完成 Issue 实现与评审后，把设计决策、规格偏离…

在 Issue 完成实现和评审/修复后、发布前，需要记录实现如何解释或偏离规格时使用。

适用场景

解决思路

1. 确认当前已完成 `/goal` 实现和 `/review-it` 评审/修复，然后进入记录笔记流程。
2. 从上下文确定 Issue 编号：用户直接提供时使用（如 `/note-it #42`）；当前分支名为 `feat/issue-42-*` 或 `fix/issue-42-*` 时提取其中的 `42`；最近一次 `/goal` 目标是 `#42` 时使用 `42`；否则询问用户「Which Issue number should I use for the notes file?」。
3. 对照 Issue spec / PRD 审查本次实现，找出实现如何偏离规格或如何解释规格。
4. 在 `docs/` 下生成 HTML 笔记文件，文件名为 `issue#XXXX.html`，其中 XXXX 为补零的 Issue 编号，例如 `issue#0042.html`；若 `docs/` 不存在则自动创建。
5. 笔记内容必须覆盖四个类别：Design Decisions、Deviations、Tradeoffs、Open Questions；某一类没有内容时也要写「None」并简要说明。
6. Design Decisions 记录规格模糊或未提及处的选择：歧义是什么、做了什么选择、理由是什么。
7. Deviations 记录有意偏离规格之处：规格怎么说、实际实现了什么、为何偏离是必要或更好的。
8. Tradeoffs 记录考虑过的替代方案及选择依据：有哪些可行替代方案、各自优缺点、为何选中的方案胜出。
9. Open Questions 记录希望确认或修改的事项：不确定的假设是什么、用户应验证什么、可能需要什么后续跟进。
10. 使用给定的完整 HTML 模板，保留其结构、样式和类名；替换模板中的 `{{ISSUE_URL}}`、`{{ISSUE_NUMBER}}`、`{{ISSUE_TITLE}}`、`{{DATE}}`；模板包含四个带彩色圆点的 `<h2>` 区域、`.item` 卡片样式、四类 label（`label-design`、`label-deviation`、`label-tradeoff`、`label-question`）以及 footer「Generated by goal-workflow /note-it」。
11. 每个条目使用 `.item` 卡片；按示例格式编写：`<h3>` 中放 label 和标题，`<p><strong>Ambiguity:</strong> ...</p>`、`<p><strong>Choice:</strong> ...</p>`、`<p><strong>Rationale:</strong> ...</p>`，偏离、权衡、问题按对应字段组织。
12. 保存前执行 checklist：Issue 编号已确定；四个类别都已审查（即使某些为「None」）；设计决策解释理由而非只写做了什么；偏离清楚对比规格与实现；权衡提到具体考虑过的替代方案；开放问题可操作（用户能回答是/否或给出方向）；HTML 格式正确且能渲染。
13. 边界情况：找不到 Issue 编号时，让用户指定。
14. 边界情况：`docs/` 目录不存在时自动创建。
15. 边界情况：该 Issue 的笔记文件已存在时，询问「Update existing notes or overwrite?」，默认更新（追加新条目）。
16. 边界情况：没有偏离或开放问题时，写「None — implementation followed the spec as written.」。
17. 边界情况：找不到 spec/PRD 文件时，在 Open Questions 中注明「No PRD found at tasks/prd-*.md — verify against original requirements.」。
18. 生成文件后向用户展示摘要。
19. 可在 `/ship-it` 之前作为最终检查点使用；任何时候用户想捕获设计理由时都可使用。

适用边界 · 注意事项

• 尚未完成实现和评审/修复，没有可记录的决策、偏离或权衡时，不适合使用。
• 没有 Issue 编号体系且无法确定 Issue 编号时，应先明确编号或改用其他记录方式。
• 只需要简短口头总结、不需要 HTML 归档或 Issue 追踪时，不必生成该文件。