spec-kitty-constitution

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Path reference rule: When you mention directories or files, provide either the absolute path or a path relative to the project root (for example,

kitty-specs/<feature>/tasks/

). Never refer to a folder by name alone.

Path: .kittify/templates/commands/constitution.md

路径参考规则： 当你提及目录或文件时，请提供绝对路径或相对于项目根目录的路径（例如：

kitty-specs/<feature>/tasks/

）。禁止仅通过文件夹名称指代。

路径：.kittify/templates/commands/constitution.md

User Input

用户输入

text

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

text

$ARGUMENTS

你必须在继续操作前考虑用户输入（如果输入不为空）。

What This Command Does

该命令的作用

This command creates or updates the project constitution through an interactive, phase-based discovery workflow.

Location:

.kittify/memory/constitution.md

(project root, not worktrees) Scope: Project-wide principles that apply to ALL features

Important: The constitution is OPTIONAL. All spec-kitty commands work without it.

Constitution Purpose:

Capture technical standards (languages, testing, deployment)
Document code quality expectations (review process, quality gates)
Record tribal knowledge (team conventions, lessons learned)
Define governance (how the constitution changes, who enforces it)

该命令通过交互式、分阶段的调研工作流创建或更新项目章程。

存储位置：

.kittify/memory/constitution.md

（项目根目录，而非工作树） 适用范围：适用于所有功能的项目级原则

重要提示：项目章程是非必需的。所有spec-kitty命令无需章程即可正常运行。

项目章程的作用：

记录技术标准（编程语言、测试、部署相关）
归档代码质量预期（评审流程、质量门禁）
留存团队经验共识（团队约定、经验教训）
定义治理规则（章程的修改方式、执行负责人）

Discovery Workflow

调研工作流

This command uses a 4-phase discovery process:

Phase 1: Technical Standards (Recommended)
- Languages, frameworks, testing requirements
- Performance targets, deployment constraints
- ≈3-4 questions, creates a lean foundation
Phase 2: Code Quality (Optional)
- PR requirements, review checklist, quality gates
- Documentation standards
- ≈3-4 questions
Phase 3: Tribal Knowledge (Optional)
- Team conventions, lessons learned
- Historical decisions (optional)
- ≈2-4 questions
Phase 4: Governance (Optional)
- Amendment process, compliance validation
- Exception handling (optional)
- ≈2-3 questions

Paths:

Minimal (≈1 page): Phase 1 only → ≈3-5 questions
Comprehensive (≈2-3 pages): All phases → ≈8-12 questions

该命令采用四阶段调研流程：

第一阶段：技术标准（推荐完成）
- 编程语言、框架、测试要求
- 性能指标、部署约束
- 约3-4个问题，搭建精简的规范基础
第二阶段：代码质量（可选）
- PR要求、评审检查清单、质量门禁
- 文档标准
- 约3-4个问题
第三阶段：团队经验共识（可选）
- 团队约定、经验教训
- 历史决策（可选）
- 约2-4个问题
第四阶段：治理规则（可选）
- 修订流程、合规校验规则
- 例外处理（可选）
- 约2-3个问题

版本选择：

精简版（约1页）：仅完成第一阶段 → 约3-5个问题
完整版（约2-3页）：完成所有阶段 → 约8-12个问题

Execution Outline

执行大纲

Step 1: Initial Choice

步骤1：初始选择

Ask the user:

Do you want to establish a project constitution?

A) No, skip it - I don't need a formal constitution
B) Yes, minimal - Core technical standards only (≈1 page, 3-5 questions)
C) Yes, comprehensive - Full governance and tribal knowledge (≈2-3 pages, 8-12 questions)

Handle responses:

A (Skip): Create a minimal placeholder at
```
.kittify/memory/constitution.md
```
:
- Title + short note: "Constitution skipped - not required for spec-kitty usage. Run /spec-kitty.constitution anytime to create one."
- Exit successfully.
B (Minimal): Continue with Phase 1 only.
C (Comprehensive): Continue through all phases, asking whether to skip each optional phase.

询问用户：

是否需要创建项目章程？

A) 不，跳过 - 我不需要正式的项目章程
B) 是，精简版 - 仅包含核心技术标准（约1页，3-5个问题）
C) 是，完整版 - 包含完整治理规则和团队经验共识（约2-3页，8-12个问题）

