@pigcloud/skills 1.0.11 → 1.1.2

package/codex-commands/README.md

@@ -1,23 +1,25 @@
-# Pig Skills Codex Commands
-
-鏈彃浠舵彁渚?Pig Skills skill pack 鐨勫懡浠ゅ紡鍏ュ彛銆?
-鍏堝畨瑁?skill pack锛屽啀閲嶅惎 Codex锛屽懡浠ゆ墠浼氱敓鏁堛€?
-
-## Commands
-
-- `/spec-refinement` -> `spec-refinement`
-- `/design` -> `technical-design`
-- `/build` -> `feature-build`
-- `/review` -> `code-review`
-- `/security` -> `security-audit`
-- `/perf` -> `performance-audit`
-- `/test` -> `test-design`
-- `/doc` -> `api-contract-docs`
-- `/distill` -> `domain-modeling`
-- `/workflow` -> `workflow-router`
-- `/kb` -> `knowledge-capture`
-- `/init` -> `project-bootstrap`
-- `/infra` -> `environment-deploy`
-
-杩欎簺鍛戒护椤典繚鎸佺煭灏忥紝鏄负浜嗚 Codex 鏇村揩瀹氫綅鍒版纭殑 skill銆?
-
+# Pig Skills Codex Commands
+
+这个命令包把 Codex 的 `/` 命令映射到当前仓库的 canonical skills，并尽量把每个命令停在正确的阶段。
+
+## Commands
+
+- `/analyze` -> `requirement-discovery`
+- `/prd` -> `business-analysis`
+- `/design` -> `architecture-design`
+- `/build` -> `backend-development` / `frontend-development` / `database-change` / `bug-fix`
+- `/review` -> `code-review`
+- `/security` -> `security-review`
+- `/perf` -> `performance-review`
+- `/test` -> `unit-test`
+- `/doc` -> `api-design`
+- `/distill` -> `business-analysis`
+- `/workflow` -> `ambiguity-detection`
+- `/kb` -> `evidence-collector`
+- `/init` -> `codebase-learning`
+- `/infra` -> `deployment-guide`
+
+## Notes
+
+- 单个命令如果覆盖多个阶段，说明里会标出默认 skill 和可替换 skill。
+- 命令包只负责路由，不把领域规则写成另一个规则库。

package/codex-commands/commands/analyze.md

