speckit-implement-zh

User input

$ARGUMENTS

Youmustconsider user input (if not empty) before continuing.

Outline

scripts: sh: .specify/scripts/bash/check-prerequisites.sh --json ps: .specify/scripts/powershell/check-prerequisites.ps1 -Json

1. Run from the repository root {SCRIPT} and parse the FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in arguments, such as "I'm Groot", use escaped syntax: for example 'I'''m Groot' (or if possible use double quotes: "I'm Groot").

2. Check checklist status(if FEATURE_DIR/checklists/ exists):

   • Scan all checklist files in the checklists/ directory

• For each checklist, count:

  • Total items: all matching - [ ] or - [X] or - [x] lines
  • Completed items: matching - [X] or - [x] lines
  • Incomplete items: matching - [ ] lines

• Create status table:

  | 检查表 | 总计 | 已完成 | 未完成 | 状态 |
  |-----------|-------|-----------|------------|--------|
  | ux.md     | 12    | 12        | 0          | ✓ 通过 |
  | test.md   | 8     | 5         | 3          | ✗ 失败 |
  | security.md | 6   | 6         | 0          | ✓ 通过 |
  

• Calculate overall status:

  • Pass: all checklists have 0 incomplete items
  • Fail: one or more checklists have incomplete items

• If any checklist is incomplete：

  • Display a table containing the count of incomplete items
  • Stopand ask: "Some checklists are incomplete. Do you still want to proceed with implementation? (yes/no)"
  • Wait for user response before continuing
  • If the user says "no" or "wait" or "stop", then stop execution
  • If the user says "yes" or "proceed" or "continue", then continue to step 3

• If all checklists are complete：

  • Display a table showing that all checklists have passed
  • Automatically continue to step 3

1. Load and analyze implementation context:

   • Required: read tasks.md to get the complete task list and execution plan
   • Required: read plan.md to get the tech stack, architecture, and file structure
   • If present: read data-model.md to get entities and relationships
   • If present: read contracts/ to get API specifications and test requirements
   • If present: read research.md to get technical decisions and constraints
   • If present: read quickstart.md to get integration scenarios

2. Project setup verification：

   • Required: create/verify ignore files according to the actual project setup:

   Detection and creation logic：

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

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

   • Check whether Dockerfile* or Docker exists in plan.md → create/validate .dockerignore

   • Check whether .eslintrc* or eslint.config.* exists → create/validate .eslintignore

   • Check whether .prettierrc* exists → create/validate .prettierignore

   • Check whether .npmrc or package.json exists → create/validate .npmignore (if publishing)

   • Check whether terraform files (*.tf) exist → create/validate .terraformignore

   • Check whether .helmignore is needed (helm charts exist) → create/validate .helmignore

   If the ignore file already exists: validate that it contains the basic patterns, and only append the missing key patterns If the ignore file is missing: create a complete pattern set containing the detected technologies

   Common patterns by technology(from the 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/
   • General：.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

3. Parse the tasks.md structure and extract:

   • Task phases: setup, testing, core, integration, refinement
   • Task dependencies: sequential and parallel execution rules
   • Task details: ID, description, file path, parallel marker [P]
   • Execution flow: sequence and dependency requirements

4. Execute the implementation according to the task plan:

   • Phase execution: complete each phase before moving on to the next
   • Respect dependencies: run sequential tasks in order; parallel tasks [P] can run together
   • Follow the TDD approach: execute test tasks before the corresponding implementation tasks
   • File-based coordination: tasks that affect the same file must run sequentially
   • Verification checkpoints: verify the completion of each phase before continuing

5. Implementation execution rules:

   • Setup first: initialize the project structure, dependencies, and configuration
   • Tests before code: write tests if needed for contracts, entities, and integration scenarios
   • Core development: implement models, services, CLI commands, and endpoints
   • Integration work: database connections, middleware, logging, external services
   • Refinement and validation: unit tests, performance optimization, documentation

6. Progress tracking and error handling:

   • Report progress after each completed task
   • Stop execution if any non-parallel task fails
   • For parallel tasks [P], continue with the successful tasks and report the failed tasks
   • Provide clear error messages and debugging context
   • Suggest next steps if the implementation cannot continue
   • Important For completed tasks, make sure to mark them as [X] in the task file.

7. Completion verification:

   • Verify that all required tasks are completed
   • Check whether the implemented functionality matches the original specification
   • Verification tests pass and coverage meets requirements
   • Confirm the implementation follows the technical plan
   • Report the final status and a summary of the completed work

Note: This command assumes that a complete task breakdown exists in tasks.md. If the tasks are incomplete or missing, it is recommended to first run speckit-tasks to regenerate the task list.