Menü
实现 + 调试全部完成后，扫描活跃计划、聚合同主题的多轮迭代计划、归档并生成最终代码事实设计文档
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
文档审查技能。将文档审查任务派发给独立子代理，重点审查文档基于代码改动的合理性、说明正确性、前后一致性、错漏和逻辑谬误，以及 AI 实现过程中产生的决策记录（implementation-notes.md）。当用户需要审查技术文档、spec文档、设计文档、计划文档、API文档、README 或任何与代码改动相关的文档时使用。
代码修改场景下，spec 文档确认后，需要继续以图优先方式梳理结构体定义、数据流和流程时使用
用户需要绘制架构图、流程图、数据流图、对比图时使用。AI 直接按规范手写 ASCII 图到 .md，不经过 PlantUML。
在代码修改前需要编写 spec 文档且应优先用图表达边界、入口、流程和改动关系时使用（仅限代码改动场景，非项目级架构文档初始化）
进行代码提交时触发。提供统一的提交标题（Conventional Commits）、正文模板、字段含义、写作风格和正反示例。应由 git-commit-standard 等提交流程 skill 强制加载。
在当前会话里按已写好的实现计划顺序执行任务时使用
| name | ddev-archive |
| description | 实现 + 调试全部完成后，扫描活跃计划、聚合同主题的多轮迭代计划、归档并生成最终代码事实设计文档 |
把同一主题下经过多轮迭代（初始计划、调试迭代、最终版本）的所有活跃计划归档到一个日期目录，并生成一份 final-spec.md 记录最终代码事实设计。
开始时声明： "正在使用 ddev-archive skill 归档变更。"
不使用的情况：
docs/plans/archive/YYYY-MM-DD/
├── 01_initial/ ← 初始计划（最早的 spec/detail/exec_plans）
│ ├── spec/
│ ├── detail/
│ └── exec_plans/
├── 02_iter1/ ← 调试后迭代 1（如有）
│ ├── spec/
│ ├── detail/
│ └── exec_plans/
├── 03_iter2/ ← 调试后迭代 2（如有）
│ └── ...
├── 04_final/ ← 最终版本（如有独立 plan）
│ └── ...
├── final-spec.md ← 综合所有迭代的最终代码事实设计
└── archive-notes.md ← 归档说明（可选，记录归档决策和未决项）
YYYY-MM-DD 为归档日期（当天）01_ / 02_ 保持时间顺序01_initial/ + final-spec.mddocs/plans/ 目录（排除 archive/ 子目录），列出所有与本次主题相关的计划目录。usb-hid、usb_hid、hid-report）按日期和时间顺序排列所有相关计划目录：
01_initial（初始计划）02_iter1、03_iter2...0N_final（最终版本）如果只有一个计划目录，直接标记为 01_initial。
分类规则：
对每个迭代目录，读取以下关键文件：
基于所有迭代文档的对比分析，生成最终代码事实设计文档。
docs/plans/archive/YYYY-MM-DD/final-spec.md
# [功能名] — 最终代码事实设计
> **归档日期**: YYYY-MM-DD | **迭代次数**: N | **最终版本**: 0N_final
>
> 本文档综合 [N] 轮迭代的设计文档，记录经过实机调试后的最终代码事实。
> 如与某轮迭代的设计存在差异，以本文档为准。
## 1. 变更面总览 (Delta Summary)
| 类型 | 对象 | 最终状态 |
|------|------|---------|
| ADDED | ... | ... |
| MODIFIED | ... | ... |
| REMOVED | ... | ... |
> 此表综合所有迭代的最终结果。与初始计划的差异在 §2 中说明。
## 2. 与原计划的关键差异
| 迭代 | 原计划 | 最终实现 | 原因 |
|------|--------|---------|------|
| 01_initial | [初始设计要点] | [实际落地情况] | [调试发现/框架约束/...] |
| 02_iter1 | [迭代1调整] | [实际落地情况] | ... |
> 如果只有一轮且无差异，写"实现与初始 plan 一致，无偏离"。
## 3. 最终架构总览
(ASCII 图 — ddev-diagram 规范 — 反映最终代码的模块边界和调用关系)
## 4. 最终核心数据结构
(经过调试确认的最终结构体、枚举、状态机定义)
每个结构体/枚举必须标注：
- 来源：来自 `01_initial/detail/structures/xxx.md`，在 `02_iter1` 中修改了字段 Y
- 如果与任何一轮设计文档不同，标注差异
## 5. 最终核心流程
(ASCII 图 — 反映最终代码的实际数据流和关键流程)
## 6. 调试发现的问题及修复
### Bug 1: [标题]
| 项目 | 内容 |
|------|------|
| 发现于 | 0N_iterX |
| 症状 | ... |
| 根因 | ... |
| 修复 | ... |
| 影响的设计文档 | 0N_iterX 的 spec/detail 中 xxx 部分 |
## 7. 未覆盖风险与已知限制
- [风险/限制 1]：[说明及缓解措施]
- [风险/限制 2]：[说明及缓解措施]
## 8. 设计决策记录
| 决策 | 触发迭代 | 决策内容 | 替代方案（为什么没选） |
|------|---------|---------|---------------------|
| ... | 02_iter1 | ... | ... |
在任何 ASCII 图动笔之前，必须执行 Skill("ddev-diagram") 加载绘制规范。
docs/plans/archive/YYYY-MM-DD/0N_xxx/ 子目录final-spec.md 写入归档根目录docs/plans/ 下的活跃计划目录（移动后清理）如果存在以下情况，创建 archive-notes.md：
# 归档说明
> 归档日期：YYYY-MM-DD
## 归档范围
- 0N_iterX：简述
- ...
## 未归档内容
- [如果有相关但未纳入归档的文件，说明原因]
## 未决项
- [Open Questions 中仍未解决的问题]
优先画：
不需要画：
ddev-exec（实现）+ 实机调试（可能产生多轮迭代 plan）ddev-diagram（画图规范）neat-freak（归档清理时引用 final-spec.md）final-spec.md 为最终权威版本归档完成后逐项核对：
.h 中的实际定义一致？docs/plans/ 下的活跃计划目录是否已移除？