@@ -1,22 +1,21 @@
-# /analyze
-
-鎶婂凡缁忕‘璁ょ殑闇€姹傛敹鏁涙垚鐮斿彂鍙墽琛岀殑瑙勬牸銆?
-
-## Route
-
-- 瀵瑰簲 skill锛歚spec-refinement`
-- 閫傜敤锛氶渶姹傛媶瑙ｃ€佽竟鐣屾⒊鐞嗐€佷緷璧栫‘璁ゃ€侀獙鏀舵爣鍑嗚ˉ鍏?
-- 涓嶉€傜敤锛氳繕娌℃敹鍙ｇ殑浜у搧璁ㄨ
-
-## Workflow
-
-1. 鍏堢‘璁よ緭鍏ュ凡缁忔敹鏁涘埌鍙墽琛岃鏍笺€?
-2. 鎶婄洰鏍囥€佽竟鐣屻€佷緷璧栥€佺害鏉熷拰楠屾敹鏉′欢鏁寸悊鎴愬彲鎵ц瑙勬牸銆?
-3. 杈撳嚭鐮斿彂鍒嗘瀽缁撴灉锛屾槑纭悗缁疄鐜版墍闇€杈撳叆銆?
-4. 蹇呰鏃朵氦缁?`technical-design` 鎴?`knowledge-capture`銆?
-
-## Guardrails
-
-- 涓嶇洿鎺ュ啓瀹炵幇浠ｇ爜銆?
-- 涓嶆妸鏈‘璁ゅ亣璁惧綋缁撹銆?
-
+# /analyze
+
+把模糊输入收敛成清晰的需求问题，再决定下一步是设计、分析还是继续澄清。
+
+## Route
+
+- 对应 skill: `requirement-discovery`
+- 适用: 需求还不够清楚、信息不完整、边界不明确
+- 不适用: 已经是明确实现任务，或者只是代码修改
+
+## Workflow
+
+1. 先讲清楚目标、背景、约束和成功标准。
+2. 标出已知信息、未知信息和必须确认的点。
+3. 只做必要澄清，不提前进入设计或编码。
+4. 如果输入已经足够稳定，再交给 `architecture-design` 或 `business-analysis`。
+
+## Guardrails
+
+- 不要把模糊问题直接包装成实现计划。
+- 不要跳过边界确认。

package/codex-commands/commands/build.md

@@ -1,22 +1,22 @@
-# /build
-
-鎸夋柟妗堣鑼冨疄鐜板凡缁忔敹鍙ｇ殑闇€姹傘€?
-
-## Route
-
-- 瀵瑰簲 skill锛歚feature-build`
-- 閫傜敤锛氬紑鍙戝疄鐜般€佸閲忔敼閫犮€佹帴鍙ｈ仈鍔ㄣ€佽惤鍦颁唬鐮?
-- 涓嶉€傜敤锛氶渶姹傝繕娌℃敹鍙ｏ紝鎴栬€呰璁¤繕娌＄ǔ瀹?
-
-## Workflow
-
-1. 鍏堢‘璁よ緭鍏ユ潵鑷?`spec-refinement` 鎴?`technical-design`銆?
-2. 鎸夊垎灞傘€佷簨鍔″拰杩斿洖鍊艰鑼冨疄鐜般€?
-3. 淇濇寔鏀瑰姩鏈€灏忥紝浼樺厛鍙獙璇併€?
-4. 浜ょ粰 `test-design` 鍜?`code-review` 鏀跺彛銆?
-
-## Guardrails
-
-- 涓嶇粫杩囨灦鏋勭害鏉熴€?
-- 涓嶆妸涓存椂淇ˉ褰撲綔鏈€缁堝疄鐜般€?
-
+# /build
+
+把已经确认的变更落成代码，默认面向后端，必要时切到前端、数据库或缺陷修复 skill。
+
+## Route
+
+- 默认 skill: `backend-development`
+- 可替换 skill: `frontend-development`、`database-change`、`bug-fix`
+- 适用: 进入具体编码、补实现、修 bug
+- 不适用: 需求还没确认，或者仍在做方案选择
+
+## Workflow
+
+1. 先确认输入来自 `requirement-discovery` 或 `architecture-design`。
+2. 选定单一实现面，避免把不同层的工作混在一起。
+3. 每次只推进一个可验证的小改动。
+4. 完成后交给 `unit-test` 和 `code-review`。
+
+## Guardrails
+
+- 不要把设计争论留在实现阶段。
+- 不要在没有验证的情况下继续堆改动。

package/codex-commands/commands/design.md