响应处理：

A（跳过）：在
```
.kittify/memory/constitution.md
```
创建精简占位文件：
- 标题+简短说明："已跳过章程创建 - spec-kitty使用无需章程。可随时运行 /spec-kitty.constitution 命令创建章程。"
- 正常退出流程。
B（精简版）：仅继续执行第一阶段。
C（完整版）：依次执行所有阶段，每个可选阶段前询问用户是否跳过。

Step 2: Phase 1 - Technical Standards

步骤2：第一阶段 - 技术标准

Context:

Phase 1: Technical Standards
These are the non-negotiable technical requirements that all features must follow.
This phase is recommended for all projects.

Ask one question at a time:

Q1: Languages and Frameworks

What languages and frameworks are required for this project?
Examples:
- "Python 3.11+ with FastAPI for backend"
- "TypeScript 4.9+ with React 18 for frontend"
- "Rust 1.70+ with no external dependencies"

Q2: Testing Requirements

What testing framework and coverage requirements?
Examples:
- "pytest with 80% line coverage, 100% for critical paths"
- "Jest with 90% coverage, unit + integration tests required"
- "cargo test, no specific coverage target but all features must have tests"

Q3: Performance and Scale Targets

What are the performance and scale expectations?
Examples:
- "Handle 1000 requests/second at p95 < 200ms"
- "Support 10k concurrent users, 1M daily active users"
- "CLI operations complete in < 2 seconds"
- "N/A - performance not a primary concern"

Q4: Deployment and Constraints

What are the deployment constraints or platform requirements?
Examples:
- "Docker-only, deployed to Kubernetes"
- "Must run on Ubuntu 20.04 LTS without external dependencies"
- "Cross-platform: Linux, macOS, Windows 10+"
- "N/A - no specific deployment constraints"

上下文提示：

第一阶段：技术标准
这是所有功能必须遵守的硬性技术要求。
推荐所有项目完成该阶段。

每次仅询问一个问题：

Q1: 编程语言与框架

本项目要求使用哪些编程语言和框架？
示例：
- "Python 3.11+ 搭配 FastAPI 用于后端开发"
- "TypeScript 4.9+ 搭配 React 18 用于前端开发"
- "Rust 1.70+，无外部依赖"

Q2: 测试要求

有哪些测试框架和覆盖率要求？
示例：
- "pytest ，行覆盖率80%，核心路径覆盖率100%"
- "Jest ，覆盖率90%，要求编写单元+集成测试"
- "cargo test，无明确覆盖率要求，但所有功能必须有对应测试"

Q3: 性能与扩容指标

性能和扩容预期是怎样的？
示例：
- "Handle 1000 requests/second at p95 < 200ms"
- "支持1万并发用户，100万日活用户"
- "CLI操作执行完成时间<2秒"
- "无要求 - 性能不是核心关注点"

Q4: 部署与约束

有哪些部署约束或平台要求？
示例：
- "仅支持Docker镜像，部署到Kubernetes"
- "必须运行在Ubuntu 20.04 LTS上，无外部依赖"
- "跨平台支持：Linux、macOS、Windows 10+"
- "无要求 - 无特定部署约束"

Step 3: Phase 2 - Code Quality (Optional)

步骤3：第二阶段 - 代码质量（可选）

Ask only if comprehensive path is selected:

Phase 2: Code Quality
Skip this if your team uses standard practices without special requirements.

Do you want to define code quality standards?
A) Yes, ask questions
B) No, skip this phase (use standard practices)

If yes, ask one at a time:

Q5: PR Requirements

What are the requirements for pull requests?
Examples:
- "2 approvals required, 1 must be from core team"
- "1 approval required, PR must pass CI checks"
- "Self-merge allowed after CI passes for maintainers"

Q6: Code Review Checklist

What should reviewers check during code review?
Examples:
- "Tests added, docstrings updated, follows PEP 8, no security issues"
- "Type annotations present, error handling robust, performance considered"
- "Standard review - correctness, clarity, maintainability"

Q7: Quality Gates

What quality gates must pass before merging?
Examples:
- "All tests pass, coverage ≥80%, linter clean, security scan clean"
- "Tests pass, type checking passes, manual QA approved"
- "CI green, no merge conflicts, PR approved"

