Speckit Plan

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 FEATURE_SPEC, IMPL_PLAN, 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").

2. Load context: Read FEATURE_SPEC and .specify/memory/constitution.md. Load IMPL_PLAN template (already copied).

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

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

2. Generate and dispatch research agents:

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

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

2. Generate API contracts from functional requirements:

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

3. 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: 部署上线

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