@@ -1,22 +1,21 @@
-# /design
-
-鎶婂凡缁忔敹鍙ｇ殑闇€姹傝ˉ鎴愬彲瀹炵幇鐨勬妧鏈柟妗堛€?
-
-## Route
-
-- 瀵瑰簲 skill锛歚technical-design`
-- 閫傜敤锛氭灦鏋勯€夊瀷銆佹ā鍧楁媶鍒嗐€佹帴鍙ｈ璁°€佹暟鎹祦璁捐銆佸疄鐜板墠琛ュ厖璁捐
-- 涓嶉€傜敤锛氬皻鏈敹鍙ｇ殑闇€姹傝璁?
-
-## Workflow
-
-1. 璇诲彇 `spec-refinement` 鐨勭粨璁恒€?
-2. 鎷嗗垎妯″潡銆佹帴鍙ｃ€佹暟鎹粨鏋勩€佷簨鍔¤竟鐣屽拰寮傚父璺緞銆?
-3. 杈撳嚭鏂规鑽夊浘銆佸叧閿喅绛栧拰钀藉湴椤哄簭銆?
-4. 缁?`feature-build` 鍑嗗瀹炵幇杈撳叆銆?
-
-## Guardrails
-
-- 涓嶉噸鏂板彂鏁ｉ渶姹傝寖鍥淬€?
-- 涓嶈烦杩囨灦鏋勭害鏉熺洿鎺ュ啓瀹炵幇銆?
-
+# /design
+
+把已经确认的需求收敛成可执行设计，重点是边界、依赖和方案选择。
+
+## Route
+
+- 对应 skill: `architecture-design`
+- 适用: 需要定方案、定边界、定依赖关系
+- 不适用: 需求还没确认，或者已经进入具体编码
+
+## Workflow
+
+1. 承接 `requirement-discovery` 的结论。
+2. 说明系统边界、依赖方向和关键 trade-off。
+3. 只输出能指导实现的设计，不写实现细节。
+4. 设计稳定后交给 `task-breakdown`。
+
+## Guardrails
+
+- 不要把设计写成代码说明。
+- 不要绕过关键决策直接进入实现。

package/codex-commands/commands/distill.md

@@ -1,21 +1,21 @@
-# /distill
-
-把业务事实提炼成可复用的领域知识。
-
-## Route
-
-- 对应 skill：`domain-modeling`
-- 适用：领域边界、实体关系、核心概念、规则沉淀
-- 不适用：纯接口变更说明
-
-## Workflow
-
-1. 识别业务对象、边界和核心规则。
-2. 抽取实体、关系、状态和约束。
-3. 输出可复用的领域索引和冲突点。
-4. 不把命名本身当作领域模型。
-
-## Guardrails
-
-- 不忽略规则冲突。
-- 不把实现细节冒充领域知识。
+# /distill
+
+把业务事实和上下文提炼成可复用的业务理解。
+
+## Route
+
+- 对应 skill：`business-analysis`
+- 适用：需要整理业务语义、术语、边界和约束
+- 不适用：只是在写纯接口说明或纯实现说明
+
+## Workflow
+
+1. 识别业务对象、规则和关键术语。
+2. 归纳成稳定、可复用的业务结论。
+3. 如果需要长期留档，再交给 `evidence-collector`。
+4. 不要把命名本身直接当成领域模型结论。
+
+## Guardrails
+
+- 不要忽略业务规则冲突。
+- 不要把实现细节伪装成业务知识。

package/codex-commands/commands/doc.md

@@ -1,22 +1,21 @@
-# /doc
-
-鎶婃帴鍙ｅ拰鍙樻洿鏁寸悊鎴愬彲瀵规帴鐨勬枃妗ｃ€?
-
-## Route
-
-- 瀵瑰簲 skill锛歚api-contract-docs`
-- 閫傜敤锛氭帴鍙ｈ鏄庛€佸彉鏇磋鏄庛€佽仈璋冭鏄庛€佸悓姝ユ枃妗?
-- 涓嶉€傜敤锛氱函浠ｇ爜瀹℃煡
-
-## Workflow
-
-1. 鍏堢‘璁ゆ帴鍙ｈ竟鐣屽拰杈撳叆杈撳嚭銆?
-2. 鎻愮偧璇锋眰銆佸搷搴斻€侀敊璇爜鍜岃皟鐢ㄩ『搴忋€?
-3. 杈撳嚭鍙仈璋冪殑鏂囨。鑽夋銆?
-4. 鍙樻洿鍚庡悓姝ュ埌鐭ヨ瘑娌夋穩銆?
-
-## Guardrails
-
-- 涓嶉仐婕忛敊璇繑鍥炲拰绾︽潫銆?
-- 涓嶆妸绌烘硾璇存槑褰撴垚鏂囨。浜や粯銆?
-
+# /doc
+
+把接口或契约说明收敛成可以落地的设计文档。
+
+## Route
+
+- 对应 skill：`api-design`
+- 适用：接口契约、请求响应、兼容性、字段约束
+- 不适用：纯业务讨论或纯实现任务
+
+## Workflow
+
+1. 先确认要写的是接口、契约还是交付文档。
+2. 把请求、响应、错误和兼容性讲清楚。
+3. 只保留对实现和联调有帮助的信息。
+4. 如果是部署或发布文档，再交给 `deployment-guide`。
+
+## Guardrails
+
+- 不要把 API 文档写成泛化的产品说明。
+- 不要忽略兼容性和错误语义。

package/codex-commands/commands/infra.md