Q8: Documentation Standards

What documentation is required?
Examples:
- "All public APIs must have docstrings + examples"
- "README updated for new features, ADRs for architectural decisions"
- "Inline comments for complex logic, keep docs up to date"
- "Minimal - code should be self-documenting"

仅当用户选择完整版时询问：

第二阶段：代码质量
如果你的团队使用通用标准无特殊要求，可跳过该阶段。

是否需要定义代码质量标准？
A) 是，开始提问
B) 否，跳过该阶段（使用通用标准）

如果选择是，依次询问以下问题：

Q5: PR要求

拉取请求（PR）有哪些要求？
示例：
- "需要2个审批，其中1个必须来自核心团队"
- "需要1个审批，PR必须通过CI检查"
- "维护者CI通过后可自行合并"

Q6: 代码评审检查清单

代码评审时评审人需要检查哪些内容？
示例：
- "新增测试、更新文档字符串、符合PEP 8规范、无安全问题"
- "存在类型注解、错误处理健壮、考虑性能影响"
- "标准评审项：正确性、清晰度、可维护性"

Q7: 质量门禁

合并前必须通过哪些质量门禁？
示例：
- "所有测试通过、覆盖率≥80%、linter检查通过、安全扫描无问题"
- "测试通过、类型检查通过、手动QA验收通过"
- "CI运行正常、无合并冲突、PR已获审批"

Q8: 文档标准

有哪些文档要求？
示例：
- "所有公共API必须有文档字符串+使用示例"
- "新功能需更新README，架构决策需要编写ADR"
- "复杂逻辑需要加行内注释，保持文档同步更新"
- "最低要求 - 代码应做到自解释"

Step 4: Phase 3 - Tribal Knowledge (Optional)

步骤4：第三阶段 - 团队经验共识（可选）

Ask only if comprehensive path is selected:

Phase 3: Tribal Knowledge
Skip this for new projects or if team conventions are minimal.

Do you want to capture tribal knowledge?
A) Yes, ask questions
B) No, skip this phase

If yes, ask:

Q9: Team Conventions

What team conventions or coding styles should everyone follow?
Examples:
- "Use Result<T, E> for fallible operations, never unwrap() in prod"
- "Prefer composition over inheritance, keep classes small (<200 lines)"
- "Use feature flags for gradual rollouts, never merge half-finished features"

Q10: Lessons Learned

What past mistakes or lessons learned should guide future work?
Examples:
- "Always version APIs from day 1"
- "Write integration tests first"
- "Keep dependencies minimal - every dependency is a liability"
- "N/A - no major lessons yet"

Optional follow-up:

Do you want to document historical architectural decisions?
A) Yes
B) No

Q11: Historical Decisions (only if yes)

Any historical architectural decisions that should guide future work?
Examples:
- "Chose microservices for independent scaling"
- "Chose monorepo for atomic changes across services"
- "Chose SQLite for simplicity over PostgreSQL"

仅当用户选择完整版时询问：

第三阶段：团队经验共识
新项目或团队约定较少时可跳过该阶段。

是否需要留存团队经验共识？
A) 是，开始提问
B) 否，跳过该阶段

如果选择是，询问以下问题：

Q9: 团队约定

有哪些团队约定或编码风格需要所有人遵守？
示例：
- "使用Result<T, E>处理易错操作，生产环境禁止使用unwrap()"
- "优先使用组合而非继承，保持类大小<200行"
- "使用特性开关做灰度发布，禁止合并半完成的功能"

Q10: 经验教训

有哪些过往错误或经验教训可指导后续工作？
示例：
- "API从第一天开始就要做版本控制"
- "优先编写集成测试"
- "尽量减少依赖 - 每个依赖都是潜在风险"
- "无 - 暂无重大经验教训"

可选后续问题：

是否需要归档历史架构决策？
A) 是
B) 否

Q11: 历史决策（仅当用户选择是时询问）

有哪些需要指导后续工作的历史架构决策？
示例：
- "选择微服务架构是为了支持独立扩容"
- "选择单体仓库是为了支持跨服务原子变更"
- "选择SQLite而非PostgreSQL是为了简化实现"

Step 5: Phase 4 - Governance (Optional)

步骤5：第四阶段 - 治理规则（可选）

