spec-kit-skill

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Spec-Kit: Constitution-Based Spec-Driven Development

Spec-Kit：基于规约的规格驱动开发

Official GitHub Spec-Kit integration providing a 7-phase constitution-driven workflow for feature development.

官方GitHub Spec-Kit集成，为功能开发提供七阶段的规约驱动工作流。

Quick Start

快速开始

This skill works with the GitHub Spec-Kit CLI to guide you through structured feature development:

Constitution → Establish governing principles
Specify → Define functional requirements
Clarify → Resolve ambiguities
Plan → Create technical strategy
Tasks → Generate actionable breakdown
Analyze → Validate consistency
Implement → Execute implementation

Storage: Creates files in

.specify/specs/NNN-feature-name/

directory with numbered features

本工具与GitHub Spec-Kit CLI配合使用，引导你完成结构化的功能开发：

规约制定 → 确立治理原则
规格定义 → 定义功能需求
澄清歧义 → 解决模糊点
方案规划 → 制定技术策略
任务拆分 → 生成可执行的任务分解
一致性分析 → 验证内容一致性
功能实现 → 执行开发实现

存储：在

.specify/specs/NNN-feature-name/

目录中创建带编号的功能相关文件

When to Use

适用场景

Setting up spec-kit in a project
Creating constitution-based feature specifications
Working with .specify/ directory
Following GitHub spec-kit workflow
Constitution-driven development

在项目中设置Spec-Kit
创建基于规约的功能规格说明
操作.specify/目录
遵循GitHub Spec-Kit工作流
规约驱动的开发

Prerequisites & Setup

前置条件与设置

Check CLI Installation

检查CLI安装情况

First, verify if spec-kit CLI is installed:

bash

command -v specify || echo "Not installed"

首先，验证是否已安装spec-kit CLI：

bash

command -v specify || echo "Not installed"

Installation

安装步骤

If not installed:

bash

undefined

如果未安装：

bash

undefined

Persistent installation (recommended)

持久化安装（推荐）

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

One-time usage

一次性使用

uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>