@@ -1,21 +1,21 @@
-# /infra
-
-准备或管理开发依赖的基础设施。
-
-## Route
-
-- 对应 skill：`environment-deploy`
-- 适用：Docker Compose、依赖服务启动、开发联调环境准备
-- 不适用：业务需求分析
-
-## Workflow
-
-1. 识别需要启动的基础设施组件。
-2. 只拉起最小可用组合。
-3. 输出启动状态和常见失败点。
-4. 不把生产部署和本地开发混在一起。
-
-## Guardrails
-
-- 不默认启动多余服务。
-- 不混淆生产环境和本地环境。
+# /infra
+
+准备和管理开发依赖、运行依赖或交付前置环境。
+
+## Route
+
+- 对应 skill：`deployment-guide`
+- 适用：Docker Compose、依赖服务、开发联调环境、启动脚本
+- 不适用：业务需求分析
+
+## Workflow
+
+1. 先识别需要启动或配置的基础设施组件。
+2. 只拉起最小可用组合。
+3. 说明启动状态、常见失败点和恢复办法。
+4. 不要把生产部署和本地开发环境混在一起。
+
+## Guardrails
+
+- 不要默认启动多余服务。
+- 不要混淆生产环境和本地环境。

package/codex-commands/commands/init.md

@@ -1,20 +1,20 @@
-# /init
-
-初始化项目或模块脚手架。
-
-## Route
-
-- 对应 skill：`project-bootstrap`
-- 适用：新建项目、模块初始化、标准目录生成
-- 不适用：业务分析
-
-## Workflow
-
-1. 确认初始化对象是项目还是模块。
-2. 生成标准目录、基础配置和依赖边界。
-3. 输出后续应该进入的 skill。
-4. 不触碰具体业务逻辑。
-
-## Guardrails
-
-- 不跳过基础配置检查。
+# /init
+
+进入新代码库或新模块时，先完成基础认知和落地准备。
+
+## Route
+
+- 对应 skill：`codebase-learning`
+- 适用：首次接手项目、初始化工作区、整理目录和基础约定
+- 不适用：已经明确知道要改什么的实现任务
+
+## Workflow
+
+1. 先确认是项目级还是模块级初始化。
+2. 搞清楚目录结构、依赖入口和基本约定。
+3. 输出后续应该进入的 skill。
+4. 不要在这里直接做业务实现。
+
+## Guardrails
+
+- 不要跳过基础约定检查。

package/codex-commands/commands/kb.md

@@ -1,20 +1,21 @@
-# /kb
-
-把项目事实整理成可检索、可复用、可过期治理的知识中心。
-
-## Route
-
-- 对应 skill：`knowledge-capture`
-- 适用：项目概览、模块索引、领域知识、方案沉淀、交接归档
-
-## Workflow
-
-1. 收集事实、来源、适用场景和限制条件。
-2. 分类沉淀到项目、模块、领域、方案或协作索引。
-3. 标明哪些内容可复用，哪些内容应过期清理。
-4. 让归档结果反哺后续分析和实现。
-
-## Guardrails
-
-- 不堆文档。
-- 不把未经验证的信息当知识沉淀。
+# /kb
+
+把已经验证过的事实沉淀成可复用、可追溯的知识。
+
+## Route
+
+- 对应 skill: `evidence-collector`
+- 适用: 事实沉淀、证据整理、交接总结
+- 不适用: 还没有证据，或者只是猜测
+
+## Workflow
+
+1. 收集来源、证据和适用场景。
+2. 区分事实、推断和未确认内容。
+3. 只沉淀已经验证过的内容。
+4. 如果还要整理业务语义，再交给 `business-analysis`。
+
+## Guardrails
+
+- 不要把未验证内容写成知识。
+- 不要把长文档当成证据。

package/codex-commands/commands/perf.md

