القائمة
在评审技术设计文档、实现计划、迁移方案、架构规格、发布与上线计划、插件或 hook 设计、以及需要工程师或代理按文档可靠执行的安全敏感自动化方案时使用；也适用于用户说评审技术方案、审设计文档、看实现计划、方案可不可行等场景。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | dev-plan-review |
| description | 在评审技术设计文档、实现计划、迁移方案、架构规格、发布与上线计划、插件或 hook 设计、以及需要工程师或代理按文档可靠执行的安全敏感自动化方案时使用；也适用于用户说评审技术方案、审设计文档、看实现计划、方案可不可行等场景。 |
多维度技术方案评审，带明确质量门槛。凡会驱动工程落地（改代码、改数据、改配置、自动化、发布）的文档，在进入实现或上线前应经本技能评审。评审围绕七个维度：一致性、正确性、完整性、可执行性、安全性、可验证性、可运维性。
通过标准： 文档能说清要解决什么、由谁执行、如何执行、失败如何收场、用什么证据证明方案成立。方案不必完美，但必须把关键风险显性化并给出可执行的控制措施。不要因文风与个人偏好不一致而否决；也不要放行依赖猜测、口头承诺或不可验收措辞的方案。
交付物： 每次评审须同时给出（1）对话中的结论性说明（摘要、强调阻塞点、必要时口头澄清）；（2）一份可归档的评审文档：按 references/review-output-template.md 填写完整 Markdown，并尽量写入仓库（若用户同意写盘）。清单自检使用 references/review-checklist-template.md，可附在报告附录或单独保存。对高影响或大范围文档，优先采用多子代理分角色评审，由主编排者合并为一份报告，见下文「多子代理评审与交叉验证」。
默认归档路径（可覆盖）： docs/reviews/YYYY-MM-DD-<主题简写>-dev-plan-review.md。子代理分片产出可写入 docs/reviews/...-subagent-<角色简写>.md 或附录，再由主编排者合并为终稿。用户指定其他路径时从其指定。禁止写盘时：在回复中用 Markdown 代码块附上与模板等价的完整文档内容。
不适用： 纯营销文案、与工程执行无关的随笔；换用对应技能。
每次评审须覆盖下列七个维度；与文档无关的维度在「评审覆盖」中写一句「不适用」及理由。
文档内部、与上游规格、与现有系统/代码库之间是否一致？
方案的因果链是否成立，能否推出承诺的结果？
完成本次工程变更所需的关键面是否都写到？
执行者能否不靠脑补按文档开工并验收？
数据、权限、外部输入与自动化执行的风险是否受控？
用什么证据证明方案成立？
上线后能否安全安装、升级、禁用、卸载、回滚与排障？
每条发现项须带下列级别之一，格式：[严重|高|中|低]。
| 级别 | 含义 |
|---|---|
| 严重 | 不安全、可能丢数据、突破安全边界，或文档矛盾到无法按文档执行 |
| 高 | 常见条件下易失败，或直接阻塞实现、测试或发布 |
| 中 | 模糊、欠测、脆弱或运维薄弱，短期未必阻塞但应修 |
| 低 | 表达、一致性润色、可读性，不单独阻塞结论 |
大文档难以评审且易藏假设。参考下列规模自检：
~10 页当量或单一子系统 → 适合单次评审闭环
~30 页当量或多子系统耦合 → 应拆成多篇或分阶段评审
「一篇写完全部」且无目录锚点 → 先要求拆分或加摘要与导航
何时允许大块头： 纯索引文档、已机器生成的附录、或与评审无关的参考粘贴（须在「评审覆盖」中排除）。
拆分策略： 按子系统垂直切分；按阶段（设计 → 实现计划 → 迁移/runbook）水平切分；共享契约单独成文，避免同一篇混写「愿景」与「逐步命令」。
按顺序执行。途中发现 严重 或 高 级问题，仍完成后续步骤，但在「总体结论」中写明阻塞关系。
在逐段抠字前建立坐标：
- 这份文档要推动什么工程变化？
- 谁来执行：人类工程师、agent、CI、运维，还是混合？
- 影响哪些资产：代码、生产数据、用户面、权限、成本、SLA？
- 依赖哪些既有规格、代码、平台能力或流程？
把文档承诺写成可对照清单；缺项即发现项或开放问题：
- 目标 / 非目标 / 范围
- 组件职责 / 数据归属 / 外部依赖
- 输入、输出、状态变化、持久化格式
- 成功标准 / 失败标准 / 回滚标准
- 兼容性、发布窗口、责任人
打开 references/review-checklist-template.md 对照「七维」小节，逐维自问并勾选；发现项记入后续报告。
不要只扫任务列表。用下列链条走两遍（成功一次、失败一次）：
触发条件 → 执行者 → 输入 → 状态写入 → 外部副作用 → 验证信号 → 清理与终态
对每个外部依赖追问：失败行为、幂等性、部分写、如何检测、如何恢复。
确保每条发现项含四件事：级别、路径或章节、触发条件与风险、最小可行修复建议。禁止只有形容词没有动作。
- 证据是否覆盖失败、边界、并发、恶意或损坏输入？
- 发布前、发布中、发布后观测是否定义？
- 回滚是否可被验证或演练？
- 手工验收是否可重复、可判定？
结论须与最高严重级别一致：存在严重问题时不得结论「可直接实现」。 存在 高 问题时默认不得「可直接实现」，除非文档证明该风险已隔离到明确的非阻塞后续阶段。
将完整内容写入按 references/review-output-template.md 生成的评审文档；对话中给出摘要并指向文件路径（或附上等价全文）。若本轮已拆子代理并行评审，由主编排者执行合并与去重，只对外交付一份填好的终稿模板；子代理中间稿可归档为附录或单独文件。
不同执行者关注不同轴，可补全单视角盲区，并通过重叠维度做交叉验证。
至少满足一条即建议启用 ≥2 个子代理；满足多条或涉及生产、数据、权限、hook、agent 写盘时建议 3 个子代理：
篇幅很短且风险档位自评为低时，可单代理全流程，但须在「评审覆盖」写明未采用多子代理及原因。
同一轮内并行派发，每个子代理只使用本技能、同一被评文档路径、同一 review-output-template.md 的字段要求，但各自侧重的七维子集如下；须使用带前缀的发现项编号以便合并：C-F1、X-F1、S-F1 等；合并后主编排者改为全局 F1…。
| 子代理 | 代号 | 侧重维度 | 必做增量 |
|---|---|---|---|
| 契约与正确性 | C | 一致性、正确性、完整性 | 主路径是否自洽、与上游规格是否冲突、非目标与范围 |
| 执行与运维 | X | 可执行性、可运维性 | 任务顺序、幂等/清理/回滚、可观测、人工步骤 |
| 安全与证据 | S | 安全性、可验证性 | 信任边界、写盘与权限、测试与证据是否撑得住结论 |
两子代理折中： C 负责 一致性+正确性+完整性+可执行性；S 负责 安全性+可验证性+可运维性。
主编排者：固定被评文档路径、归档路径、是否三拆或两拆
│
├─ 并行 ─→ 子代理 C：输出带 C- 前缀的发现项草稿 + 覆盖声明
├─ 并行 ─→ 子代理 X：输出带 X- 前缀的发现项草稿 + 覆盖声明
└─ 并行 ─→ 子代理 S：输出带 S- 前缀的发现项草稿 + 覆盖声明（三拆时）
│
▼
主编排者：合并、去重、消解或升级冲突 → 统一 F 编号 → 填一份 review-output-template.md
│
▼
可选：人审终判
同一轮触发： 勿串行等第一个子代理结束再派第二个；并行结束后再合并，缩短总延迟。
[高]，列出双方论据，禁止主编排者无依据强行折中。派发时附上相同上下文块，仅替换「你的代号与侧重的维度」：
你已挂载 dev-plan-review 技能。被评文档：[路径]。
你的角色：[C / X / S] — 仅在该角色对应的七维子集上深挖；其他维度若发现致命问题可写，但标注「越权发现」。
输出：按 `references/review-output-template.md` 结构输出草稿，发现项 ID 使用 `C-F1`、`X-F1` 或 `S-F1` 形式；评审覆盖须诚实。
禁止：与其他子代理通稿；仅基于文档与技能独立评审。
F1… 映射先给执行摘要（3～6 句）：结论档位、最高严重级别、是否阻塞、是否已落盘及路径。
完整正文必须基于 references/review-output-template.md 填写，并保留四个固定二级标题：发现项、开放问题、总体结论、评审覆盖。须包含：被评方案摘要、带 F 编号与维度的发现项表、发现项下的七维索引、总体结论内的决策摘要表与理由、评审覆盖内的阅读与假设及证据与验证表。
禁止只给口头意见而不产出可复制的报告体 Markdown。
若暂无阻塞性发现项：保留「发现项」小节说明未发现阻塞性问题，并在同节或「总体结论 / 评审覆盖-证据」中写明残余风险与建议补做验证。
评审过程中或收尾时，按 references/review-checklist-template.md 勾选；勾选结果可贴在报告末尾「附录」或单独文件（如 *-checklist.md）。
| 文件 | 用途 |
|---|---|
references/review-output-template.md | 报告：被评摘要、F 编号发现项、七维索引、总体结论含决策表与理由、评审覆盖含阅读与证据 |
references/review-checklist-template.md | 七维自检清单，勾选框形式 |
| 借口 | 事实 |
|---|---|
| 「计划而已，实现时再补测试」 | 测试策略与风险应对应对齐；无证据不视为通过 |
| 「逻辑上没问题」 | 要求可判定验收条件或状态说明；否则记为中高级模糊 |
| 「agent 不会乱来」 | Instruction 不是安全边界；须硬门控或可核验约束 |
| 「太长略过」 | 执行者无法还原步骤即阻塞：要求拆分或补全 |
| 「性能以后再说」 | 若触及用户路径或 SLA，列入开放问题或发现项 |
差： 先按章节复述全文，最后说「整体不错」。
好： 直接写发现项，例如：[高] 任务 4：Stop hook 失败后 trigger 文件未定义清理，重入可能双触发……
差： 「子代理会遵守 SKILL，不会写到 skills 外。」
好： [严重] 仅靠文档约束路径不足；须 PreToolUse 白名单或等价拦截及对应测试。
差： 只描述迁移成功后的终态。
好： [高] 回滚未定义：Step 2 写失败后是否维持双写窗口？旧读路径保留多久？
交付前须将下列待勾选框逐项勾为已满足；全部勾选后，方可将本轮评审标为「完成」。
references/review-output-template.md 产出完整评审文档（已写入仓库路径，或在回复中附上同等结构的 Markdown 全文）references/review-checklist-template.md 完成勾选（附于报告附录或单独文件，或说明以等价方式覆盖）深度功能分析，以问题驱动的方式深入挖掘某个功能/机制的实现原理，生成单篇深度解析文档。参考 skill-creation-mechanism.md 的分析风格：从核心问题出发，层层深入，多维度对比，最后给出总结。适用于"深入分析 X 的原理"、"深度解析 Y 机制的实现"、"理解 Z 功能的设计决策"等场景。
Build and maintain a personal knowledge base where an LLM incrementally builds and maintains a structured, interlinked collection of markdown files. Based on Andrej Karpathy's LLM Wiki pattern.
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
Use when building TypeScript SDKs, extracting shared code into packages, creating developer tooling libraries, designing clean API surfaces, or publishing to npm (public or private). Covers typed clients, error handling, multi-target bundling (ESM/CJS/browser).
Interact with GitHub using the `gh` CLI. Use `gh issue`, `gh pr`, `gh run`, and `gh api` for issues, PRs, CI runs, and advanced queries.
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task.