Update commands.

templates/checklist-template.md

@@ -0,0 +1,40 @@
+# [CHECKLIST TYPE] Checklist: [FEATURE NAME]
+
+**Purpose**: [Brief description of what this checklist covers]
+**Created**: [DATE]
+**Feature**: [Link to spec.md or relevant documentation]
+
+**Note**: This checklist is generated by the `/checklist` command based on feature context and requirements.
+
+<!-- 
+  ============================================================================
+  IMPORTANT: The checklist items below are SAMPLE ITEMS for illustration only.
+  
+  The /checklist command MUST replace these with actual items based on:
+  - User's specific checklist request
+  - Feature requirements from spec.md
+  - Technical context from plan.md
+  - Implementation details from tasks.md
+  
+  DO NOT keep these sample items in the generated checklist file.
+  ============================================================================
+-->
+
+## [Category 1]
+
+- [ ] CHK001 First checklist item with clear action
+- [ ] CHK002 Second checklist item
+- [ ] CHK003 Third checklist item
+
+## [Category 2]
+
+- [ ] CHK004 Another category item
+- [ ] CHK005 Item with specific criteria
+- [ ] CHK006 Final item in this category
+
+## Notes
+
+- Check items off as completed: `[x]`
+- Add comments or findings inline
+- Link to relevant resources or documentation
+- Items are numbered sequentially for easy reference

templates/commands/analyze.md

@@ -9,8 +9,8 @@ The user input to you can be provided directly by the agent or as a command argu
 
 User input:
 
