通过 Skills CLI 安装
使用 npx skills add 将该 skill 安装到选中的 Agent。Phase 0 命令均为按规则生成，尚未验证。
Codex
npx skills add https://github.com/affaan-m/ECC -g -a codex -y去掉 -g 可改为项目级安装
#46
该品类排名 #46 / 共 47 个· Ranked #46 of 47 in this category
orch-build-mvp
Orchestrate turning a design document into a working MVP through thin vertical slices, scaffolding, and gated commits.
自动筛查 · automated开源 · open source
安装前须知Before you install
✓未声明特殊权限需求No special access needs declared
编辑结论· Editor's verdict
Position as a specialized entry point over the more general orch-pipeline skill, so docs can explain it as a preset rather than a standalone system.
✓
适合什么场景Best for
- Teams that already have a written design document and want a structured path to a first running slice.
- Projects where the value comes from shipping a thin end-to-end path quickly rather than complete layers.
- Engineers using a GAN-style generator and evaluator loop and wanting the planner step skipped because the spec already exists.
✗
不适合什么场景Not for
- Greenfield work without any spec, design doc, or PRD to drive the slicing from.
- Tasks that need a full horizontal layer first, such as building the entire data model before any UI.
- Users who want to manually iterate slice by slice without an automated build and evaluator loop.
vs 其他选择vs alternatives
完整对比表Full compare table →#1GStack Review
分支合并前，先把真正危险的改动挑出来。
差异 · diff高信号 PR 评审的首选。它读的是 diff 本身，而不是把整个仓库重新总结一遍，所以评审会落在真正变化的代码上。最擅长信任边界类问题——SQL 注入、鉴权检查、条件分支副作用——这些在浅层评审里最容易漏掉。纯样式问题别用它，丢给 linter 更划算。建议先在普通 feature 分支上验过一次，再放到 hot-fix 流程里用。
#2Git Shiproom
请求评审前，先给分支做一次发布前检查。
差异 · diff专门覆盖「我这个分支可以合了」到「评审者能冷启动接手」之间那段窄缝。会跑一遍发布前检查：依赖漂移、改动文件缺没缺测试、commit 标题和 PR 描述对不对得上，然后生成一份评审者能 60 秒读完的交接说明。它不是代码评审器——不审查逻辑。当作请求评审前的最后一步用，别拿它代替评审本身。
#3Review Radar
先找 bug、回归和缺失测试。
差异 · diff想拿 PR 评审的洞察、但又不想绑定到完整评审流程时，它最合适。给出的回归和缺测试信号跟 gstack-review 是同一档，但只输出建议——不动 diff、不写评论、不申请修复。最适合资深工程师在自己 merge 之前做二次审视。要给别人代码把关时它不够用，那种场景 gstack-review 的更重流程才能撑住。
维度对比side-by-side compare
和同类的关键维度差异| 当前 · this skillorch-build-mvp | GStack Review | Git Shiproom | Review Radar | |
|---|---|---|---|---|
| 评分 · rating | 0.0 | 4.9 | 4.9 | 4.8 |
| 星标 · stars | 215k | 110k | 13k | 11k |
| 风险 · risk | 自动筛查 · automated | 低风险 · low risk | 低风险 · low risk | 低风险 · low risk |
| 最适合 · best for | Teams that already have a written design document and want a structured path to a first running slice. | 合并前 PR 评审 | 分支发布前检查 | 聚焦代码评审 |
| 不适合 · not for | Greenfield work without any spec, design doc, or PRD to drive the slicing from. | 纯样式评审 | 深度代码评审 | 浏览器 QA |
审计备注Audit notes
2026-06-10 复查 · last reviewed源码Source公开 GitHub · open on GitHub✓
作者Author社区贡献 · community!
网络访问Network只读 · read-only✓
文件写入Filesystem工作目录沙箱 · sandboxed✓
依赖Dependencies依赖少且通过审计 · audited✓
遥测Telemetry无 · none✓