speckit-implement

name	speckit-implement
description	Execute the implementation plan by processing and executing all tasks via the Beads issue tracker (br/bv)
compatibility	Requires spec-kit project structure with .specify/ directory and Beads CLI
metadata	{"author":"github-spec-kit","source":"templates/commands/implement.md"}

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Pre-Execution Checks

Check for extension hooks (before implementation):

• Check if .specify/extensions.yml exists in the project root.
• If it exists, read it and look for entries under the hooks.before_implement key
• If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
• Filter out hooks where enabled is explicitly false. Treat hooks without an enabled field as enabled by default.
• For each remaining hook, do not attempt to interpret or evaluate hook condition expressions:
  • If the hook has no condition field, or it is null/empty, treat the hook as executable
  • If the hook defines a non-empty condition, skip the hook and leave condition evaluation to the HookExecutor implementation
• For each executable hook, output the following based on its optional flag:
  • Optional hook (optional: true):

    ## Extension Hooks
    
    **Optional Pre-Hook**: {extension}
    Command: `/{command}`
    Description: {description}
    
    Prompt: {prompt}
    To execute: `/{command}`
    

  • Mandatory hook (optional: false):

    ## Extension Hooks
    
    **Automatic Pre-Hook**: {extension}
    Executing: `/{command}`
    EXECUTE_COMMAND: {command}
    
    Wait for the result of the hook command before proceeding to the Outline.
    

• If no hooks are registered or .specify/extensions.yml does not exist, skip silently

Outline

1. Run .specify/scripts/bash/check-prerequisites.sh --json from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'''m Groot' (or double-quote if possible: "I'm Groot").

2. Check checklists status:

   • Run br list --status=open --json and look for beads with type chore or question related to the current feature's Spec ID.
   • If any open checklist beads exist:
     • Display a summary of the incomplete checklist beads.
     • STOP and ask: "Some checklist/verification beads 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 checklist beads are complete (or none exist):
     • Display a message that all checklist requirements are met.
     • Automatically proceed to step 3

3. Load and analyze the implementation context:

   • REQUIRED: Query the Beads system using bv --robot-triage to assess project health and identify the highest priority actionable work
   • REQUIRED: Read plan.md for tech stack, architecture, and file structure
   • REQUIRED: Use code-review-graph MCP tools (e.g., semantic_search_nodes, get_impact_radius) to establish architectural boundaries and identify impact radius before editing existing code.
   • IF EXISTS: Read data-model.md for entities and relationships
   • IF EXISTS: Read contracts/ for API specifications and test requirements
   • IF EXISTS: Read research.md for technical decisions and constraints
   • IF EXISTS: Read quickstart.md for integration scenarios

4. Beads Workflow Integration (Phase-by-Phase Execution Loop): You MUST execute tasks strictly through the Beads issue tracking system (br and bv) ONE PHASE AT A TIME to avoid context limit errors and ensure controlled progress. Do NOT attempt to implement all beads in a single uninterrupted run.

   • Determine Current Phase: Identify the lowest phase (e.g., Phase 1, Phase 2) that has open beads.
   • Execute Phase Loop:
     • Step A: Triage & Pick Work: Run bv --robot-triage to find unblocked, high-priority issues. Choose the top recommended actionable item that explicitly contains the current phase tag in its title (e.g., [Phase: Phase 1]).
     • Step B: Claim Work: Claim the issue by running br update <id> --status=in_progress.
     • Step C: Load Context: Read the full issue details via br show <id>. Review its description for the Exit State & Verification requirements. CRITICAL: Use code-review-graph tools to verify the blast radius of your intended changes.
     • Step D: Implement & Test: Execute the required code changes, adhering strictly to the plan and project constraints. Follow TDD where applicable. Verify the exit state.
     • Step E: Complete & Release: Close the issue by running br close <id> --reason "Completed: <brief summary>".
     • Step F: Sync: Run br sync --flush-only to export the database changes to JSONL.
   • Phase Pause: Repeat this loop until there are no more actionable items for the current phase. Once all beads for the current phase are completed, STOP and ask the user: "I have completed all tasks for Phase X. Should I proceed to implement the tasks for Phase Y?"
   • Wait for Confirmation: You MUST wait for the user's explicit confirmation before continuing to the next phase.

5. Implementation execution rules:

   • Setup first: Initialize project structure, dependencies, configuration based on foundational beads.
   • Tests before code: If required by the bead, write tests for contracts and integration scenarios first.
   • Respect Boundaries: Do not expand scope beyond the current bead's Exit State.

6. Progress tracking and error handling:

   • Halt execution if a critical task fails or an assumption is invalidated.
   • If a task is blocked by a newly discovered dependency, create a new bead (br create), link the dependency (br dep add), and switch context to unblock it.
   • Provide clear error messages with context for debugging.

7. Completion validation:

   • Verify all required beads for the feature are completed (br list --status=open should not show pending tasks for this feature).
   • Validate that tests pass and coverage meets requirements.
   • Confirm the implementation follows the technical plan.
   • Report final status with a summary of completed work.
   • Run a final br sync --flush-only.

Note: This command assumes tasks have already been generated in the Beads system. If the backlog is empty, suggest running /speckit.tasks first to populate the tasks via Beads.

8. Check for extension hooks: After completion validation, check if .specify/extensions.yml exists in the project root.
   • If it exists, read it and look for entries under the hooks.after_implement key
   • If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
   • Filter out hooks where enabled is explicitly false. Treat hooks without an enabled field as enabled by default.
   • For each remaining hook, do not attempt to interpret or evaluate hook condition expressions:
     • If the hook has no condition field, or it is null/empty, treat the hook as executable
     • If the hook defines a non-empty condition, skip the hook and leave condition evaluation to the HookExecutor implementation
   • For each executable hook, output the following based on its optional flag:
     • Optional hook (optional: true):

       ## Extension Hooks
       
       **Optional Hook**: {extension}
       Command: `/{command}`
       Description: {description}
       
       Prompt: {prompt}
       To execute: `/{command}`
       

     • Mandatory hook (optional: false):

       ## Extension Hooks
       
       **Automatic Hook**: {extension}
       Executing: `/{command}`
       EXECUTE_COMMAND: {command}
       

   • If no hooks are registered or .specify/extensions.yml does not exist, skip silently