自用网站SHIJIE / KEEP ROAMING
GitHub ↗
作品/dev-skills

REQUIREMENT TO PR

dev-skills

从需求到验证过、可合入的 PR：一套给编程 Agent 用的 Skills。
先给仓库搭一个 Agent 能自己启动、操作、观察的验证环境；之后每个需求由一个 Agent 从头做到尾，在运行的应用里证明结果，再由另一家模型独立验证。人只在三处介入：确认决定，确认验收标准，合入前读一遍决定清单。

查看源码安装与使用

介绍复核于 · 查看依据版本 2254db6

一个需求怎样走完

每个仓库先做一次准备，之后每个需求依次经过定义和交付；这次暴露出的仓库缺口，列在 PR 里，由你决定补回仓库还是 Skill。

  1. A 仓库准备 · repo-readiness

    让 Agent 能自己验证。你：每个仓库一次，回答仓库里查不到的事。

  2. B 定义 · core-grill

    把要你定的事问清楚。你：回答问题，确认一次决定汇总。

  3. B 定义 · core-spec

    写下决定和验收标准。你：确认一次 spec 和 verify。

  4. C 交付 · deliver

    一个 Agent 做到可合入。你：合入前读决定清单，然后合入。

几条约定贯穿全程：要人决定的事和验收要求在开头定全，结尾由另一家模型按验收标准验证，中间交给一个 owner 做完；合入、强推共享分支、删除共享数据、对外发消息、改共享环境，这些不可逆操作留给你。

A 仓库准备 / 让 Agent 能自己验证

repo-readiness

每个仓库做一次。搭好项目自己的验证 Skill：Agent 能在 worktree 里隔离地启动、操作、观察应用；配上带判据编号的功能地图、场景脚本、冒烟集，以及 CI 里的结构检查。仓库里查不到的事，一次问清。

你要做的：每个仓库一次，回答仓库里查不到的事。

/dev-skills:repo-readiness 下一个需求是 <链接或原文>
阅读 Skill 原文

B 定义 / 把要你定的事问清楚

core-grill

需求开始时逐轮追问会改变用户可见结果的决定，比如交互、文案、默认值、入口、数据会不会丢。每个问题给出选项、后果和推荐答案；实现细节由 Agent 自己定，记成默认决定。最后整理成一份决定汇总。

你要做的：回答问题，确认一次决定汇总。

/dev-skills:core-grill 需求是 <链接或原文>，需求文档放 <需求目录>/
阅读 Skill 原文

B 定义 / 写下决定和验收标准

core-spec

把决定汇总收敛成 spec.md（决定与约束）和 verify.md（验收要求），请另一家模型逐条查漏。确认后两份文件冻结，提交到需求分支，开 Draft PR。也可以只产出 spec。

你要做的：确认一次 spec 和 verify。

/dev-skills:core-spec 依据决定汇总写 spec.md 和 verify.md
阅读 Skill 原文

C 交付 / 一个 Agent 做到可合入

deliver

依据冻结的 spec 和 verify，由一个 owner 逐个里程碑实现，并在运行的应用里跑场景。要定的事先问另一家模型，再自己决定，列进 PR 最前面的决定清单。最后由另一家模型对最终代码独立验证，处理完 CI 和评审，做到可合入。

你要做的：合入前读决定清单，然后合入。

/dev-skills:deliver 接手 <Draft PR 链接>
阅读 Skill 原文

流程里也会用到

评审、读 PR 和写报告时，流程会沿用下面三个 Skill；它们也可以单独调用。

  1. review-rules · 让评审有依据

    评审代码与设计、复核评审意见、判断修复方案时用的五条准则：正确完整、最小必要改动、复杂度与收益相称、足够的扩展性、责任边界清楚。

    /dev-skills:review-rules 复核这条评审意见，说明依据和最小修复
    阅读 Skill 原文 ↗

  2. mr-for-human · 读懂 AI 写的代码

    把 PR 整理成给人看的阅读指南：先给核心结论和需要判断的事，再讲设计、用伪代码写出的执行逻辑和运行约束，最后给出代码定位。

    /dev-skills:mr-for-human 带我读懂这个 PR：<链接>
    阅读 Skill 原文 ↗

  3. explain-as-fool · 把概念讲清楚

    面向对话题一无所知的人做解释，直接说，不绕修辞。其他 Skill 写给人的报告也沿用它的写作要求。

    /dev-skills:explain-as-fool 解释一下什么是线程池
    阅读 Skill 原文 ↗

可以单独使用

不在交付流程里，按手头的任务单独调用。

  1. design-for-review · 让方案可独立阅读

    把需求和设计材料整理成可独立阅读的技术评审文档，讲清问题、整体设计、改动范围和需要拍板的取舍。

    /dev-skills:design-for-review 根据已确认的设计，整理一份评审文档
    阅读 Skill 原文 ↗

  2. plan-for-agents · 把决定变成计划

    创建、修订或检查供 Agent 执行的完整计划，从需求和已确认的决定落到步骤、产物和验收证据。

    /dev-skills:plan-for-agents 根据已确认的 spec，写一份可独立执行的 plan
    阅读 Skill 原文 ↗

  3. agent-prompt-rules · 写给 Agent 的规则

    写和审查给 Agent 的 prompt、多 Agent pipeline 与 SKILL.md 时用的规则，每条都链接到 Anthropic、OpenAI 的原文。

    /dev-skills:agent-prompt-rules 按规则审查这份 SKILL.md
    阅读 Skill 原文 ↗

  4. recon-to-contract · 把调研收敛成契约

    把两个以上外部参照物的对标调研，收敛成一份有证据、有决定、有验收标准的可执行契约。

    /dev-skills:recon-to-contract 对比这三个开源实现，产出迁移契约
    阅读 Skill 原文 ↗

安装与调用

以插件安装时，Skill 带命名空间：MCode 和 Claude Code 写 /dev-skills:core-grill，Codex 写 $dev-skills:core-grill。从克隆把 Skill 目录链接到本机时没有命名空间，写 /core-grill 或 $core-grill。两种方式二选一。

在 Claude Code 和 Codex 里，core-spec 也可以在讨论结束后由 Agent 主动调用，其余 Skill 只支持手动调用。MCode 目前不读这个设置，按名字调用更稳妥。

查看安装步骤

使用前的前提

需要两个不同家族模型的 CLI，都装好并登录，默认是 Claude Code 和 Codex。查漏和最终验证必须由另一家模型来做；只有一家可用时，流程会停在那一步，不会降级成同家族检查。

还需要 Node.js 24、git，以及开 PR 用的 gh 或 glab；再加一个 Agent 能在 worktree 里启动、操作、观察的应用，这正是 repo-readiness 要搭的。插件安装支持 MCode、Claude Code 和 Codex；端到端测试目前只在 Claude Code 和 Codex 上做过。

返回作品