plan-review
Skill4 starsChanged 4 days agoMITView on GitHub
涉规范/红线/技能体系的改造由子代理出计划、主代理按硬清单复核;普通大型改造走 DSH 原生 plan mode(/plan → exit_plan_mode)。Triggers: 制定计划, 出计划, 复核计划, 计划审核, 计划把关, 子代理规划, 规划阶段, 计划制定规范, 测试计划复核, plan mode, exit_plan_mode
43 other projects use a version of this.
Adopted by
Most recently taken up by
- bas1l/claude-skillstheir own version, first seen Nov 3, 2026
- duncanmorris/agent-skillstheir own version, first seen Nov 2, 2026
- vzhukovs/podman-desktop-kittheir own version, first seen Nov 1, 2026
- Esi-Abolfazl/skillstheir own version, first seen Nov 1, 2026
- kopp0510/claude-ddtheir own version, first seen Nov 1, 2026
- Mathews-Tom/armorytheir own version, first seen Nov 1, 2026
Used with
Projects with it also use plan-execute, pr-comment and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
longranger2Skillplan-execute
Use when the user says "/plan-execute", "plan execute", "implement plan", or "execute plan" and provides a finalized plan file path to carry out. Claude orchestrates, Codex writes code, Claude reviews, and Codex fixes issues until the quality bar is met.
Also in 3 projects that use this
BenjaminGSkillpr-comment
This skill should be used when reviewing someone else's pull request and you want drafted review comments posted to GitHub — either gate / gate-wf findings (tier-marked) or pr-challenge's reviewer questions (unmarked) — each drafted through humanizer and posted as a standalone inline comment at its file:line, after one confirmation. Triggers on "post these as review comments", "comment the gate findings on the PR", "draft and post my review", "leave review comments", after a gate / gate-wf run or a pr-challenge pass on a PR you're reviewing.
Also in 3 projects that use this
MicrosoftSkillspec-review
Independent, multi-model review of a design or spec **before** any code is written, for the microsoft/winappcli repo. Activate when a contributor asks to "review this spec", "review my design", "review this design doc", "validate this approach", "should we build this", "spec review", "design review", or "feature review". Fans out parallel sub-agents — each doing its OWN research against the real codebase and ecosystem rather than trusting the spec — covering necessity & scope, approach & alternatives, feasibility vs reality, risks & unknowns, DX & user impact, and a different-model-family cross-check. Emits a decision-oriented recommendation (proceed / proceed-with-changes / reconsider) to stdout. This is the PRE-CODE companion to the pr-review skill (which reviews code already written); use spec-review at the design/spec stage, not on an implemented diff. Does NOT write code or edit the spec.
Also in 3 projects that use this
AnthropicSkilloffice-hours
Set up and run Claude Code office hours, including the calendar event when the champion's own calendar connector allows it. Use when a champion wants a regular time for teammates to bring problems.
Also in 3 projects that use this
AWSSkillretro
Conduct a retrospective on a coding session.
Also in 5 projects that use this
BlockSkillplan
Draft a TDD, PRD, or lightweight plan in the conversation without committing it.
Also in 5 projects that use this
Other versions43 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 43
- ahmadrosid/nakama★ 786same name
- igerber/diff-diff★ 413same name
- Mathews-Tom/armory★ 340same name
- sd0xdev/sd0x-dev-flow★ 192same name
- sd0xdev/sd0x-harness★ 192same name
- YougLin-dev/Aha-Loop★ 181same name
- longranger2/claude-gpt-workflow★ 76same name
- ConnorGriffin/skills★ 21same name
- liewcf/agent-skills★ 16same name
- kopp0510/claude-dd★ 12same name
33 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository15 other files it gives its agents.
- AGENTS.mdAGENTS.md
- dsh/AGENTS.mdAGENTS.md
- android-apk-download-verifySkill
- auto-skill-creatorSkill
- docs-stale-auditSkill
- dsh-turn-failure-diagnosisSkill
- git-branch-consolidationSkill
- opencode-oauth-context-capSkill
- opencode-share-kitSkill
- phased-refactor-and-reportSkill
- powershell-utf8-safetySkill
- quality-baselineSkill
- test-verificationSkill
- white-bear-safe-rulesSkill
- windows-openssh-serverSkill
The file
Files
计划子代理 + 复核门禁
<role>
规划阶段纪律。DSH 下优先走原生 plan mode:用户执行 `/plan` 后按部署配置产出决策完备的计划,调用 `exit_plan_mode` 交用户审批。
下列四眼流程用于两类场景:改动命中红线 / 开发规范 / 技能体系,或用户明确要求子代理出计划并复核。
1. 子代理产出《开发计划》并落盘(DSH 用 `subagent` 工具)。
2. 主代理按硬清单复核,通过后才进入执行;退回子代理重出(上限 2 轮)。
3. 计划文件是执行、复核、中途更新的唯一事实来源。
</role>触发门槛(不满足则豁免,不增加开销)
满足任一进入规划流程:
- 改动涉及红线 / 开发规范 / 技能体系(AGENTS.md、AI-开发规范.md、SKILL.md、INDEX.md)
- 用户明确要求「先出计划」并复核
- 普通大型改造:DSH 走原生 plan mode(
/plan→exit_plan_mode),由用户审批,不再重复子代理四眼流程
流程
P1 子代理出计划 → P2 主代理复核 →(不通过→退回P1,上限2轮)→ 通过 → P3 执行P1 子代理出计划(planner)
- 主代理把「任务描述 + 相关规范(AGENTS.md / 项目 AI-开发规范.md / 相关 SKILL.md)+ 现状分析」交给子代理:DSH 用
subagent工具(fresh 上下文);OpenCode 用task的general子代理。 - 子代理产出《开发计划》,主代理用
write工具落盘:项目.dsh/plans/{slug}-{yyyyMMdd}.md(DSH;OpenCode 用.opencode/plans/,临时任务用work/plans/),固定模板:
# {任务} 开发计划
## 一、目标与范围(做什么/不做什么)
## 二、阶段拆分(每阶段:目标 | 涉及文件 | 验收项/风险与场景 | 验证命令或手动步骤/成功标准/证据 | 回滚方案)
## 三、风险与依赖
## 四、技能同步预案(触及 页面/模块/命令/架构/红线 时的技能更新安排)P2 主代理复核(reviewer,硬清单逐项核查)
A. 计划制定规范(承接 phased-refactor-and-report):
- 每阶段可独立测试 / 独立提交 / 独立回滚
- 每阶段只做一类变更(先结构后行为、先加后删)
- 阶段粒度合理(理想 1 阶段 1 commit)
- 每阶段写明目标 / 涉及文件 / 验收项与相关风险场景 / 验证命令或可复现手动步骤 / 成功标准与证据(按
test-verificationP2 设计) - 测试从直接路径和已知缺陷起步:每项追加检查有具体风险或门禁依据,项目必要门禁完整、停止条件明确,客观关键缺口可见(方法按总控路由选用)
- 含应用运行场景时,复用实际运行检查相关来源;诊断和补采集由具体问题或必要证据触发(见
test-verification运行时信号检查) - 本次涉及的主观视觉与体验有简短人工验收入口,截图按需取证;AI 客观结果与待人工项目分别明确
- 有风险点与回滚方案
B. 开发规范(承接 quality-baseline;涉前端项目另加载项目前端规范):
- 代码结构:复用非复制、单一来源
- 维护性:易测易回滚、抽象适度
- 界面统一 / 操作一致 / 动效合适遵循项目规范,明确契约客观核对,主观体验交人工(涉前端时)
- 涉规则改动时:白熊三原则(禁令配正面替代、行为与诊断分离、正面先行)
C. 一致性:
- 与任务目标对齐,无遗漏、无越界
- 阶段顺序依赖正确(前置在前)
- 技能同步预案已包含
复核输出固定格式:逐项 通过/不通过+理由 → 结论(通过/退回/小瑕疵) → 修改意见。
P3 闭环(复核结论三态)
- 通过 → 进执行,计划文件即执行依据。
- 小瑕疵(漏验证命令、措辞不清等)→ 主代理直接修文件并标注,视为通过。
- 不通过(结构性问题:阶段不可独立回滚、目标遗漏、违反红线)→ 附修改意见退回 P1,上限 2 轮;超限上报用户裁决,由用户拍板后再开工。
P4 执行
回归 phased-refactor-and-report:每阶段 实现→测试→提交;中途计划外事项 → 暂停 → 更新计划文件 → 变更较大时重新走复核。
关键命令 / 模式
- 出计划:DSH 用
subagent工具(fresh 上下文);OpenCode 用task工具(subagent_type: general)。prompt = 任务 + 规范清单 + 输出模板 + 落盘路径。 - 落盘:DSH 用
write工具(计划含中文,遵循powershell-utf8-safety);OpenCode 用 Write 工具。 - 复核:对照清单逐项给出 通过/不通过 + 可核验依据,结论三态明确。
注意事项(红线)
- 禁止橡皮图章:每项必须给出可核验依据,不写"OK"了事。
- 迭代上限 2 轮是硬约束,防死循环;超限上报用户裁决。
- 不追求完全独立复核:复核者与规划者共享上下文,独立性有限,硬清单保证下限;真正独立留给用户终裁。
- 计划文件是唯一事实来源:执行、复核、中途更新都围绕它,禁止口头计划漂移。
- 规划前置:大型改造先出计划并复核通过,经用户确认后才动手(用户明确指示直接做除外)。
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