@@ -1,21 +1,21 @@
-# /perf
-
-妫€鏌ユ€ц兘鐑偣銆佺摱棰堝拰鍥炲綊椋庨櫓銆?
-
-## Route
-
-- 瀵瑰簲 skill锛歚performance-audit`
-- 閫傜敤锛歂+1銆佺紦瀛樸€佺储寮曘€佹壒閲忔搷浣溿€佺儹鐐硅矾寰?
-- 涓嶉€傜敤锛氱函瀹夊叏瀹℃煡鎴栫函闇€姹傝璁?
-
-## Workflow
-
-1. 鎵惧嚭楂橀璺緞鍜屽ぇ鏁版嵁閲忚矾寰勩€?
-2. 妫€鏌ユ暟鎹簱璁块棶銆佺紦瀛樺懡涓€佸惊鐜皟鐢ㄥ拰鎵瑰鐞嗐€?
-3. 杈撳嚭鍙獙璇佺殑鎬ц兘椋庨櫓鍜屼紭鍖栭『搴忋€?
-4. 蹇呰鏃朵氦缁?`code-review` 鎴?`feature-build`銆?
-
-## Guardrails
-
-- 涓嶇敤娉涙硾寤鸿鏇夸唬瀹氫綅缁撹銆?
-
+# /perf
+
+审查变更里的性能风险，重点看延迟、吞吐、内存和热点路径。
+
+## Route
+
+- 对应 skill: `performance-review`
+- 适用: latency、throughput、memory、load、hot path
+- 不适用: 只需要一般代码审查
+
+## Workflow
+
+1. 找出具体慢路径和资源压力点。
+2. 说明瓶颈类型和影响范围。
+3. 只输出性能相关结论。
+4. 必要时再交给 `code-review` 或 `backend-development`。
+
+## Guardrails
+
+- 不要用“可能会慢”代替具体路径。
+- 不要把性能审查变成实现重写。

package/codex-commands/commands/prd.md

@@ -1,22 +1,21 @@
-# /prd
-
-鎶婁骇鍝佹剰鍥炬敹鍙ｆ垚缁欑爺鍙戝垎鏋愪娇鐢ㄧ殑闇€姹傝緭鍏ャ€?
-
-## Route
-
-- 瀵瑰簲 skill锛歚spec-refinement`
-- 閫傜敤锛氫骇鍝佺洰鏍囥€佷笟鍔¤儗鏅€佽寖鍥磋鍓€佷紭鍏堢骇銆侀獙鏀跺彛寰勩€侀渶姹傚垵绋?
-- 涓嶉€傜敤锛氬凡缁忚繘鍏ュ疄鐜扮粏鑺傜殑鐮斿彂鍒嗘瀽
-
-## Workflow
-
-1. 鍏堢‘璁よ繖鏄骇鍝佷晶闇€姹傦紝涓嶇洿鎺ヨ繘鍏ヨ璁℃垨缂栫爜銆?
-2. 鏀堕泦鐩爣銆佽寖鍥淬€佺害鏉熴€佷紭鍏堢骇鍜岄獙鏀舵爣鍑嗐€?
-3. 杈撳嚭缁撴瀯鍖栫殑 PRD-ready brief銆?
-4. 浜ょ粰 `technical-design`銆?
-
-## Guardrails
-
-- 涓嶆浛浠ｇ爺鍙戦渶姹傚垎鏋愩€?
-- 涓嶈烦杩囬渶姹傛敹鍙ｇ洿鎺ュ啓鏈€缁堢粨璁恒€?
-
+# /prd
+
+把 PRD、brief 或产品说明整理成可交给设计阶段的业务结论。
+
+## Route
+
+- 对应 skill: `business-analysis`
+- 适用: PRD、产品目标、业务规则、角色、业务流程整理
+- 不适用: 已经明确要写实现方案
+
+## Workflow
+
+1. 提炼业务目标、角色、流程和规则。
+2. 区分需求、前提、验收和开放问题。
+3. 用业务语言输出，不提前写技术实现。
+4. 再交给 `architecture-design`。
+
+## Guardrails
+
+- 不要把 PRD 直接改写成代码任务。
+- 不要忽略业务冲突和未决问题。

package/codex-commands/commands/review.md

