Menu
记录架构决策（ADR）。触发条件：(1) 艰难选择——在方案间纠结、选了A但B也有优势、知道有副作用 (2) 重构/重大修改后——改了3+次才定方案、每次改有新考虑 (3) 奇怪代码——被问"为什么这样写"、审查被质疑、自己回看也觉得奇怪 (4) 用户做出重大决策或出现决策疑问
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
为 AI Agent 创建元规则和领域知识，帮助用户在不熟悉领域建立 Agent 的思考方式和行为准则。专注于抽象的行事风格而非具体技术约束。适用场景：(1) 创建新 Agent 缺少行为准则，(2) 更新现有 Agent 的元规则或知识，(3) 用户不熟悉目标领域需要搜索最佳实践，(4) 希望 Agent 跨项目保持一致工作风格。
记录 AI 犯错或可改进点，生成可复用的学习资产。支持两种模式：(1) 当前会话 - 会话结束时触发，引导用户回顾本次会话中的纠正和可改进点；(2) 指定会话 - 通过 session_id 或 JSONL 文件路径分析历史会话。存储位置：D:\desktop\quackDocs\my_notes\ai_mistake\（index.md 索引 + records.md 实体）。触发词：记录错误、记录问题、AI 错误记录、会话总结、记录教训、record mistakes。
记录 AI 犯错或可改进点，生成可复用的学习资产。支持两种模式：(1) 当前会话 - 会话结束时触发，引导用户回顾本次会话中的纠正和可改进点；(2) 指定会话 - 通过 session_id 或 JSONL 文件路径分析历史会话。存储位置：D:\desktop\quackDocs\my_notes\ai_bug_history\（index.md 索引 + records.md 实体）。触发词：记录错误、记录问题、AI 错误记录、会话总结、记录教训、record mistakes。
指导 Manager 设计和创建 Loop 循环。当 Manager 需要创建自动化循环（如 Executor-Reviewer、Writer-Editor 模式）时使用。 提供完整的设计流程：需求澄清 → 节点设计 → 用户确认 → Subagent 验证 → 创建循环。 确保循环提示词质量，避免因上下文设计不当导致循环失败。 触发词：创建循环、loop、循环设计、迭代执行、自动审查。
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
本地代码审查工具，用于审查指定范围的代码变更。支持多种输入方式：(1) git range（如 HEAD~3..HEAD）(2) 暂存区（--staged）(3) 指定文件/目录路径 (4) 模糊功能描述（如"认证模块"、"用户登录"）。必须指定审查范围，否则直接返回错误。输出审查报告到 docs/generated/。触发词：local-review、本地审查、代码审查、review。
| name | write-decisions |
| description | 记录架构决策（ADR）。触发条件：(1) 艰难选择——在方案间纠结、选了A但B也有优势、知道有副作用 (2) 重构/重大修改后——改了3+次才定方案、每次改有新考虑 (3) 奇怪代码——被问"为什么这样写"、审查被质疑、自己回看也觉得奇怪 (4) 用户做出重大决策或出现决策疑问 |
决策必须满足以下全部条件才创建：
决策不需要创建的场景：
以下 3 个场景满足 checklist 条件时，必须触发写入：
场景 1：艰难选择
标志：在两个方案间纠结了很久；选了 A 但 B 也有明显优势；知道选择有副作用。
行动：决策完成后立即写 ADR，记录考虑了哪些方案、为什么选这个、有什么已知限制。
场景 2：重构或重大修改后
标志：改了 3+ 次才找到合适方案；每次改都有新的考虑；最终方案看起来不是"最直接的"。
行动：重构完成后写 ADR，记录演进历史（为什么改了 3 次）、每次改解决了什么问题、当前方案的权衡。使用 decision-template.md 中的"演进历史"节。
场景 3：看起来奇怪的代码
标志：新人或 AI 问"为什么这样写"；代码审查时有人质疑；自己回看代码时也觉得奇怪。
行动：补写 ADR，使用补写模式（见下方）。
对于场景 3（看起来奇怪的代码），使用简化流程：
决策内容必须基于：
决策内容禁止基于：
如果用户没有指定文档，且对话中没有足够信息推断决策依据，必须向用户确认，不能自行推断。
决策文档是独立文件，复制到两个位置，内容完全相同：
| 位置 | 路径 | 用途 |
|---|---|---|
| 项目级 | docs\ADR\YYYY-MM-DD-{具体内容}.md | 团队和 agent 参考 |
| 全局级 | D:\desktop\quackDocs\my_notes\my-decisions\YYYY-MM-DD-{具体内容}.md | 跨项目积累 |
写入后更新对应的 index.md：
docs\ADR\index.mdD:\desktop\quackDocs\my_notes\my-decisions\index.md全局级 index.md 格式：
| YYYY-MM-DD | 决策标题 | decided\undecided | 项目名 | [详情](YYYY-MM-DD-{具体内容}.md) |
项目名从当前工作目录的文件夹名推断。
如果全局目录不存在，创建它。
使用模板：references\decision-template.md
模板中的各节按需保留，无内容的节直接删除。
使用模板：references\user-design-summary-template.md
User Design Summary 是聚合文档，两个位置各自维护（链接格式不同，条目可能不同）：
| 位置 | 路径 | 链接格式 |
|---|---|---|
| 项目级 | docs\ADR\user-design-summary.md | [决策标题](.\YYYY-MM-DD-{具体内容}.md) |
| 全局级 | D:\desktop\quackDocs\my_notes\my-decisions\user-design-summary.md | [决策标题](YYYY-MM-DD-{具体内容}.md) |
编写原则：