**Requirements**:
- Python 3.11+
- Git
- uv package manager ([install uv](https://docs.astral.sh/uv/))

uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>


**要求**：
- Python 3.11+
- Git
- uv包管理器（[安装uv](https://docs.astral.sh/uv/)）

Project Initialization

项目初始化

If CLI is installed but project not initialized:

bash

undefined

如果已安装CLI但项目未初始化：

bash

undefined

Initialize in current directory

在当前目录初始化

specify init . --ai claude

Initialize new project

初始化新项目

specify init <project-name> --ai claude

Options:

选项：

--force: Overwrite non-empty directories

--force: 覆盖非空目录

--script ps: Generate PowerShell scripts (Windows)

--script ps: 生成PowerShell脚本（Windows系统）

--no-git: Skip Git initialization

--no-git: 跳过Git初始化


---

<details>
<summary>🔍 Phase Detection Logic</summary>


---

<details>
<summary>🔍 阶段检测逻辑</summary>

Detecting Project State

检测项目状态

Before proceeding, always detect the current state:

在开始前，请先检测当前项目状态：

1. CLI Installed?

1. CLI是否已安装？

bash

if command -v specify &> /dev/null || [ -x "$HOME/.local/bin/specify" ]; then
  echo "CLI installed"
else
  echo "CLI not installed - guide user through installation"
fi

bash

if command -v specify &> /dev/null || [ -x "$HOME/.local/bin/specify" ]; then
  echo "CLI installed"
else
  echo "CLI not installed - guide user through installation"
fi

2. Project Initialized?

2. 项目是否已初始化？

bash

if [ -d ".specify" ] && [ -f ".specify/memory/constitution.md" ]; then
  echo "Project initialized"
else
  echo "Project not initialized - guide user through 'specify init'"
fi

bash

if [ -d ".specify" ] && [ -f ".specify/memory/constitution.md" ]; then
  echo "Project initialized"
else
  echo "Project not initialized - guide user through 'specify init'"
fi

3. Current Feature

3. 当前功能模块

bash

undefined

bash

undefined

Get latest feature directory

获取最新的功能目录

LATEST=$(ls -d .specify/specs/[0-9]* 2>/dev/null | sort -V | tail -1) echo "Latest feature: $LATEST"

undefined

LATEST=$(ls -d .specify/specs/[0-9]* 2>/dev/null | sort -V | tail -1) echo "Latest feature: $LATEST"

undefined

4. Current Phase

4. 当前阶段

Detect phase by checking file existence in latest feature:

bash

FEATURE_DIR=".specify/specs/001-feature-name"

if [ ! -f ".specify/memory/constitution.md" ]; then
  echo "Phase: constitution"
elif [ ! -d "$FEATURE_DIR" ]; then
  echo "Phase: specify"
elif [ -f "$FEATURE_DIR/spec.md" ] && ! grep -q "## Clarifications" "$FEATURE_DIR/spec.md"; then
  echo "Phase: clarify"
elif [ ! -f "$FEATURE_DIR/plan.md" ]; then
  echo "Phase: plan"
elif [ ! -f "$FEATURE_DIR/tasks.md" ]; then
  echo "Phase: tasks"
elif [ -f "$FEATURE_DIR/tasks.md" ] && grep -q "\\- \\[ \\]" "$FEATURE_DIR/tasks.md"; then
  echo "Phase: implement"
else
  echo "Phase: complete"
fi

</details> <details> <summary>📜 Phase 1: Constitution</summary>

通过检查最新功能目录中的文件存在情况来检测阶段：

bash

FEATURE_DIR=".specify/specs/001-feature-name"

if [ ! -f ".specify/memory/constitution.md" ]; then
  echo "Phase: constitution"
elif [ ! -d "$FEATURE_DIR" ]; then
  echo "Phase: specify"
elif [ -f "$FEATURE_DIR/spec.md" ] && ! grep -q "## Clarifications" "$FEATURE_DIR/spec.md"; then
  echo "Phase: clarify"
elif [ ! -f "$FEATURE_DIR/plan.md" ]; then
  echo "Phase: plan"
elif [ ! -f "$FEATURE_DIR/tasks.md" ]; then
  echo "Phase: tasks"
elif [ -f "$FEATURE_DIR/tasks.md" ] && grep -q "\\- \\[ \\]" "$FEATURE_DIR/tasks.md"; then
  echo "Phase: implement"
else
  echo "Phase: complete"
fi

</details> <details> <summary>📜 阶段1：规约制定</summary>

Constitution Phase

规约制定阶段

Establish foundational principles that govern all development decisions.

确立指导所有开发决策的基础原则。

Purpose

目标

Create

.specify/memory/constitution.md

with:

Project values and principles
Technical standards
Decision-making frameworks
Code quality expectations
Architecture guidelines

创建

.specify/memory/constitution.md

文件，包含：

项目价值观与原则
技术标准
决策框架
代码质量要求
架构指南

Process

流程

Gather Context
- Understand project domain
- Identify key stakeholders
- Review existing standards (if any)
Draft Constitution
- Core values and principles
- Technical standards
- Quality expectations
- Decision criteria
Structure

markdown

undefined

收集上下文
- 了解项目领域
- 识别关键利益相关者
- 审查现有标准（如果有）
起草规约
- 核心价值观与原则
- 技术标准
- 质量要求
- 决策标准
结构示例

markdown

undefined

Project Constitution

项目规约

Core Values

核心价值观

[Value Name]: [Description and implications]
[Value Name]: [Description and implications]

[价值观名称]: [描述与影响]
[价值观名称]: [描述与影响]

Technical Principles

技术原则

Architecture

架构

[Principle with rationale]

[原则与理由]

Code Quality

代码质量

[Standards and expectations]

[标准与要求]

Performance

性能

[Performance criteria]

[性能标准]

Decision Framework

决策框架

When making technical decisions, consider:

[Criterion with priority]
[Criterion with priority]


4. **Versioning**
   - Constitution can evolve
   - Track changes for governance
   - Review periodically

在做出技术决策时，需考虑：

[带优先级的标准]
[带优先级的标准]


4. **版本控制**
   - 规约可以逐步演进
   - 跟踪变更以用于治理
   - 定期审查更新

Example Content

示例内容

markdown

undefined

markdown

undefined

Project Constitution

项目规约

Core Values

核心价值观

Simplicity Over Cleverness: Favor straightforward solutions that are easy to understand and maintain over clever optimizations.
User Experience First: Every technical decision should improve or maintain user experience.

简洁优于精巧: 优先选择易于理解和维护的简单解决方案，而非精巧的优化方案。
用户体验优先: 每一项技术决策都应提升或保持用户体验。

Technical Principles

技术原则

Architecture

架构

Prefer composition over inheritance
Keep components loosely coupled
Design for testability

优先组合而非继承
保持组件松耦合
为可测试性而设计

Code Quality

代码质量

Code reviews required for all changes
Unit test coverage > 80%
Documentation for public APIs

所有变更都需要代码审查
单元测试覆盖率 > 80%
公共API需提供文档

Performance

性能

Page load < 3 seconds
API response < 200ms
Progressive enhancement for slower connections

页面加载时间 < 3秒
API响应时间 < 200ms
为低速连接提供渐进式增强

Decision Framework

决策框架

When choosing between approaches:

Does it align with our core values?
Is it maintainable by the team?
Does it scale with our growth?
What's the long-term cost?


</details>

<details>
<summary>📝 Phase 2: Specify</summary>

在选择不同方案时：

是否符合我们的核心价值观？
团队是否能够维护？
是否能随业务增长扩展？
长期成本如何？


</details>

<details>
<summary>📝 阶段2：规格定义</summary>

Specify Phase

规格定义阶段

Define what needs building and why, avoiding technology specifics.

定义需要构建什么以及原因，避免涉及技术细节。

Script Usage

脚本使用

bash

undefined

bash

undefined

Create new feature

创建新功能

.specify/scripts/bash/create-new-feature.sh --json "feature-name"

Expected JSON output:

预期JSON输出:

{"BRANCH_NAME": "001-feature-name", "SPEC_FILE": "/path/to/.specify/specs/001-feature-name/spec.md"}


**Parse JSON**: Extract `BRANCH_NAME` and `SPEC_FILE` for subsequent operations.


**解析JSON**: 提取`BRANCH_NAME`和`SPEC_FILE`用于后续操作。

Template Structure

模板结构

Load

.specify/templates/spec-template.md

to understand required sections, then create specification at

SPEC_FILE

location.

加载

.specify/templates/spec-template.md

了解所需章节，然后在

SPEC_FILE

位置创建规格说明文件。

Specification Content

规格说明内容

Focus on functional requirements:

markdown

undefined

聚焦于功能需求：

markdown

undefined

Feature Specification: [Feature Name]

功能规格说明: [功能名称]

Problem Statement

问题陈述

[What problem are we solving?]

[我们要解决什么问题？]

User Stories

用户故事

Story 1: [Title]

故事1: [标题]

As a [role] I want [capability] So that [benefit]

Acceptance Criteria:

[Specific, testable criterion]
[Specific, testable criterion]

作为[角色] 我希望[能力] 以便[收益]

验收标准:

[具体、可测试的标准]
[具体、可测试的标准]

Story 2: [Title]

故事2: [标题]

[Continue...]

[继续...]

Non-Functional Requirements

非功能需求

Performance: [Specific metrics]
Security: [Requirements]
Accessibility: [Standards]
Scalability: [Expectations]

性能: [具体指标]
安全性: [需求]
可访问性: [标准]
可扩展性: [预期]

Success Metrics

成功指标

[Measurable outcome]
[Measurable outcome]

[可衡量的结果]
[可衡量的结果]

Out of Scope

范围外内容

[Explicitly state what's NOT included]

undefined

[明确说明不包含的内容]

undefined

Key Principles

核心原则

Technology-agnostic: Don't specify "use React" or "MySQL"
Outcome-focused: Describe what user achieves, not how
Testable: Acceptance criteria must be verifiable
Complete: Address edge cases and error scenarios

技术无关: 不要指定“使用React”或“MySQL”
结果导向: 描述用户能达成什么，而非如何实现
可测试: 验收标准必须可验证
完整性: 覆盖边缘情况和错误场景

Git Integration

Git集成

The script automatically:

Creates new feature branch (e.g.,
```
001-feature-name
```
)
Checks out the branch
Initializes spec file

</details> <details> <summary>❓ Phase 3: Clarify</summary>

脚本会自动：

创建新的功能分支（例如：
```
001-feature-name
```
）
切换到该分支
初始化规格文件

</details> <details> <summary>❓ 阶段3：澄清歧义</summary>

Clarify Phase

澄清歧义阶段

Resolve underspecified areas through targeted questioning.

通过针对性提问解决规格说明中不明确的部分。

Purpose

目标

Before planning implementation, ensure specification is complete and unambiguous.

在规划实现前，确保规格说明完整且无歧义。

Process

流程

Analyze Specification
- Read spec.md thoroughly
- Identify ambiguities, gaps, assumptions
- Note areas with multiple valid interpretations
Generate Questions (Maximum 5)
- Prioritize high-impact areas
- Focus on decisions that affect architecture
- Ask about edge cases and error handling
Question Format

markdown

undefined

分析规格说明
- 仔细阅读spec.md
- 识别歧义、空白点、假设
- 标记存在多种合理解释的部分
生成问题（最多5个）
- 优先处理高影响区域
- 聚焦于影响架构的决策
- 询问边缘情况和错误处理方式
问题格式

markdown

undefined

Clarifications

澄清内容

Q1: [Clear, specific question]

Q1: [清晰、具体的问题]

Context: [Why this matters] Options: [If multiple approaches exist]

背景: [为什么这个问题重要] 选项: [如果存在多种方案]

Q2: [Clear, specific question]

Q2: [清晰、具体的问题]

Context: [Why this matters] Impact: [What decisions depend on this]


4. **Update Specification**
   - Add "## Clarifications" section to spec.md
   - Document questions and answers
   - Update relevant sections based on answers
   - Iterate until all critical questions answered

背景: [为什么这个问题重要] 影响: [哪些决策依赖于此]


4. **更新规格说明**
   - 在spec.md中添加“## 澄清内容”章节
   - 记录问题与答案
   - 根据答案更新相关章节
   - 反复迭代直到所有关键问题得到解答

Guidelines

指南

Maximum 5 questions per round
Specific, not general: "How should we handle concurrent edits?" not "How should it work?"
Decision-focused: Questions that inform technical choices
Incremental: Can run multiple clarification rounds

最多5个问题每轮
具体而非笼统: 例如“当两个用户同时编辑同一文档时，系统应如何处理冲突？”而非“它应该如何工作？”
决策导向: 提出能指导技术选择的问题
增量式: 可以进行多轮澄清

Example Questions

示例问题

markdown

undefined

markdown

undefined

Clarifications

澄清内容

Q1: How should the system handle conflicts when two users edit the same document simultaneously?

Q1: 当两个用户同时编辑同一文档时，系统应如何处理冲突？

Context: This affects data model design and user experience. Options:

Last-write-wins (simple, may lose data)
Operational transforms (complex, preserves all edits)
Locked editing (simple, limits collaboration)

Answer: [User provides answer]

背景: 这会影响数据模型设计和用户体验。选项:

最后写入者获胜（简单，但可能丢失数据）
操作转换（复杂，但保留所有编辑）
锁定编辑（简单，但限制协作）

答案: [用户提供的答案]

Q2: What's the maximum number of concurrent users we need to support?

Q2: 我们需要支持的最大并发用户数是多少？

Context: Affects infrastructure planning and architecture decisions. Impact: Determines caching strategy, database choices, and scaling approach.

Answer: [User provides answer]


</details>

<details>
<summary>🏗️ Phase 4: Plan</summary>

背景: 影响基础设施规划和架构决策。影响: 决定缓存策略、数据库选择和扩展方式。

答案: [用户提供的答案]


</details>

<details>
<summary>🏗️ 阶段4：方案规划</summary>

Plan Phase

方案规划阶段

Create technical implementation strategy based on clarified specification.

基于已澄清的规格说明创建技术实现策略。

Script Usage

脚本使用

bash

undefined

bash

undefined

Setup plan phase

设置规划阶段

.specify/scripts/bash/setup-plan.sh --json

Expected JSON output:

预期JSON输出:

{"FEATURE_SPEC": "/path/spec.md", "IMPL_PLAN": "/path/plan.md", "SPECS_DIR": "/path/specs", "BRANCH": "001-feature"}

undefined

undefined

Documents to Create

需要创建的文档

1. Main Plan (

plan.md

)

1. 主规划文件 (

plan.md

)

markdown

undefined

markdown

undefined

Implementation Plan: [Feature Name]

实现规划: [功能名称]

Technology Stack

技术栈

Frontend

前端

Framework: [Choice with rationale]
State Management: [Choice with rationale]
Styling: [Choice with rationale]

框架: [选择与理由]
状态管理: [选择与理由]
样式方案: [选择与理由]

Backend

后端

Language/Framework: [Choice with rationale]
Database: [Choice with rationale]
API Style: [REST/GraphQL/etc with rationale]

语言/框架: [选择与理由]
数据库: [选择与理由]
API风格: [REST/GraphQL等与理由]

Architecture

架构

System Overview

系统概览

mermaid

graph TD
    A[Client] --> B[API Gateway]
    B --> C[Service Layer]
    C --> D[Data Layer]

mermaid

graph TD
    A[Client] --> B[API Gateway]
    B --> C[Service Layer]
    C --> D[Data Layer]

Component Design

组件设计

Component 1: [Name]

组件1: [名称]

Responsibility: [What it does]
Interfaces: [APIs it exposes]
Dependencies: [What it needs]

[Continue for all components...]

职责: [功能描述]
接口: [暴露的API]
依赖: [所需资源]

[继续描述所有组件...]

Design Patterns

设计模式

[Pattern]: [Where and why used]

Security Considerations

安全考虑

Authentication: [Approach]
Authorization: [Approach]
Data Protection: [Approach]

身份认证: [实现方案]
授权机制: [实现方案]
数据保护: [实现方案]

Performance Strategy

性能策略

Caching: [Strategy]
Optimization: [Key areas]

缓存: [策略]
优化: [关键领域]

Error Handling

错误处理

Error types and handling strategies
Logging and monitoring approach

undefined

错误类型与处理策略
日志与监控方案

undefined

2. Data Model (

data-model.md

)

2. 数据模型 (

data-model.md

)

markdown

undefined

markdown

undefined

Data Model

数据模型

Entity Relationship

实体关系

mermaid

erDiagram
    USER ||--o{ DOCUMENT : creates
    USER {
        string id
        string email
        string role
    }
    DOCUMENT {
        string id
        string title
        string content
    }

mermaid

erDiagram
    USER ||--o{ DOCUMENT : creates
    USER {
        string id
        string email
        string role
    }
    DOCUMENT {
        string id
        string title
        string content
    }

Schemas

数据结构

User

用户

typescript

interface User {
  id: string;
  email: string;
  role: 'admin' | 'editor' | 'viewer';
  createdAt: Date;
}

[Continue for all entities...]

undefined

typescript

interface User {
  id: string;
  email: string;
  role: 'admin' | 'editor' | 'viewer';
  createdAt: Date;
}

[继续描述所有实体...]

undefined

3. API Contracts (

contracts/

)

3. API契约 (

contracts/

)

Create API specifications:

```
api-spec.json
```
(OpenAPI/Swagger)
```
signalr-spec.md
```
(if using SignalR)
Other contract definitions

创建API规格说明：

```
api-spec.json
```
(OpenAPI/Swagger格式)
```
signalr-spec.md
```
(如果使用SignalR)
其他契约定义

4. Research (

research.md

) - Optional

4. 技术调研 (

research.md

) - 可选

Document technology investigations:

markdown

undefined

记录技术调研内容：

markdown

undefined

Research: [Topic]

调研: [主题]

Options Evaluated

评估的方案

Option 1: [Technology]

方案1: [技术]

Pros: [Benefits] Cons: [Drawbacks] Fit: [How well it matches our needs]

优点: [优势] 缺点: [劣势] 适配性: [与需求的匹配程度]

Option 2: [Technology]

方案2: [技术]

[Same structure...]

[相同结构...]

Recommendation

References

参考资料

[Source 1]
[Source 2]

undefined

[来源1]
[来源2]

undefined

5. Quick start (

quickstart.md

) - Optional

5. 快速上手 (

quickstart.md

) - 可选

Setup instructions for developers.

为开发者提供设置说明。

Alignment Check

一致性检查

Before finalizing:

✅ Does plan address all requirements?
✅ Does it follow constitution principles?
✅ Are technical choices justified?
✅ Are dependencies identified?
✅ Is it implementable?

</details> <details> <summary>✅ Phase 5: Tasks</summary>

最终确定前，请检查：

✅ 规划是否覆盖所有需求？
✅ 是否遵循规约原则？
✅ 技术选择是否有充分理由？
✅ 依赖关系是否已识别？
✅ 是否可实现？

</details> <details> <summary>✅ 阶段5：任务拆分</summary>

Tasks Phase

任务拆分阶段

Generate dependency-ordered, actionable implementation tasks.

生成按依赖关系排序的可执行开发任务。

Prerequisites Script

前置条件检查脚本

bash

undefined

bash

undefined

Check prerequisites

检查前置条件

.specify/scripts/bash/check-prerequisites.sh --json [--require-tasks] [--include-tasks]

Output: {"FEATURE_DIR": "/path", "AVAILABLE_DOCS": ["spec.md", "plan.md", ...]}

输出: {"FEATURE_DIR": "/path", "AVAILABLE_DOCS": ["spec.md", "plan.md", ...]}

undefined

undefined

Task Generation

任务生成

Create

.specify/specs/NNN-feature/tasks.md

markdown

undefined

创建

.specify/specs/NNN-feature/tasks.md

文件：

markdown

undefined

Implementation Tasks: [Feature Name]

实现任务: [功能名称]

Phase 1: Foundation

阶段1: 基础设置

1.1 Set up project structure
- Create directory layout per architecture doc
- Configure build tools
- Initialize testing framework
- Depends on: None
- Requirement: R1.1
1.2 [P] Configure development environment
- Set up linters and formatters
- Configure CI/CD pipeline basics
- Depends on: 1.1
- Requirement: R1.2

1.1 搭建项目结构
- 根据架构文档创建目录布局
- 配置构建工具
- 初始化测试框架
- 依赖: 无
- 需求: R1.1
1.2 [P] 配置开发环境
- 设置代码检查器与格式化工具
- 配置CI/CD流水线基础
- 依赖: 1.1
- 需求: R1.2

Phase 2: Core Implementation

阶段2: 核心实现

2.1 Implement User model and persistence
- Create User entity with validation
- Implement repository pattern
- Write unit tests
- Depends on: 1.1
- Requirement: R2.1, R2.3
2.2 [P] Implement Document model
- Create Document entity
- Define relationships with User
- Write unit tests
- Depends on: 1.1
- Requirement: R2.2
2.3 Implement API endpoints
- Create REST controllers
- Add request/response validation
- Write integration tests
- Depends on: 2.1, 2.2
- Requirement: R3.1, R3.2

[Continue with all phases...]

2.1 实现用户模型与持久化
- 创建带验证的用户实体
- 实现仓库模式
- 编写单元测试
- 依赖: 1.1
- 需求: R2.1, R2.3
2.2 [P] 实现文档模型
- 创建文档实体
- 定义与用户的关系
- 编写单元测试
- 依赖: 1.1
- 需求: R2.2
2.3 实现API端点
- 创建REST控制器
- 添加请求/响应验证
- 编写集成测试
- 依赖: 2.1, 2.2
- 需求: R3.1, R3.2

[继续所有阶段...]

Phase N: Integration & Testing

阶段N: 集成与测试

N.1 End-to-end testing
- Write E2E test scenarios
- Test critical user paths
- Depends on: [all previous]
- Requirement: All

N.1 端到端测试
- 编写E2E测试场景
- 测试关键用户路径
- 依赖: [所有前置任务]
- 需求: 全部

Notes

说明

```
[P]
```
indicates tasks that can be parallelized
Always check dependencies before starting
Reference requirements for acceptance criteria

undefined

```
[P]
```
表示可并行执行的任务
开始前请务必检查依赖关系
参考需求中的验收标准

undefined

Task Characteristics

任务特征

Each task should:

Be specific and actionable
Reference requirements (R1.1, R2.3, etc.)
List dependencies
Be completable in 1-4 hours
Have clear acceptance criteria

Task Types:

Implementation tasks (write code)
Testing tasks (write tests)
Configuration tasks (set up tools)
Integration tasks (connect components)

Exclude:

Deployment tasks
User training
Marketing activities
Non-coding work

每个任务应满足：

具体且可执行
关联需求（如R1.1, R2.3等）
列出依赖关系
可在1-4小时内完成
有明确的验收标准

任务类型：

实现任务（编写代码）
测试任务（编写测试）
配置任务（设置工具）
集成任务（连接组件）

需排除：

部署任务
用户培训
营销活动
非编码工作

Dependency Markers

依赖标记

None: Can start immediately
1.1: Must complete task 1.1 first
1.1, 2.2: Must complete both first
[P]: Can run in parallel with siblings

</details> <details> <summary>🔍 Phase 6: Analyze</summary>

无: 可立即开始
1.1: 必须先完成任务1.1
1.1, 2.2: 必须先完成这两个任务
[P]: 可与同级任务并行执行

</details> <details> <summary>🔍 阶段6：一致性分析</summary>

Analyze Phase

一致性分析阶段

Cross-artifact consistency and quality validation (read-only).

跨工件的一致性与质量验证（只读操作）。

Purpose

目标

Before implementation, verify:

All requirements covered by tasks
Plan aligns with constitution
No conflicts between documents
No missing dependencies

在实现前，验证：

所有需求都有对应的任务覆盖
规划符合规约原则
文档之间无冲突
无缺失的依赖关系

Analysis Process

分析流程

Read All Documents
- Constitution
- Specification
- Plan
- Data model
- Tasks
Coverage Check

bash

undefined

阅读所有文档
- 项目规约
- 规格说明
- 实现规划
- 数据模型
- 任务列表
需求覆盖检查

bash

undefined

Extract requirements

提取需求

grep -E "R[0-9]+.[0-9]+" spec.md | sort -u > requirements.txt

Extract referenced requirements in tasks

提取任务中引用的需求

grep -E "Requirement.*R[0-9]+" tasks.md | sort -u > covered.txt

Compare

对比差异

comm -23 requirements.txt covered.txt


3. **Consistency Checks**

**Constitution Alignment**:
- Does plan follow stated principles?
- Are architecture choices justified per constitution?

**Requirement Coverage**:
- Is every requirement addressed in tasks?
- Are acceptance criteria testable?

**Technical Coherence**:
- Do data models match spec needs?
- Do API contracts align with plan?
- Are dependencies realistic?

**Task Dependencies**:
- Are all dependencies valid?
- Is critical path identified?
- Any circular dependencies?

4. **Report Findings**

```markdown

comm -23 requirements.txt covered.txt


3. **一致性检查**

**规约对齐**：
- 规划是否遵循既定原则？
- 架构选择是否符合规约中的理由？

**需求覆盖**：
- 每个需求是否都有对应的任务？
- 验收标准是否可测试？

**技术连贯性**：
- 数据模型是否符合规格说明需求？
- API契约是否与规划对齐？
- 依赖关系是否合理？

**任务依赖**：
- 所有依赖是否有效？
- 是否已识别关键路径？
- 是否存在循环依赖？

4. **生成分析报告**

```markdown

Analysis Report

分析报告

✅ Passing Checks

✅ 通过检查项

All requirements covered
Constitution alignment verified
No circular dependencies

所有需求已覆盖
已验证与规约对齐
无循环依赖

⚠️ Warnings

⚠️ 警告

Requirement R3.4 has no corresponding task
Task 5.2 references undefined dependency

需求R3.4没有对应的任务
任务5.2引用了未定义的依赖

🔴 Critical Issues

🔴 严重问题

None found

未发现

Recommendations

建议

Add task for Requirement R3.4
Clarify dependency for task 5.2
Consider breaking task 6.1 into smaller tasks (estimated 8 hours)

undefined

为需求R3.4添加对应任务
明确任务5.2的依赖关系
考虑将任务6.1拆分为更小的任务（预计8小时）

undefined

Guidelines

指南

Read-only: Don't modify documents
Objective: Report facts, not opinions
Actionable: Provide specific recommendations
Prioritized: Critical issues first

</details> <details> <summary>⚙️ Phase 7: Implement</summary>

只读操作: 不要修改文档
客观: 报告事实而非观点
可执行: 提供具体建议
优先级: 先处理严重问题

</details> <details> <summary>⚙️ 阶段7：功能实现</summary>

Implement Phase

功能实现阶段

Execute tasks systematically, respecting dependencies and test-driven development.

系统地执行任务，遵循依赖关系并采用测试驱动开发。

Implementation Strategy

实现策略

Phase-by-Phase Execution
- Complete all Phase 1 tasks before Phase 2
- Respect task dependencies
- Leverage parallel markers [P]
Task Execution Pattern

bash

undefined

分阶段执行
- 完成所有阶段1任务后再开始阶段2
- 遵循任务依赖关系
- 利用并行标记[P]
任务执行模式

bash

undefined

For each task:

对于每个任务：

1. Read context

1. 阅读上下文

cat .specify/specs/001-feature/spec.md cat .specify/specs/001-feature/plan.md cat .specify/specs/001-feature/data-model.md

2. Check dependencies

2. 检查依赖

Verify all depends-on tasks are complete

验证所有依赖任务已完成

3. Implement

3. 实现

Write code per task description

根据任务描述编写代码

4. Test

4. 测试

Write and run tests

编写并运行测试

5. Validate

5. 验证

Check against requirements

对照需求检查

6. Mark complete

6. 标记完成

Update tasks.md: - [x] task completed

更新tasks.md: - [x] 任务已完成


3. **Test-Driven Approach**

For each task:
- Write tests first (when applicable)
- Implement to pass tests
- Refactor while maintaining green tests
- Integration test when connecting components

4. **Quality Checks**

Before marking task complete:
- [ ] Code follows plan architecture
- [ ] Tests written and passing
- [ ] Meets acceptance criteria
- [ ] No obvious bugs
- [ ] Integrated with previous work


3. **测试驱动开发方法**

对于每个任务：
- 先编写测试（适用时）
- 实现代码以通过测试
- 在保持测试通过的同时重构
- 连接组件时进行集成测试

4. **质量检查**

标记任务完成前，请检查：
- [ ] 代码符合规划的架构
- [ ] 已编写测试且全部通过
- [ ] 满足验收标准
- [ ] 无明显bug
- [ ] 已与之前的工作集成

Handling Errors

错误处理

If implementation reveals issues:

Design Issues: Return to plan phase, update plan
Requirement Gaps: Return to specify/clarify, update spec
Technical Blockers: Document, escalate to user

如果实现过程中发现问题：

设计问题: 返回规划阶段，更新规划
需求空白: 返回规格定义/澄清阶段，更新规格说明
技术障碍: 记录问题，升级给用户

Progress Tracking

进度跟踪

Update tasks.md as you go:

markdown

- [x] 1.1 Set up project structure ✓ Complete
- [x] 1.2 [P] Configure development environment ✓ Complete
- [ ] 2.1 Implement User model ← Currently here
- [ ] 2.2 [P] Implement Document model

随时更新tasks.md：

markdown

- [x] 1.1 搭建项目结构 ✓ 已完成
- [x] 1.2 [P] 配置开发环境 ✓ 已完成
- [ ] 2.1 实现用户模型 ← 当前进行中
- [ ] 2.2 [P] 实现文档模型

Completion Criteria

完成标准

File Structure

文件结构

.specify/
├── memory/
│   └── constitution.md              # Phase 1
├── specs/
│   └── 001-feature-name/            # Numbered features
│       ├── spec.md                  # Phase 2
│       ├── plan.md                  # Phase 4
│       ├── data-model.md            # Phase 4
│       ├── contracts/               # Phase 4
│       │   ├── api-spec.json
│       │   └── signalr-spec.md
│       ├── research.md              # Phase 4 (optional)
│       ├── quickstart.md            # Phase 4 (optional)
│       └── tasks.md                 # Phase 5
├── scripts/
│   └── bash/
│       ├── check-prerequisites.sh
│       ├── create-new-feature.sh
│       ├── setup-plan.sh
│       └── common.sh
└── templates/
    ├── spec-template.md
    ├── plan-template.md
    └── tasks-template.md

.specify/
├── memory/
│   └── constitution.md              # 阶段1
├── specs/
│   └── 001-feature-name/            # 带编号的功能模块
│       ├── spec.md                  # 阶段2
│       ├── plan.md                  # 阶段4
│       ├── data-model.md            # 阶段4
│       ├── contracts/               # 阶段4
│       │   ├── api-spec.json
│       │   └── signalr-spec.md
│       ├── research.md              # 阶段4（可选）
│       ├── quickstart.md            # 阶段4（可选）
│       └── tasks.md                 # 阶段5
├── scripts/
│   └── bash/
│       ├── check-prerequisites.sh
│       ├── create-new-feature.sh
│       ├── setup-plan.sh
│       └── common.sh
└── templates/
    ├── spec-template.md
    ├── plan-template.md
    └── tasks-template.md

Workflow Rules

工作流规则

Sequential Phases: Must complete phases in order
Constitution First: Always establish constitution before features
Branch per Feature: Each feature gets its own Git branch
Numbered Features: Use sequential numbering (001, 002, 003)
Script Integration: Use provided bash scripts for consistency
Principle-Driven: All decisions align with constitution

阶段顺序: 必须按顺序完成各个阶段
规约优先: 必须先确立项目规约再开发功能
功能分支: 每个功能对应独立的Git分支
编号功能: 使用连续编号（001, 002, 003）
脚本集成: 使用提供的bash脚本以保持一致性
原则驱动: 所有决策需与项目规约对齐

Summary

总结

Spec-Kit provides a rigorous, constitution-based approach to feature development with clear phases, explicit dependencies, and comprehensive documentation at every step. The workflow ensures alignment from principles through implementation.

Spec-Kit提供了一套严谨的、基于规约的功能开发方法，包含清晰的阶段划分、明确的依赖关系，以及每个步骤的全面文档。该工作流确保从原则定义到最终实现的全程对齐。

Supporting Files

支持文件

For advanced detection logic and automation scripts, see:

Detection Logic - Comprehensive state detection algorithms

如需高级检测逻辑和自动化脚本，请查看：

检测逻辑 - 全面的状态检测算法