@@ -1,22 +1,21 @@
-# /review
-
-瀹℃煡浠ｇ爜鍙樻洿銆佽川閲忛闄╁拰璺ㄦā鍧楀奖鍝嶃€?
-
-## Route
-
-- 瀵瑰簲 skill锛歚code-review`
-- 閫傜敤锛歅R 瀹℃煡銆乨iff 瀹℃牳銆佷笂绾垮墠妫€鏌ャ€佹鏋惰鑼冩牳瀵?
-- 涓嶉€傜敤锛氱函闇€姹傝璁?
-
-## Workflow
-
-1. 鍏堢‘璁ゅ彉鏇磋寖鍥达紝涓嶅彧鐪嬪崟鏂囦欢銆?
-2. 鏍稿鏋舵瀯銆佽竟鐣屻€佸洖褰掗闄╁拰绾︽潫銆?
-3. 杈撳嚭闂绾у埆銆侀闄╁拰淇寤鸿銆?
-4. 蹇呰鏃惰ˉ `security-audit` 鎴?`performance-audit`銆?
-
-## Guardrails
-
-- 鍙鏌ュ凡缁忓彂鐢熺殑鍙樻洿銆?
-- 涓嶈烦杩囪瘉鎹洿鎺ヤ笅缁撹銆?
-
+# /review
+
+审查已经提交的变更，重点找出可证实、可执行的质量问题。
+
+## Route
+
+- 对应 skill: `code-review`
+- 适用: diff、PR、重构结果、需要审查的代码变更
+- 不适用: 还没有实现内容可审
+
+## Workflow
+
+1. 先看变更意图和影响面。
+2. 找出正确性、可维护性和回归风险问题。
+3. 只给能落地的审查结论。
+4. 如果发现安全或性能问题，再切到对应 review skill。
+
+## Guardrails
+
+- 不要在 review 阶段重写实现。
+- 不要把未验证的猜测写成结论。

package/codex-commands/commands/security.md

@@ -1,22 +1,21 @@
-# /security
-
-瀹℃煡瀹夊叏椋庨櫓銆佹潈闄愯竟鐣屽拰鏁忔劅鏁版嵁鏆撮湶銆?
-
-## Route
-
-- 瀵瑰簲 skill锛歚security-audit`
-- 閫傜敤锛氬畨鍏ㄥ鏌ャ€佹潈闄愭鏌ャ€佹暟鎹毚闇叉鏌ャ€佸悎瑙勯闄╂鏌?
-- 涓嶉€傜敤锛氭櫘閫氶渶姹傝璁?
-
-## Workflow
-
-1. 鍏堢‘璁よ緭鍏ユ槸宸茬粡鍙戠敓鐨勫彉鏇存垨鍙鏌ョ殑鏂规銆?
-2. 鎷嗗垎鎺ュ彛銆佹潈闄愩€佹暟鎹祦鍚戝拰鏁忔劅淇℃伅椋庨櫓銆?
-3. 杈撳嚭瀹夊叏鍙戠幇銆佷紭鍏堢骇鍜屼慨澶嶅缓璁€?
-4. 蹇呰鏃朵氦缁?`knowledge-capture` 鎴?`feature-build`銆?
-
-## Guardrails
-
-- 涓嶇洿鎺ヤ慨鏀圭敓浜т唬鐮併€?
-- 涓嶆妸涓€鑸川閲忛棶棰樿鍒ゆ垚瀹夊叏缁撹銆?
-
+# /security
+
+审查变更里的认证、权限、数据暴露和滥用风险。
+
+## Route
+
+- 对应 skill: `security-review`
+- 适用: auth、secret、用户输入、数据访问、信任边界
+- 不适用: 只需要一般代码审查
+
+## Workflow
+
+1. 找出可能被不可信输入触达的敏感路径。
+2. 说明攻击面、影响对象和最小修复方式。
+3. 只输出安全相关的审查结论。
+4. 如果需要事实支撑，再交给 `evidence-collector`。
+
+## Guardrails
+
+- 不要把安全审查变成实现重写。
+- 不要把没有证据的风险写成 findings。

package/codex-commands/commands/test.md

@@ -1,21 +1,21 @@
-# /test
-
-把验收标准转成可执行的测试设计。
-
-## Route
-
-- 对应 skill：`test-design`
-- 适用：测试策略、用例设计、回归矩阵、验证路径
-- 不适用：需求还不明确，或者只是想“快速跑一下”
-
-## Workflow
-
-1. 先确认验收标准或实现结果。
-2. 转成测试策略、用例、回归和边界场景。
-3. 输出可执行的验证方案。
-4. 必要时交给 `code-review` 或 `feature-build`。
-
-## Guardrails
-
-- 不跳过前置条件。
-- 不把“跑过一次”当作完整验证。
+# /test
+
+把验证目标落成可执行的测试方案和测试实现。
+
+## Route
+
+- 对应 skill: `unit-test`
+- 适用: 单元测试、边界场景、回归保护
+- 不适用: 需求还不清楚，或者只是想先跑一下
+
+## Workflow
+
+1. 先确认要验证的行为。
+2. 补齐测试策略、用例和边界场景。
+3. 输出可以直接执行的验证方案。
+4. 必要时交给 `regression-check`、`code-review` 或 `backend-development`。
+
+## Guardrails
+
+- 不要跳过前置条件。
+- 不要把“跑一次”当成完整验证。