菜单
TDD が適さない変更系タスクを、最大リスク起点で安全に進める実行手法スキル。変更対象のリスク棚卸し、最小検証、段階適用、停止条件を定義し、主に実装系・変更系スキルの補助として使う。「リスクを見ながら実装して」「安全に段階導入したい」「まず危ないところから潰したい」「変更順序と停止条件を決めて」などで発動する。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/ynitto/sandbox --skill risk-driven-development命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | risk-driven-development |
| description | TDD が適さない変更系タスクを、最大リスク起点で安全に進める実行手法スキル。変更対象のリスク棚卸し、最小検証、段階適用、停止条件を定義し、主に実装系・変更系スキルの補助として使う。「リスクを見ながら実装して」「安全に段階導入したい」「まず危ないところから潰したい」「変更順序と停止条件を決めて」などで発動する。 |
| metadata | {"version":"1.0.0","tier":"experimental","category":"implementation","tags":["risk-driven","incremental-change","safety-gate","implementation-method"]} |
最大リスクを起点に、変更の順序・検証方法・停止条件を決めてから実装を進める。
このスキルは プライマリスキルではなく補助スキル として使うのが基本である。対象の実装・変更そのものは既存の実装系スキルに委譲し、本スキルは「何から・どの順で・どこで止まるか」を管理する。
このスキルの駆動源は リスク である。ここでいうリスクは、次のいずれかを指す。
判断は「工数が大きいか」ではなく、先に小さく潰すべき危険が何か で行う。
このSKILL.mdが置かれているディレクトリを SKILL_DIR、その親ディレクトリを SKILLS_DIR とする。他スキルは ${SKILLS_DIR}/[skill-name]/SKILL.md を優先して探す。
最初に、このスキルを本当に適用すべきかを判定する。
contract-driven-development の方が適切failure-driven-development 相当の方が適切以下を 3 行以内で明示する。
適用判定: APPLY / SKIP
主理由: [1文]
代替: [なし / 代替スキル名]
ゲート条件: APPLY と判定できた場合のみ Phase 1 へ進む。SKIP の場合は理由と代替を返して終了する。
変更対象を読み、候補リスクを列挙する。最低でも次の観点を見る。
| 観点 | 確認内容 |
|---|---|
| 影響度 | 壊れたときに何が止まるか |
| 不確実性 | 仕様・既存挙動・依存関係のどこが曖昧か |
| 可逆性 | すぐ戻せるか、フラグや分岐で逃がせるか |
| 可観測性 | 成否をどこで確認できるか |
| 波及範囲 | 何ファイル・何レイヤー・何利用者に広がるか |
| 依存順序 | 先に変えると危ない箇所はどこか |
各リスクは次の形式で整理する。
- R1: [リスク名]
影響: High / Medium / Low
不確実性: High / Medium / Low
可逆性: High / Medium / Low
初期対策: [1文]
優先順位付けルール:
影響 = High かつ 不確実性 = High を最優先にする可逆性が低い ものを先に扱う最小検証で潰せるもの を先にするゲート条件: 最大リスク 1 件を明示できること。曖昧なら追加調査を 1 回だけ行い、それでも絞れなければユーザーに相談する。
最大リスクを丸ごと解こうとせず、最小変更で事実確認できる検証単位 に落とす。
以下を決める。
出力形式:
最大リスク: [R番号]
最小変更: [何を最初に変えるか]
検証方法: [どう確かめるか]
成功条件: [次へ進める条件]
失敗条件: [停止条件]
ゲート条件: 実装前に「成功条件」と「失敗条件」の両方が定義されていること。片方でも欠けていたら Phase 2 をやり直す。
Phase 2 の最小検証を起点に、変更全体を段階化する。
各段階は以下の粒度で書く。
Stage 1: [最小検証]
目的: [何を確かめるか]
実施: [主に使うプライマリスキル]
確認: [実施後のチェック]
失敗時: [戻し方 or 凍結条件]
Stage 2: [次の拡張]
...
ゲート条件: すべてのステージに 確認 と 失敗時 があること。なければ計画不備として修正する。
プライマリスキルに実装を委譲しつつ、各ステージの前後で以下を必ず確認する。
各ステージの結果は次の形式で記録する。
=== Risk Stage [N] ===
対象: [ステージ名]
結果: PASS / HOLD / FAIL
確認結果: [要約]
次アクション: 次へ進む / 同ステージ再試行 / 計画見直し / ユーザー相談
FAIL ではないが不確実性が残る場合は HOLD とし、次のどちらかを選ぶ。
ゲート条件: PASS のステージだけ次へ進める。HOLD と FAIL はそのまま先送りしない。
最後に、リスク起点でどう進めたかを短くまとめる。
## Risk-Driven 完了レポート
最大リスク: [内容]
最初の最小検証: [内容]
実施ステージ数: [N]
停止・保留の有無: [なし / 内容]
残留リスク: [なし / 内容]
推奨次アクション: [1〜3件]
<!-- verdict-json -->
{
"skill": "risk-driven-development",
"verdict": "PASS | HOLD | FAIL",
"max_risk": "[summary]",
"stages_completed": 0,
"blocking": false,
"residual_risks": []
}
<!-- /verdict-json -->
react-frontend-coder — UI の段階実装、影響範囲の見極めci-cd-configurator — 設定変更の段階投入、限定検証code-simplifier — リファクタの順序設計と停止条件管理systematic-debugging — 既知バグ修正時の危険箇所の先行把握test-driven-development を優先するcontract-driven-development を優先するfailure-driven-development / error-recovery-strategist 系を優先する| 状況 | 対応 |
|---|---|
| 最大リスクを絞れない | 追加調査を 1 回だけ実施し、それでも曖昧ならユーザーに相談 |
| 検証方法が存在しない | 変更を分割し直す。どうしても不可なら HOLD として相談 |
| ステージ途中で副作用が広がった | そのステージを中断し、戻し方を実行して Phase 1 に戻る |
2 ステージ連続で HOLD | 現行計画は不適切とみなし、ユーザーに判断を仰ぐ |
| 可逆性が低い変更しか残っていない | 最終段に隔離し、明示的な承認を取ってから進む |
HOLD になったリスクを説明なく先送りする」このスキルの目的は速度ではなく、危険を早く小さく露出させること である。