|
| 1 | +--- |
| 2 | +description: Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation. |
| 3 | +scripts: |
| 4 | + sh: scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks |
| 5 | + ps: scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks |
| 6 | +--- |
| 7 | + |
| 8 | +The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty). |
| 9 | + |
| 10 | +User input: |
| 11 | + |
| 12 | +$ARGUMENTS |
| 13 | + |
| 14 | +Goal: Identify inconsistencies, duplications, ambiguities, and underspecified items across the three core artifacts (`spec.md`, `plan.md`, `tasks.md`) before implementation. This command MUST run only after `/tasks` has successfully produced a complete `tasks.md`. |
| 15 | + |
| 16 | +STRICTLY READ-ONLY: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually). |
| 17 | + |
| 18 | +Constitution Authority: The project constitution (`/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/analyze`. |
| 19 | + |
| 20 | +Execution steps: |
| 21 | + |
| 22 | +1. Run `{SCRIPT}` once from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS. Derive absolute paths: |
| 23 | + - SPEC = FEATURE_DIR/spec.md |
| 24 | + - PLAN = FEATURE_DIR/plan.md |
| 25 | + - TASKS = FEATURE_DIR/tasks.md |
| 26 | + Abort with an error message if any required file is missing (instruct the user to run missing prerequisite command). |
| 27 | + |
| 28 | +2. Load artifacts: |
| 29 | + - Parse spec.md sections: Overview/Context, Functional Requirements, Non-Functional Requirements, User Stories, Edge Cases (if present). |
| 30 | + - Parse plan.md: Architecture/stack choices, Data Model references, Phases, Technical constraints. |
| 31 | + - Parse tasks.md: Task IDs, descriptions, phase grouping, parallel markers [P], referenced file paths. |
| 32 | + - Load constitution `/memory/constitution.md` for principle validation. |
| 33 | + |
| 34 | +3. Build internal semantic models: |
| 35 | + - Requirements inventory: Each functional + non-functional requirement with a stable key (derive slug based on imperative phrase; e.g., "User can upload file" -> `user-can-upload-file`). |
| 36 | + - User story/action inventory. |
| 37 | + - Task coverage mapping: Map each task to one or more requirements or stories (inference by keyword / explicit reference patterns like IDs or key phrases). |
| 38 | + - Constitution rule set: Extract principle names and any MUST/SHOULD normative statements. |
| 39 | + |
| 40 | +4. Detection passes: |
| 41 | + A. Duplication detection: |
| 42 | + - Identify near-duplicate requirements. Mark lower-quality phrasing for consolidation. |
| 43 | + B. Ambiguity detection: |
| 44 | + - Flag vague adjectives (fast, scalable, secure, intuitive, robust) lacking measurable criteria. |
| 45 | + - Flag unresolved placeholders (TODO, TKTK, ???, <placeholder>, etc.). |
| 46 | + C. Underspecification: |
| 47 | + - Requirements with verbs but missing object or measurable outcome. |
| 48 | + - User stories missing acceptance criteria alignment. |
| 49 | + - Tasks referencing files or components not defined in spec/plan. |
| 50 | + D. Constitution alignment: |
| 51 | + - Any requirement or plan element conflicting with a MUST principle. |
| 52 | + - Missing mandated sections or quality gates from constitution. |
| 53 | + E. Coverage gaps: |
| 54 | + - Requirements with zero associated tasks. |
| 55 | + - Tasks with no mapped requirement/story. |
| 56 | + - Non-functional requirements not reflected in tasks (e.g., performance, security). |
| 57 | + F. Inconsistency: |
| 58 | + - Terminology drift (same concept named differently across files). |
| 59 | + - Data entities referenced in plan but absent in spec (or vice versa). |
| 60 | + - Task ordering contradictions (e.g., integration tasks before foundational setup tasks without dependency note). |
| 61 | + - Conflicting requirements (e.g., one requires to use Next.js while other says to use Vue as the framework). |
| 62 | + |
| 63 | +5. Severity assignment heuristic: |
| 64 | + - CRITICAL: Violates constitution MUST, missing core spec artifact, or requirement with zero coverage that blocks baseline functionality. |
| 65 | + - HIGH: Duplicate or conflicting requirement, ambiguous security/performance attribute, untestable acceptance criterion. |
| 66 | + - MEDIUM: Terminology drift, missing non-functional task coverage, underspecified edge case. |
| 67 | + - LOW: Style/wording improvements, minor redundancy not affecting execution order. |
| 68 | + |
| 69 | +6. Produce a Markdown report (no file writes) with sections: |
| 70 | + |
| 71 | + ### Specification Analysis Report |
| 72 | + | ID | Category | Severity | Location(s) | Summary | Recommendation | |
| 73 | + |----|----------|----------|-------------|---------|----------------| |
| 74 | + | A1 | Duplication | HIGH | spec.md:L120-134 | Two similar requirements ... | Merge phrasing; keep clearer version | |
| 75 | + (Add one row per finding; generate stable IDs prefixed by category initial.) |
| 76 | + |
| 77 | + Additional subsections: |
| 78 | + - Coverage Summary Table: |
| 79 | + | Requirement Key | Has Task? | Task IDs | Notes | |
| 80 | + - Constitution Alignment Issues (if any) |
| 81 | + - Unmapped Tasks (if any) |
| 82 | + - Metrics: |
| 83 | + * Total Requirements |
| 84 | + * Total Tasks |
| 85 | + * Coverage % (requirements with >=1 task) |
| 86 | + * Ambiguity Count |
| 87 | + * Duplication Count |
| 88 | + * Critical Issues Count |
| 89 | + |
| 90 | +7. At end of report, output a concise Next Actions block: |
| 91 | + - If CRITICAL issues exist: Recommend resolving before `/implement`. |
| 92 | + - If only LOW/MEDIUM: User may proceed, but provide improvement suggestions. |
| 93 | + - Provide explicit command suggestions: e.g., "Run /specify with refinement", "Run /plan to adjust architecture", "Manually edit tasks.md to add coverage for 'performance-metrics'". |
| 94 | + |
| 95 | +8. Ask the user: "Would you like me to suggest concrete remediation edits for the top N issues?" (Do NOT apply them automatically.) |
| 96 | + |
| 97 | +Behavior rules: |
| 98 | +- NEVER modify files. |
| 99 | +- NEVER hallucinate missing sections—if absent, report them. |
| 100 | +- KEEP findings deterministic: if rerun without changes, produce consistent IDs and counts. |
| 101 | +- LIMIT total findings in the main table to 50; aggregate remainder in a summarized overflow note. |
| 102 | +- If zero issues found, emit a success report with coverage statistics and proceed recommendation. |
| 103 | + |
| 104 | +Context: {ARGS} |
0 commit comments