一键导入
speckit
Use when user wants to work with specifications or create feature requirements following the spec-driven development workflow
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when user wants to work with specifications or create feature requirements following the spec-driven development workflow
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Use when starting work on any project (technical or non-technical) to understand structure, standards, and best practices before making changes
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Apply the code-quality checklist to audit files or directories and produce a Markdown report with findings and suggested fixes. Use when asked to "audit these files", "run a quality check", "code quality review", or "check against the code-quality checklist".
Generate a structured deep research prompt. USE WHEN the user needs to research a complex topic, market, or bug deeply. Capabilities include objective clarification, tech stack validation, and prompt generation.
Use for go-to-market strategy, user acquisition, channel analysis, and performance marketing.
Generate documentation for an existing project. USE WHEN onboarded to a new codebase OR documenting legacy code. Capabilities include architectural mapping, tech stack inventory, and technical debt documentation.
| name | speckit |
| description | Use when user wants to work with specifications or create feature requirements following the spec-driven development workflow |
Speckit is a complete specification-driven development workflow that ensures features are well-defined before implementation. It guides you through creating specifications, technical plans, and actionable tasks.
Core Principle: Define WHAT and WHY before HOW. Specifications describe user needs and business value, plans describe technical approach, tasks describe execution steps.
Use this skill when:
The speckit workflow has 4 main phases:
1. Brainstorming → 2. Specify → 3. Plan → 4. Tasks → (5. Implement)
Skill: brainstorming
Purpose: Deeply understand user intent, requirements, and design before creating the specification.
When: User presents their goal and wants to work in the specs format
What happens:
Output: Clear understanding of feature requirements, ready to be formalized
Skill: speckit-specify
Purpose: Create a formal, technology-agnostic specification that describes user needs and business value.
Prerequisites: Completed brainstorming session
What happens:
spec.md with:
Key Principles:
Output: specs/N-feature-name/spec.md - Complete feature specification
Skill: speckit-plan
Purpose: Create technical implementation plan that describes HOW to build the feature.
Prerequisites: Completed specification
What happens:
Output:
specs/N-feature-name/plan.md - Implementation planspecs/N-feature-name/data-model.md - Entity relationshipsspecs/N-feature-name/contracts/ - API specificationsspecs/N-feature-name/quickstart.md - Integration scenariosspecs/N-feature-name/research.md - Technical decisionsSkill: speckit-tasks
Purpose: Break down the plan into actionable, dependency-ordered tasks.
Prerequisites: Completed technical plan
What happens:
Key Principles:
Output: specs/N-feature-name/tasks.md - Complete task breakdown
Skills: executing-plans OR test-driven-development (user choice)
Purpose: Execute the tasks and build the feature.
Prerequisites: Completed task breakdown
User Choice:
What happens:
Output: Implemented feature matching specification
Skill: speckit-checklist
Purpose: Generate custom requirement quality checklists ("unit tests for requirements")
When: After specification or plan, when you need domain-specific validation
Output: specs/N-feature-name/checklists/[domain].md - Quality checklist
Skill: speckit-constitution
Purpose: Create or update project constitution (principles and standards)
When: Establishing project principles or updating standards
Output: .specify/memory/constitution.md - Project constitution
Brainstorm the feature:
Use brainstorming skill to explore feature requirements
Create specification:
Use speckit-specify skill with feature description
Build technical plan:
Use speckit-plan skill to design implementation
Generate tasks:
Use speckit-tasks skill to create task breakdown
Implement (choose one):
Use executing-plans skill for sequential execution
OR
Use test-driven-development skill for TDD approach
User says: "I want to build a user authentication system with OAuth2"
Agent does:
Invoke brainstorming skill
Invoke speckit-specify skill
Invoke speckit-plan skill
Invoke speckit-tasks skill
Offer implementation options:
If requirements are unclear, use brainstorming first to explore the problem space.
After generating spec, use speckit-checklist to validate quality, then refine if needed.
Generate tasks.md once, then choose between executing-plans (sequential) or test-driven-development (TDD).
Define project constitution first, then all specs/plans automatically enforce those principles.
Wrong: Jump directly to speckit-specify without understanding requirements Right: Use brainstorming to deeply explore user needs first
Wrong: Include framework choices, API endpoints, database schemas in spec.md Right: Spec describes user needs, plan describes technical approach
Wrong: Generate tasks directly from specification Right: Create technical plan first, then generate tasks from plan
Wrong: Proceed with implementation when checklists fail Right: Complete checklists or explicitly acknowledge risk
Wrong: "Create user model" (no file path, unclear scope) Right: "Create User entity in src/models/user.py with fields from data-model.md" [US1]
You're using speckit correctly when:
specs/N-feature-name/
├── spec.md # WHAT & WHY (from speckit-specify)
├── plan.md # HOW (from speckit-plan)
├── tasks.md # Execution plan (from speckit-tasks)
├── data-model.md # Entities (from speckit-plan)
├── research.md # Technical decisions (from speckit-plan)
├── quickstart.md # Integration scenarios (from speckit-plan)
├── contracts/ # API specs (from speckit-plan)
│ ├── openapi.yaml
│ └── ...
└── checklists/ # Quality validation (from speckit-checklist)
├── ux.md
├── security.md
└── ...