Ask only if comprehensive path is selected:

Phase 4: Governance
Skip this to use simple defaults.

Do you want to define governance process?
A) Yes, ask questions
B) No, skip this phase (use simple defaults)

If skipped, use defaults:

Amendment: Any team member can propose changes via PR
Compliance: Team validates during code review
Exceptions: Discuss with team, document in PR

If yes, ask:

Q12: Amendment Process

How should the constitution be amended?
Examples:
- "PR with 2 approvals, announce in team chat, 1 week discussion"
- "Any maintainer can update via PR"
- "Quarterly review, team votes on changes"

Q13: Compliance Validation

Who validates that features comply with the constitution?
Examples:
- "Code reviewers check compliance, block merge if violated"
- "Team lead reviews architecture"
- "Self-managed - developers responsible"

Optional follow-up:

Do you want to define exception handling?
A) Yes
B) No

Q14: Exception Handling (only if yes)

How should exceptions to the constitution be handled?
Examples:
- "Document in ADR, require 3 approvals, set sunset date"
- "Case-by-case discussion, strong justification required"
- "Exceptions discouraged - update constitution instead"

仅当用户选择完整版时询问：

第四阶段：治理规则
使用简单默认规则可跳过该阶段。

是否需要定义治理流程？
A) 是，开始提问
B) 否，跳过该阶段（使用简单默认规则）

如果跳过，使用默认规则：

章程修订：任何团队成员都可通过PR提交修改建议
合规校验：代码评审时团队成员校验合规性
例外处理：团队内部讨论，在PR中归档说明

如果选择是，询问以下问题：

Q12: 修订流程

项目章程如何修订？
示例：
- "PR需2个审批，团队群同步公告，预留1周讨论时间"
- "任何维护者都可通过PR更新"
- "每季度评审一次，团队投票决定变更"

Q13: 合规校验

谁负责校验功能符合章程要求？
示例：
- "代码评审人检查合规性，违反要求则阻止合并"
- "团队负责人评审架构"
- "自管理 - 开发者自行负责"

可选后续问题：

是否需要定义例外处理规则？
A) 是
B) 否

Q14: 例外处理（仅当用户选择是时询问）

违反章程的例外情况如何处理？
示例：
- "在ADR中归档，需要3个审批，设置失效日期"
- "逐案讨论，需要充分的正当理由"
- "不鼓励例外情况 - 建议优先更新章程"

Step 6: Summary and Confirmation

步骤6：摘要与确认

Present a summary and ask for confirmation:

Constitution Summary
====================

You've completed [X] phases and answered [Y] questions.
Here's what will be written to .kittify/memory/constitution.md:

Technical Standards:
- Languages: [Q1]
- Testing: [Q2]
- Performance: [Q3]
- Deployment: [Q4]

[If Phase 2 completed]
Code Quality:
- PR Requirements: [Q5]
- Review Checklist: [Q6]
- Quality Gates: [Q7]
- Documentation: [Q8]

[If Phase 3 completed]
Tribal Knowledge:
- Conventions: [Q9]
- Lessons Learned: [Q10]
- Historical Decisions: [Q11 if present]

Governance: [Custom if Phase 4 completed, otherwise defaults]

Estimated length: ≈[50-80 lines minimal] or ≈[150-200 lines comprehensive]

Proceed with writing constitution?
A) Yes, write it
B) No, let me start over
C) Cancel, don't create constitution

Handle responses:

A: Write the constitution file.
B: Restart from Step 1.
C: Exit without writing.

展示摘要并请求用户确认：

项目章程摘要
====================

你已完成[X]个阶段，回答了[Y]个问题。
以下内容将写入 .kittify/memory/constitution.md 文件：

技术标准：
- 编程语言与框架：[Q1回答]
- 测试要求：[Q2回答]
- 性能指标：[Q3回答]
- 部署约束：[Q4回答]

[如果完成第二阶段则展示]
代码质量：
- PR要求：[Q5回答]
- 评审检查清单：[Q6回答]
- 质量门禁：[Q7回答]
- 文档标准：[Q8回答]

[如果完成第三阶段则展示]
团队经验共识：
- 团队约定：[Q9回答]
- 经验教训：[Q10回答]
- 历史决策：[如果有Q11回答则展示]

