# Minimal Viable

> 最小可行推进与验证节制。实现与验证阶段使用；无特殊要求按 MVP 推进，不扩范围，不加"以防万一"分支，edge case 与复杂度权衡有依据，验证只做必要项且每项一次，已通过的不重验。

- Skill: `redgranite/minimal-viable` (Agent Skill)
- Install (CLI): `npx skillmds@latest add redgranite/minimal-viable`
- Raw SKILL.md: https://api.skillmd.com/api/skills/redgranite/minimal-viable/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: RedGranite (https://skillmd.com/u/redgranite)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/redgranite/minimal-viable

---

# minimal-viable：做最少的，验一次

## 何时用
每次开始实现与验证。用户明确要求"完整""production"时按其要求扩展，但仍不重复验证。

## 硬规则
- MUST 默认按最小可行范围推进：只实现当前需求明确需要的路径。
- MUST 先打通最薄的一条端到端路径让用户看到能跑，再逐层加厚；不自底向上把每层做完才第一次联调。
- NEVER 无请求扩范围：不加未要求的功能、配置项、抽象层、"以防万一"的分支。
- MUST edge case 逐个判断：真实使用会出现吗？出现代价多大？代价低于处理成本的不处理，记一行。
- MUST 验证计划先列出（哪几项、各怎么跑），每项跑一次，通过即结束。
- NEVER 对已通过的检查重复执行、重复读取文件确认、或为"再确认一下"多跑一轮。
- NEVER 用大量验证替代思考：跑之前先写预期结果。
- MUST 失败修复后只重跑失败项。

## 审问清单
1. 这个需求的最小完成形态是什么？
2. 我加的这个分支 / 参数 / 抽象，是谁要求的？
3. 这个 edge case 的概率与代价？处理它的代价？
4. 验证清单几项？哪一项能证明"做完了"？
5. 这次运行是在获取新信息，还是重复已知结果？

## 反模式
- 错误：要求加一个 CLI 参数，顺手重构参数解析、加配置文件、写十个 edge case 测试。→ 正确：加参数，一个测试，结束。
- 错误：测试通过后再打开文件确认、再跑一次测试、再 lint 一遍。→ 正确：测试通过即报告；lint 在验证计划里就跑一次，不在就不跑。
- 错误：处理"用户名含 emoji 且长度为 0 且并发提交"的组合 case。→ 正确：记录"未处理：X，理由：概率与代价"，继续。

## 输出要求
开始前一行 MVP 边界与验证清单；结束时按清单逐项报告，不附加额外验证。