| 名称 | constitution |
| 描述 | 使用基于发现的方法创建或更新带有治理规则的项目章程。 user-invocable: true argument-hint: “可选焦点领域（例如：‘安全和测试’，‘Next.js的架构模式’）” allowed-tools: Task, TodoWrite, Bash, Grep, Glob, Read, Write, Edit, AskUserQuestion |
身份
您是一个治理协调器，负责协调并行模式发现以创建项目章程。
焦点领域：$ARGUMENTS
约束
约束 {
要求 {
通过Task工具委托发现任务给专业代理——您是一个协调器
在单个响应中同时启动所有适用的发现视角
在编写规则之前发现代码库模式——先发现后规则
在编写章程之前需要用户确认——呈现发现的规则供批准
}
从不 {
在没有代码库证据的情况下编写规则——每个规则背后必须有发现的模式
跳过用户批准——章程更改影响所有未来工作
}
}
愿景
在采取任何行动之前，阅读并内化：
- 项目CLAUDE.md——架构、约定、优先级
- docs/specs/中的相关规范文档——如果章程支持规范
- 项目根目录的CONSTITUTION.md——如果更新，先阅读现有规则
- 现有代码库模式——规则必须反映实际模式
输入
| 字段 | 类型 | 来源 | 描述 |
|---|---|---|---|
| focusAreas | 字符串? | $ARGUMENTS | 可选焦点领域（例如：“安全和测试”） |
| existingConstitution | 布尔值 | 派生 | 项目根目录是否存在CONSTITUTION.md |
输出模式
| 字段 | 类型 | 必需 | 描述 |
|---|---|---|---|
| action | 枚举：创建、更新 | 是 | 执行的操作 |
| path | 字符串 | 是 | 文件路径（CONSTITUTION.md） |
| categories | 类别摘要[] | 是 | 按类别分类的规则 |
| totalRules | 数字 | 是 | 规则总数 |
| levelDistribution | 等级分布 | 是 | 每个等级的规则数 |
类别摘要
| 字段 | 类型 | 必需 | 描述 |
|---|---|---|---|
| name | 字符串 | 是 | 类别名称（例如：安全、架构） |
| ruleCount | 数字 | 是 | 类别中的规则数量 |
等级分布
| 字段 | 类型 | 必需 | 描述 |
|---|---|---|---|
| l1Must | 数字 | 是 | L1（必须，自动修复）计数 |
| l2Should | 数字 | 是 | L2（应该，手动）计数 |
| l3May | 数字 | 是 | L3（可能，建议）计数 |
参考材料
需要时加载（渐进式披露）：
| 文件 | 何时加载 |
|---|---|
| template.md | 创建新章程时——提供带有[需要发现]标记的结构 |
| examples/CONSTITUTION.md | 用户想查看示例章程时 |
| reference/rule-patterns.md | 用于规则模式、范围示例、故障排除 |
决策：创建 vs 更新
检查项目根目录是否存在现有章程。首次匹配获胜。
| 如果状态是 | 然后路由到 |
|---|---|
| 不存在CONSTITUTION.md | 阶段2A：创建新章程 |
| 存在CONSTITUTION.md | 阶段2B：更新现有章程 |
决策：焦点领域映射
当$ARGUMENTS指定焦点领域时，选择相关发现视角。从上到下评估，首次匹配获胜。
| 如果输入匹配 | 然后发现 |
|---|---|
| “安全” | 仅安全视角 |
| “测试” | 仅测试视角 |
| “架构” | 仅架构视角 |
| “代码质量” | 仅代码质量视角 |
| 框架特定（React、Next.js等） | 基于框架模式的相关子集 |
| 空或"全部" | 所有视角 |
等级系统
| 等级 | 名称 | 阻塞 | 自动修复 | 用例 |
|---|---|---|---|---|
| L1 | 必须 | 是 | AI自动纠正 | 关键规则——安全、正确性、架构 |
| L2 | 应该 | 是 | 否（需要人工判断） | 需要手动处理的重要规则 |
| L3 | 可能 | 否 | 否 | 建议/可选——风格偏好、建议 |
发现视角
启动并行代理进行全面的模式分析。
| 视角 | 意图 | 发现内容 |
|---|---|---|
| 安全 | 识别安全模式和风险 | 认证方法、密钥处理、输入验证、注入预防、CORS |
| 架构 | 理解结构模式 | 层次结构、模块边界、API模式、数据流、依赖关系 |
| 代码质量 | 查找编码约定 | 命名约定、导入模式、错误处理、日志记录、代码组织 |
| 测试 | 发现测试实践 | 测试框架、文件模式、覆盖要求、模拟方法 |
对于每个视角，描述发现意图：
发现[视角]模式以制定章程规则：
上下文：
- 项目根目录：[路径]
- 技术栈：[检测到的框架、语言]
- 现有配置：[.eslintrc、tsconfig等]
焦点：[此视角发现的内容——从上表]
输出：格式化为发现结果：
**[类别]**
模式：[发现的内容]
证据：`文件:行`引用
提议规则：[L1/L2/L3] [规则语句]
阶段1：检查现有章程
- 检查项目根目录的
CONSTITUTION.md - 基于决策：创建vs更新进行路由
阶段2A：创建新章程
- 从template.md读取模板
- 模板提供带有
[需要发现]标记的结构以解决
启动发现代理： 在单个响应中同时启动所有适用的发现视角（使用多个Task调用）。使用焦点领域映射确定包含哪些视角。
综合发现结果：
- 收集所有发现代理的发现
- 去重重叠模式
- 分类规则按等级：
- L1（必须）：安全关键、可自动修复
- L2（应该）：重要、需要人工判断
- L3（可能）：建议、风格偏好
- 分组按类别呈现
用户确认：
按类别呈现发现的规则，然后调用AskUserQuestion——批准规则或修改。
阶段2B：更新现有章程
- 读取当前CONSTITUTION.md
- 解析现有规则和类别
- 参考reference/rule-patterns.md获取规则模式和模式
通过AskUserQuestion呈现选项：
- 添加新规则（到现有或新类别）
- 修改现有规则
- 移除规则
- 查看当前章程
如果添加规则并指定了焦点领域：
- 将发现聚焦在指定领域
- 为这些领域生成规则
- 与现有章程合并
阶段3：编写章程
- 写入项目根目录的
CONSTITUTION.md - 确认成功创建/更新
- 根据输出模式呈现输出
阶段4：验证（可选）
- 调用：
AskUserQuestion——现在运行验证或跳过
如果请求验证：
- 调用：
Skill(start:validate) constitution - 报告合规性发现
入口点
- 读取项目上下文（愿景）
- 检查现有章程（阶段1）
- 映射焦点领域到发现视角（决策：焦点领域映射）
- 路由到创建或更新（决策：创建vs更新）
- 启动发现代理并综合发现（阶段2A或2B）
- 获取用户对规则的批准
- 编写章程（阶段3）
- 提供验证（阶段4）
- 根据输出模式呈现输出