-$ARGUMENTS
-
+`$ARGUMENTS
+`
 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`.
 
 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).

templates/commands/checklist.md

@@ -0,0 +1,130 @@
+---
+description: Generate a custom checklist for the current feature based on user requirements.
+scripts:
+  sh: scripts/bash/check-prerequisites.sh --json
+  ps: scripts/powershell/check-prerequisites.ps1 -Json
+---
+
+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).
+
+User input:
+
+`$ARGUMENTS
+`
+## Execution Steps
+
+1. **Setup**: Run `{SCRIPT}` from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS list.
+   - All file paths must be absolute.
+
+2. **Clarify intent (dynamic)**: Derive THREE contextual clarifying questions (no pre-baked catalog). They MUST:
+   - Be generated from the user's phrasing + extracted signals from spec/plan/tasks
+   - Only ask about information that materially changes checklist content
+   - Be skipped individually if already unambiguous in `$ARGUMENTS`
+   - Prefer precision over breadth
+
+   Generation algorithm:
+   1. Extract signals: feature domain keywords (e.g., auth, latency, UX, API), risk indicators ("critical", "must", "compliance"), stakeholder hints ("QA", "review", "security team"), and explicit deliverables ("a11y", "rollback", "contracts").
+   2. Cluster signals into candidate focus areas (max 4) ranked by relevance.
+   3. Identify probable audience & timing (author, reviewer, QA, release) if not explicit.
+   4. Detect missing dimensions: scope breadth, depth/rigor, risk emphasis, exclusion boundaries, measurable acceptance criteria.
+   5. Formulate up to three questions chosen from these archetypes:
+      - Scope refinement (e.g., "Should this include integration touchpoints with X and Y or stay limited to local module correctness?")
+      - Risk prioritization (e.g., "Which of these potential risk areas should receive mandatory gating checks?")
+      - Depth calibration (e.g., "Is this a lightweight pre-commit sanity list or a formal release gate?")
+      - Audience framing (e.g., "Will this be used by the author only or peers during PR review?")
+      - Boundary exclusion (e.g., "Should we explicitly exclude performance tuning items this round?")
+
+   Question formatting rules:
+   - If presenting options, generate a compact table with columns: Option | Candidate | Why It Matters
+   - Limit to A–E options maximum; omit table if a free-form answer is clearer
+   - Never ask the user to restate what they already said
+   - Avoid speculative categories (no hallucination). If uncertain, ask explicitly: "Confirm whether X belongs in scope." 
+
+   Defaults when interaction impossible:
+   - Depth: Standard
+   - Audience: Reviewer (PR) if code-related; Author otherwise
+   - Focus: Top 2 relevance clusters
+
+   Output the three questions (or fewer if not needed) and wait for answers before continuing. Clearly label each as Q1/Q2/Q3.
+
+3. **Understand user request**: Combine `$ARGUMENTS` + clarifying answers:
+   - Derive checklist theme (e.g., security, review, deploy, ux)
+   - Consolidate explicit must-have items mentioned by user
+   - Map focus selections to category scaffolding
+   - Infer any missing context from spec/plan/tasks (do NOT hallucinate)
+
+4. **Load feature context**: Read from FEATURE_DIR:
+   - spec.md: Feature requirements and scope
+   - plan.md (if exists): Technical details, dependencies
+   - tasks.md (if exists): Implementation tasks
+   - Use context to enrich or validate checklist items (omit irrelevant categories)
+
+5. **Generate checklist**:
+   - Create `FEATURE_DIR/checklists/` directory if it doesn't exist
+   - Generate unique checklist filename:
+     * Use short, descriptive name based on checklist type
+     * Format: `[type].md` (e.g., `ux.md`, `test.md`, `security.md`, `deploy.md`)
+     * If file exists, append counter: `[type]-2.md`, `[type]-3.md`, etc.
+     * Examples: `ux.md`, `test.md`, `security.md`, `deploy.md`, `review-2.md`
+   - Use format: `[ ] CHK001 Item description here`
+   - Number items sequentially starting from CHK001
+   - Group items by category/section if applicable
+   - Include brief explanations or links where helpful
+   - Each `/checklist` run creates a NEW file (never overwrites existing checklists)
+
+6. **Checklist structure**:
+   ```markdown
+   # [Checklist Type] Checklist: [Feature Name]
+   
+   **Purpose**: [Brief description of what this checklist covers]
+   **Created**: [Date]
+   
+   ## [Category 1]
+   - [ ] CHK001 First item
+   - [ ] CHK002 Second item
+   
+   ## [Category 2]
+   - [ ] CHK003 Third item
+   ```
+
+7. **Report**: Output full path to created checklist, item count, and remind user that each run creates a new file. Summarize:
+   - Focus areas selected
+   - Depth level
+   - Actor/timing
+   - Any explicit user-specified must-have items incorporated
+
+**Important**: Each `/checklist` command invocation creates a NEW checklist file using short, descriptive names. This allows:
+- Multiple checklists of different types (e.g., `ux.md`, `test.md`, `security.md`)
+- Simple, memorable filenames that indicate checklist purpose
+- Counter-based uniqueness for duplicate types (e.g., `review-2.md`)
+- Easy identification and navigation in the checklists/ folder
+
+To avoid clutter, use descriptive types and clean up obsolete checklists when done.
+
+## Example Checklist Types
+
+**Code Review:** `review.md`
+- Code quality checks
+- Documentation requirements
+- Test coverage verification
+- Security considerations
+
+**Pre-Deployment:** `deploy.md`
+- Build verification
+- Test execution
+- Configuration validation
+- Rollback plan
+
+**Accessibility:** `ux.md` or `a11y.md`
+- WCAG compliance
+- Keyboard navigation
+- Screen reader compatibility
+- Color contrast
+
+**Security:** `security.md`
+- Input validation
+- Authentication/authorization
+- Data encryption
+- Dependency vulnerabilities
+
+Generate checklist items that are specific, actionable, and relevant to the feature context.

templates/commands/clarify.md

@@ -9,7 +9,7 @@ The user input to you can be provided directly by the agent or as a command argu
 
 User input:
 
-$ARGUMENTS
+`$ARGUMENTS`
 
 Goal: Detect and reduce ambiguity or missing decision points in the active feature specification and record the clarifications directly in the spec file.
 

templates/commands/constitution.md

@@ -6,7 +6,7 @@ The user input to you can be provided directly by the agent or as a command argu
 
 User input:
 
-$ARGUMENTS
+`$ARGUMENTS`
 
 You are updating the project constitution at `/memory/constitution.md`. This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.
 

templates/commands/implement.md

@@ -9,11 +9,40 @@ The user input can be provided directly by the agent or as a command argument -
 
 User input:
 
-$ARGUMENTS
+`$ARGUMENTS`
 
 1. Run `{SCRIPT}` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute.
 
-2. Load and analyze the implementation context:
+2. **Check checklists status** (if FEATURE_DIR/checklists/ exists):
+   - Scan all checklist files in the checklists/ directory
+   - For each checklist, count:
+     * Total items: All lines matching `- [ ]` or `- [X]` or `- [x]`
+     * Completed items: Lines matching `- [X]` or `- [x]`
+     * Incomplete items: Lines matching `- [ ]`
+   - Create a status table:
+     ```
+     | Checklist | Total | Completed | Incomplete | Status |
+     |-----------|-------|-----------|------------|--------|
+     | ux.md     | 12    | 12        | 0          | ✓ PASS |
+     | test.md   | 8     | 5         | 3          | ✗ FAIL |
+     | security.md | 6   | 6         | 0          | ✓ PASS |
+     ```
+   - Calculate overall status:
+     * **PASS**: All checklists have 0 incomplete items
+     * **FAIL**: One or more checklists have incomplete items
+   
+   - **If any checklist is incomplete**:
+     * Display the table with incomplete item counts
+     * **STOP** and ask: "Some checklists are incomplete. Do you want to proceed with implementation anyway? (yes/no)"
+     * Wait for user response before continuing
+     * If user says "no" or "wait" or "stop", halt execution
+     * If user says "yes" or "proceed" or "continue", proceed to step 3
+   
+   - **If all checklists are complete**:
+     * Display the table showing all checklists passed
+     * Automatically proceed to step 3
+
+3. Load and analyze the implementation context:
    - **REQUIRED**: Read tasks.md for the complete task list and execution plan
    - **REQUIRED**: Read plan.md for tech stack, architecture, and file structure
    - **IF EXISTS**: Read data-model.md for entities and relationships
@@ -21,27 +50,27 @@ $ARGUMENTS
    - **IF EXISTS**: Read research.md for technical decisions and constraints
    - **IF EXISTS**: Read quickstart.md for integration scenarios
 
-3. Parse tasks.md structure and extract:
+4. Parse tasks.md structure and extract:
    - **Task phases**: Setup, Tests, Core, Integration, Polish
    - **Task dependencies**: Sequential vs parallel execution rules
    - **Task details**: ID, description, file paths, parallel markers [P]
    - **Execution flow**: Order and dependency requirements
 
-4. Execute implementation following the task plan:
+5. Execute implementation following the task plan:
    - **Phase-by-phase execution**: Complete each phase before moving to the next
    - **Respect dependencies**: Run sequential tasks in order, parallel tasks [P] can run together  
    - **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks
    - **File-based coordination**: Tasks affecting the same files must run sequentially
    - **Validation checkpoints**: Verify each phase completion before proceeding
 
-5. Implementation execution rules:
+6. Implementation execution rules:
    - **Setup first**: Initialize project structure, dependencies, configuration
    - **Tests before code**: If you need to write tests for contracts, entities, and integration scenarios
    - **Core development**: Implement models, services, CLI commands, endpoints
    - **Integration work**: Database connections, middleware, logging, external services
    - **Polish and validation**: Unit tests, performance optimization, documentation
 
-6. Progress tracking and error handling:
+7. Progress tracking and error handling:
    - Report progress after each completed task
    - Halt execution if any non-parallel task fails
    - For parallel tasks [P], continue with successful tasks, report failed ones
@@ -49,7 +78,7 @@ $ARGUMENTS
    - Suggest next steps if implementation cannot proceed
    - **IMPORTANT** For completed tasks, make sure to mark the task off as [X] in the tasks file.
 
-7. Completion validation:
+8. Completion validation:
    - Verify all required tasks are completed
    - Check that implemented features match the original specification
    - Validate that tests pass and coverage meets requirements

templates/commands/plan.md

@@ -12,7 +12,7 @@ The user input to you can be provided directly by the agent or as a command argu
 
 User input:
 
-$ARGUMENTS
+`$ARGUMENTS`
 
 ## Execution Steps
 

templates/commands/specify.md

@@ -9,7 +9,7 @@ The user input to you can be provided directly by the agent or as a command argu
 
 User input:
 
-$ARGUMENTS
+`$ARGUMENTS`
 
 The text the user typed after `/specify` in the triggering message **is** the feature description. Assume you always have it available in this conversation even if `{ARGS}` appears literally below. Do not ask the user to repeat it unless they provided an empty command.
 
@@ -33,10 +33,7 @@ Given that feature description, do this:
        Each requirement must be testable
        Mark ambiguous requirements
     6. Identify Key Entities (if data involved)
-    7. Run Review Checklist
-       If any [NEEDS CLARIFICATION]: WARN "Spec has uncertainties"
-       If implementation details found: ERROR "Remove tech details"
-    8. Return: SUCCESS (spec ready for planning)
+    7. Return: SUCCESS (spec ready for planning)
 
 4. Write the specification to SPEC_FILE using the template structure, replacing placeholders with concrete details derived from the feature description (arguments) while preserving section order and headings.
 5. Report completion with branch name, spec file path, and readiness for the next phase.
@@ -47,9 +44,10 @@ Given that feature description, do this:
 
 ## Quick Guidelines
 
-- Focus on WHAT users need and WHY
-- Avoid HOW to implement (no tech stack, APIs, code structure)
-- Written for business stakeholders, not developers
+- Focus on **WHAT** users need and **WHY**.
+- Avoid HOW to implement (no tech stack, APIs, code structure).
+- Written for business stakeholders, not developers.
+- DO NOT create any checklists that are embedded in the spec. That will be a separate command.
 
 ### Section Requirements
 

templates/commands/tasks.md

@@ -9,7 +9,7 @@ The user input to you can be provided directly by the agent or as a command argu
 
 User input:
 
-$ARGUMENTS
+`$ARGUMENTS`
 
 ## Execution Steps