speckit-implement

Speckit Implement Skill

User Input

$ARGUMENTS

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

Outline

1. Run .specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks 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").

1. 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

1. 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
• 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

1. Project Setup Verification:

• REQUIRED: Create/verify ignore files based on actual project setup:

Detection & Creation Logic:

• Check if the following command succeeds to determine if the repository is a git repo (create/verify .gitignore if so):

     git rev-parse --git-dir 2>/dev/null

• Check if Dockerfile* exists or Docker in plan.md → create/verify .dockerignore
• Check if .eslintrc* exists → create/verify .eslintignore
• Check if eslint.config.* exists → ensure the config's ignores entries cover required patterns
• Check if .prettierrc* exists → create/verify .prettierignore
• Check if .npmrc or package.json exists → create/verify .npmignore (if publishing)
• Check if terraform files (*.tf) exist → create/verify .terraformignore
• Check if .helmignore needed (helm charts present) → create/verify .helmignore

If ignore file already exists: Verify it contains essential patterns, append missing critical patterns only

If ignore file missing: Create with full pattern set for detected technology

Common Patterns by Technology (from plan.md tech stack):

• Node.js/JavaScript/TypeScript: node_modules/, dist/, build/, .log, .env
• Python: __pycache__/, .pyc, .venv/, venv/, dist/, .egg-info/
• Java: target/, .class, .jar, .gradle/, build/
• C#/.NET: bin/, obj/, .user, .suo, packages/
• Go: .exe, .test, vendor/, *.out
• Ruby: .bundle/, log/, tmp/, *.gem, vendor/bundle/
• PHP: vendor/, .log, .cache, *.env
• Rust: target/, debug/, release/, .rs.bk, .rlib, .prof, .idea/, .log, .env
• Kotlin: build/, out/, .gradle/, .idea/, .class, .jar, .iml, .log, .env*
• C++: build/, bin/, obj/, out/, .o, .so, .a, .exe, .dll, .idea/, .log, .env*
• C: build/, bin/, obj/, out/, .o, .a, .so, .exe, Makefile, config.log, .idea/, .log, .env
• Swift: .build/, DerivedData/, *.swiftpm/, Packages/
• R: .Rproj.user/, .Rhistory, .RData, .Ruserdata, *.Rproj, packrat/, renv/
• Universal: .DS_Store, Thumbs.db, .tmp, .swp, .vscode/, .idea/

Tool-Specific Patterns:

• Docker: node_modules/, .git/, Dockerfile, .dockerignore, .log, .env, coverage/
• ESLint: node_modules/, dist/, build/, coverage/, *.min.js
• Prettier: node_modules/, dist/, build/, coverage/, package-lock.json, yarn.lock, pnpm-lock.yaml
• Terraform: .terraform/, .tfstate, *.tfvars, .terraform.lock.hcl
• Kubernetes/k8s: .secret.yaml, secrets/, .kube/, kubeconfig, .key, .crt

1. 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

1. 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

1. 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

1. 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
• Provide clear error messages with context for debugging
• Suggest next steps if implementation cannot proceed
• IMPORTANT For completed tasks, make sure to mark the task off as [X] in the tasks file.

1. Completion validation:

• Verify all required tasks are completed
• Check that implemented features match the original specification
• Validate that tests pass and coverage meets requirements
• Confirm the implementation follows the technical plan
• Report final status with summary of completed work

Note: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running /speckit.tasks first to regenerate the task list.