Spec Kit Plan Skill

When to Use

• The feature spec is ready and you need a technical implementation plan.

Inputs

• specs/<feature>/spec.md
• Repo context and .specify/ templates
• User-provided constraints or tech preferences (if any)

If the spec is missing, ask the user to run speckit-specify first.

Workflow

1. Setup: Run .specify/scripts/bash/setup-plan.sh --json from repo root and parse JSON for FEATURESPEC, IMPLPLAN, SPECS_DIR, BRANCH. 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. Load context: Read FEATURESPEC and .specify/memory/constitution.md. Load IMPLPLAN template (already copied).

1. Execute plan workflow: Follow the structure in IMPL_PLAN template to:

- Fill Technical Context (mark unknowns as "NEEDS CLARIFICATION") - Fill Constitution Check section from constitution - Evaluate gates (ERROR if violations unjustified) - Phase 0: Generate research.md (resolve all NEEDS CLARIFICATION) - Phase 1: Generate data-model.md, contracts/, quickstart.md - Phase 1: Update agent context by running the agent script - Re-evaluate Constitution Check post-design

1. Stop and report: Command ends after Phase 2 planning. Report branch, IMPL_PLAN path, and generated artifacts.

Phases

Phase 0: Outline & Research

1. Extract unknowns from Technical Context above:

- For each NEEDS CLARIFICATION → research task - For each dependency → best practices task - For each integration → patterns task

1. Generate and dispatch research agents:

``text For each unknown in Technical Context: Task: "Research {unknown} for {feature context}" For each technology choice: Task: "Find best practices for {tech} in {domain}" ``

1. Consolidate findings in research.md using format:

- Decision: [what was chosen] - Rationale: [why chosen] - Alternatives considered: [what else evaluated]

Output: research.md with all NEEDS CLARIFICATION resolved

Phase 1: Design & Contracts

Prerequisites: research.md complete

1. Extract entities from feature spec → data-model.md:

- Entity name, fields, relationships - Validation rules from requirements - State transitions if applicable

1. Generate API contracts from functional requirements:

- For each user action → endpoint - Use standard REST/GraphQL patterns - Output OpenAPI/GraphQL schema to /contracts/

1. Agent context update:

- Run .specify/scripts/bash/update-agent-context.sh <agent_type> - Use the current runtime agent type (e.g., claude, codex, copilot, gemini). Leave empty to update all existing agent files. - Update the appropriate agent-specific context file - Add only new technology from current plan - Preserve manual additions between markers

Output: data-model.md, /contracts/\*, quickstart.md, agent-specific file

Key rules

• Use absolute paths
• ERROR on gate failures or unresolved clarifications

Outputs

• specs/<feature>/plan.md (filled implementation plan)
• specs/<feature>/research.md
• specs/<feature>/data-model.md
• specs/<feature>/contracts/ (API schemas)
• specs/<feature>/quickstart.md
• Updated agent context file (runtime-specific)

Next Steps

After planning:

• Generate tasks with speckit-tasks.
• Create a checklist with speckit-checklist when a quality gate is needed.

国内适配

• 支持中文文档和中文注释
• 示例代码兼容国内开发环境
• 提供中文 FAQ 和常见问题解答

能力边界

✅ 适用场景

• 当你需要使用此技能对应的技术栈时
• 当项目需要遵循最佳实践时
• 当需要快速上手或深入理解核心概念时

⚠️ 需要注意

• 复杂业务逻辑需要结合具体场景调整
• 性能优化需要根据实际数据量评估

❌ 不适用场景

• 不相关的技术栈或框架
• 需要完全自定义的特殊场景

使用流程

Step 1: 环境准备

确保开发环境已安装必要的依赖和工具。

Step 2: 配置初始化

根据项目需求进行基础配置。

Step 3: 核心功能使用

按照示例代码实现核心功能。

Step 4: 测试验证

运行测试确保功能正常。

Step 5: 部署上线

完成开发后进行部署和监控。