治理规则：[如果完成第四阶段则展示自定义规则，否则展示默认规则]

预估长度：精简版约[50-80行] / 完整版约[150-200行]

是否确认写入章程？
A) 是，写入文件
B) 否，重新开始
C) 取消，不创建章程

响应处理：

A：写入章程文件。
B：从步骤1重新开始。
C：直接退出，不写入任何内容。

Step 7: Write Constitution File

步骤7：写入章程文件

Generate the constitution as Markdown:

markdown

undefined

生成Markdown格式的章程：

markdown

undefined

[PROJECT_NAME] Constitution

[PROJECT_NAME] 章程

Auto-generated by spec-kitty constitution command Created: [YYYY-MM-DD] Version: 1.0.0

由spec-kitty constitution命令自动生成创建时间：[YYYY-MM-DD] 版本：1.0.0

Purpose

作用

This constitution captures the technical standards, code quality expectations, tribal knowledge, and governance rules for [PROJECT_NAME]. All features and pull requests should align with these principles.

本章程记录了[PROJECT_NAME]的技术标准、代码质量预期、团队经验共识和治理规则。所有功能和PR都应符合这些原则。

Technical Standards

技术标准

Languages and Frameworks

编程语言与框架

[Q1]

[Q1回答]

Testing Requirements

测试要求

[Q2]

[Q2回答]

Performance and Scale

性能与扩容指标

[Q3]

[Q3回答]

Deployment and Constraints

部署与约束

[Q4]

[If Phase 2 completed]

[Q4回答]

[如果完成第二阶段则展示]

Code Quality

代码质量

Pull Request Requirements

PR要求

[Q5]

[Q5回答]

Code Review Checklist

代码评审检查清单

[Q6]

[Q6回答]

Quality Gates

质量门禁

[Q7]

[Q7回答]

Documentation Standards

文档标准

[Q8]

[If Phase 3 completed]

[Q8回答]

[如果完成第三阶段则展示]

Tribal Knowledge

团队经验共识

Team Conventions

团队约定

[Q9]

[Q9回答]

Lessons Learned

经验教训

[Q10]

[If Q11 present]

[Q10回答]

[如果有Q11回答则展示]

Historical Decisions

历史决策

[Q11]

[Q11回答]

Governance

治理规则

[If Phase 4 completed]

[如果完成第四阶段则展示]

Amendment Process

修订流程

[Q12]

[Q12回答]

Compliance Validation

合规校验

[Q13]

[If Q14 present]

[Q13回答]

[如果有Q14回答则展示]

Exception Handling

例外处理

[Q14]

[If Phase 4 skipped, use defaults]

[Q14回答]

[如果跳过第四阶段则使用默认规则]

Amendment Process

修订流程

Any team member can propose amendments via pull request. Changes are discussed and merged following standard PR review process.

任何团队成员都可通过PR提交修订建议。变更按照标准PR评审流程讨论合并。

Compliance Validation

合规校验

Code reviewers validate compliance during PR review. Constitution violations should be flagged and addressed before merge.

代码评审人在PR评审时校验合规性。违反章程的问题应在合并前修复。

Exception Handling

例外处理

Exceptions discussed case-by-case with team. Strong justification required. Consider updating constitution if exceptions become common.

undefined

例外情况由团队逐案讨论，需要充分的正当理由。如果例外情况频繁出现，考虑更新章程。

undefined

Step 8: Success Message

步骤8：成功提示

After writing, provide:

Location of the file
Phases completed and questions answered
Next steps (review, share with team, run /spec-kitty.specify)

写入完成后，向用户提供以下信息：

文件存储位置
完成的阶段数和回答的问题数
后续步骤（评审、同步给团队、运行 /spec-kitty.specify命令）

Required Behaviors

要求行为

Ask one question at a time.
Offer skip options and explain when to skip.
Keep responses concise and user-focused.
Ensure the constitution stays lean (1-3 pages, not 10 pages).
If user chooses to skip entirely, still create the minimal placeholder file and exit successfully.

每次仅询问一个问题。
提供跳过选项，并说明适用的跳过场景。
保持回复简洁，以用户需求为核心。
确保章程内容精简（1-3页，不要超过10页）。
如果用户选择完全跳过，仍需创建精简占位文件并正常退出。