菜单
记录架构决策（ADR）。触发条件：(1) 艰难选择——在方案间纠结、选了A但B也有优势、知道有副作用 (2) 重构/重大修改后——改了3+次才定方案、每次改有新考虑 (3) 奇怪代码——被问"为什么这样写"、审查被质疑、自己回看也觉得奇怪 (4) 用户做出重大决策或出现决策疑问
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
为 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) |
编写原则：