sync-dev-spec
同步设计规约技能:检查 code-deconstruct 产物完整性(缺失则先执行 code-deconstruct),将描述性设计文档提炼为规范性开发规约,对不一致与未决点向用户裁决,写入 AGENTS.md 纳入日常开发约束
Source facts
- Repository
- hellyguo/self-ai-spec
- Last source activity
- October 12, 2026 at 03:39
- Detected SKILL.md language
- Chinese
- Stars
- 8
- Forks
- 0
Install options
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Review the source files
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
File Explorer
3 filesShowing SKILL.md
SKILL.md
Source instructions · Read-only preview- name
- sync-dev-spec
- description
- 同步设计规约技能:检查 code-deconstruct 产物完整性(缺失则先执行 code-deconstruct),将描述性设计文档提炼为规范性开发规约,对不一致与未决点向用户裁决,写入 AGENTS.md 纳入日常开发约束
# sync-dev-spec - 设计规约同步
<HARD-GATE>
**强制约束:规约必须源于代码事实**
1. 未确认 code-deconstruct 产物完整(缺失则先执行 code-deconstruct),禁止提炼规约。
2. 每条规约必须有代码依据(引用 `docs/deconstruct/` 的具体文档),禁止凭空生成规约。
3. 不一致点与未决点必须向用户裁决,不得由 AI 擅自统一风格。
4. 规约必须写入当前项目 `AGENTS.md` 的 `## 设计规约` 章节,方可结束。
违反以上约束视为执行失败,必须回到对应阶段重做。
</HARD-GATE>
## 目的
code-deconstruct 产出的是**描述性**文档(设计是什么样),本技能将其转化为**规范性**规约(必须是什么样,偏离即违规),固化到 `AGENTS.md`,使后续所有 AI 会话的编码、审查、重构有统一标尺。规约从代码事实中提炼,不来自预设选项菜单,因此对任意形态的项目均适用。
## 核心原则
1. **事实先行**:先有 code-deconstruct 的解构产物,后有规约
2. **描述转规范**:把"用了分层架构"转写为"新增模块必须遵循 X 分层,禁止 Y"
3. **条条有据**:每条规约标注依据文档路径,可追溯、可质疑
4. **裁决归用户**:风格冲突与未决取舍由用户定夺,AI 只呈现证据与候选
## 执行流程
```mermaid
flowchart TD
A[触发 sync-dev-spec] --> B[检查 code-deconstruct 产物完整性]
B --> C{完整?}
C -- 否 --> D[执行 code-deconstruct]
D --> B
C -- 是 --> E[通读解构产物]
E --> F[提炼规约条目: 决策+理由+约束+适用范围]
F --> G[识别不一致/未决/缺失点]
G --> H{存在需裁决项?}
H -- 是 --> I[向用户呈现证据与候选, 裁决]
I --> F
H -- 否 --> J[生成设计规约文档]
J --> K[写入 AGENTS.md 的 设计规约 章节]
K --> L[向用户确认生效]
L -- 有异议 --> F
L -- 确认 --> M[规约生效: 日常开发约束]
```
## Phase 1: 产物完整性检查
### 必需产物
| 产物 | 说明 |
| :--- | :--- |
| `docs/deconstruct/classes_graph.puml` | 主干类图 |
| `docs/deconstruct/core_data_flow.puml` 或 `.md` | 核心数据流 |
| `docs/deconstruct/global_design.md` | 全项目设计细节 |
| `docs/deconstruct/arch_design_summary.md` | 架构设计总结 |
| `docs/deconstruct/design_{package}/design.md` | 分模块设计(至少一个模块) |
### 条件产物
| 产物 | 条件 |
| :--- | :--- |
| `docs/deconstruct/database/`(inventory、ER 图、database_design.md) | 项目含数据库时必需 |
| `docs/deconstruct/algorithm_{package}/algorithm.md` | 存在核心算法时必需 |
| `docs/deconstruct/memory_usage.md` | 长运行或资源敏感项目应有 |
| `docs/deconstruct/network_usage.md` | 含网络通信时应有 |
### 检查处理
- 必需产物缺失:停止,先完整执行 `code-deconstruct` 技能,产物生成后重新检查
- 条件产物缺失且对应条件成立:同样回到 `code-deconstruct` 补齐
- 条件产物缺失但条件不成立:记录"该项目无此类产物",继续
- 产物存在但内容空洞(模板占位符未填充、与代码明显不符):视同缺失
## Phase 2: 提炼规约
### 产物到规约的映射
| 解构产物 | 提炼的规约方向 |
| :--- | :--- |
| `arch_design_summary.md` | 架构模式规约:分层形态、依赖方向、模式使用边界 |
| `global_design.md` | 全局规约:公共组件、横切关注点(日志、异常、配置)的统一方式 |
| `core_data_flow` | 数据流规约:调用链形态、禁止的跨层/反向调用、异步边界 |
| `design_{package}/design.md` | 模块规约:模块职责边界、对外接口形态、模块间依赖规则 |
| `classes_graph.puml` | 组织规约:命名体系、类的组织与可见性习惯 |
| `database/` | 数据访问规约:SQL 风格、事务边界、对象-表映射方式 |
| `algorithm_{package}/algorithm.md` | 算法实现规约:核心算法的实现方式与替换限制 |
| `memory_usage.md` | 资源规约:资源释放方式、集合与缓存使用限制 |
| `network_usage.md` | 通信规约:序列化方式、超时与重试习惯 |
### 条目格式
每条规约包含五个字段,缺一不可:
| 字段 | 内容 |
| :--- | :--- |
| 编号 | `DS-{seq}`(Design Spec) |
| 约束 | 必须 / 禁止 / 建议 + 一句话表述 |
| 理由 | 为什么代码事实支持这条约束 |
| 依据 | `docs/deconstruct/` 下的具体文档路径与章节 |
| 适用范围 | 全局 / 指定模块 / 指定场景 |
### 提炼要求
- 条目按"必须遵守 / 禁止事项 / 新增代码规约"三类组织
- 从代码归纳时保留项目特有习惯(如该项目的异常处理方式、日志规范),不套用通用最佳实践
- 通用最佳实践只在代码已有体现时才收录,代码没有的不写入
- 规约条目总数控制在 50 条以内,超出则合并或只保留高频触碰项
### 需裁决项识别
提炼过程中识别三类问题,向用户呈现证据与候选后裁决:
| 类型 | 定义 | 呈现方式 |
| :--- | :--- | :--- |
| 不一致 | 同类问题在不同模块用了不同做法 | 列出各做法及所在模块、代码量占比,给出候选统一方向 |
| 未决 | 决策在用但无明确理由(如选了某框架但无说明) | 列出现状做法,询问"固化为规约"还是"标记为待重构" |
| 缺失 | 关键环节无统一做法(各写各的) | 列出现状散点,给出候选统一方案 |
## Phase 3: 写入 AGENTS.md
### 完整规约文档
先将完整规约(含依据、理由、裁决记录)落盘到 `docs/dev-spec/design-charter.md`,使用模板 `templates/design-charter.md`。这是规约的事实源,AGENTS.md 章节与之互链。
### AGENTS.md 章节
在项目 `AGENTS.md` 写入独立章节 `## 设计规约`,使用模板 `templates/agents-section.md`:
- 已存在该章节:整体更新,不重复追加
- 内容:规约条目清单(编号 + 约束一句话表述)、规约文档路径、生效日期
- 精简:AGENTS.md 只放约束条目本身,理由与依据保留在规约文档,两处以路径互链
### 确认生效
向用户展示规约摘要与裁决结果,请求确认:
```text
设计规约已生成(docs/dev-spec/design-charter.md),共 N 条:
- 必须遵守:X 条
- 禁止事项:Y 条
- 新增代码规约:Z 条
裁决结果:{不一致/未决/缺失项的处理结论}
执行结论已写入 AGENTS.md 的 "设计规约" 章节。
是否确认生效?
```
| 反馈 | 处理 |
| :--- | :--- |
| 确认 | 规约生效 |
| 修改某条目 | 修订该条目,重新确认 |
| 取消 | 终止,清除未确认的写入 |
## Phase 4: 纳入日常开发约束
规约生效后,作为后续工作的强制标尺:
| 场景 | 应用方式 |
| :--- | :--- |
| 编码 | 新增代码必须符合"新增代码规约"与对应模块规约 |
| 代码审查 | 命中"禁止事项"即为必须修复项,偏离其他条目为发现项 |
| 局部修改 | 修改前核对是否触碰规约约束,触碰则先回到规约修订流程 |
| 重构 | 重构目标不得与规约冲突,冲突则先与用户修订规约 |
| 规约失效 | 代码演进导致某条规约不再符合事实时,重新执行本技能同步 |
### 同步机制
本技能可重复执行。以下时机应重新运行:
- 大规模重构或新模块落地后
- `docs/deconstruct/` 产物更新后
- 用户认为规约与代码事实脱节时
重跑时以现有 `AGENTS.md` 章节与规约文档为基线,只更新变化条目并记录变更历史,不推倒重写。
如前次已经执行过一轮,将前次执行的结果移动到 `docs/dev-spec/dev-spec_{YYYYMMDD}_{seq%000}` 下,然后再重新生成
## 异常处理
| 情况 | 处理 |
| :--- | :--- |
| `docs/deconstruct/` 不存在 | 先执行 `code-deconstruct`,完成后再继续 |
| 解构产物与当前代码不符(产物过期) | 视同缺失,重新执行 `code-deconstruct` |
| 用户拒绝裁决某项 | 按代码中占多数的做法拟定规约,标注"默认沿用多数做法" |
| 规约条目与 AGENTS.md 既有内容冲突 | 报告冲突点,由用户裁决保留或合并 |
| 项目无数据库/无网络等条件产物 | 记录不适用,跳过对应规约方向 |
## 执行检查清单
**检查阶段:**
- [ ] code-deconstruct 必需产物齐全且非空洞
- [ ] 条件产物按项目条件核对完毕
**提炼阶段:**
- [ ] 每条规约含编号/约束/理由/依据/适用范围五字段
- [ ] 不一致、未决、缺失点已向用户裁决
- [ ] 未收录代码中不存在的通用最佳实践
**落盘阶段:**
- [ ] 完整规约文档已生成 `docs/dev-spec/design-charter.md`
- [ ] `AGENTS.md` 的 `## 设计规约` 章节已写入并互链
- [ ] 用户已确认生效
View on GitHub