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集成，为功能开发提供7阶段的章程驱动工作流。

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/

目录中创建文件，采用编号方式管理功能

References

参考资料

For detailed detection logic and status checks, see
```
helpers/detection-logic.md
```
.
For a runnable status report, use
```
scripts/detect-phase.sh
```
.

如需了解详细的检测逻辑和状态检查，请查看
```
helpers/detection-logic.md
```
。
如需生成可运行的状态报告，请使用
```
scripts/detect-phase.sh
```
。

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 codex

Initialize new project

初始化新项目

specify init <project-name> --ai codex

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[客户端] --> B[API网关]
    B --> C[服务层]
    C --> D[数据层]

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提供了一套严谨的、基于章程的功能开发方法，包含清晰的阶段划分、明确的依赖关系，以及每个环节的完整文档。该工作流确保从原则定义到落地实现的全程对齐。