ynitto risk-driven-development
最大リスクを起点に、変更の順序・検証方法・停止条件を決めてから実装を進める。
このスキルは プライマリスキルではなく補助スキル として使うのが基本である。対象の実装・変更そのものは既存の実装系スキルに委譲し、本スキルは「何から・どの順で・どこで止まるか」を管理する。
駆動源の定義
このスキルの駆動源は リスク である。ここでいうリスクは、次のいずれかを指す。
- 変更失敗時の影響が大きい
- 仕様や挙動の不確実性が高い
- 巻き込み範囲が読みにくい
- 戻しにくい、あるいは観測しにくい
- 変更順序を誤ると壊れやすい
判断は「工数が大きいか」ではなく、先に小さく潰すべき危険が何か で行う。
パス解決
このSKILL.mdが置かれているディレクトリを SKILL_DIR、その親ディレクトリを SKILLS_DIR とする。他スキルは ${SKILLS_DIR}/[skill-name]/SKILL.md を優先して探す。
Step 0: スコーピング
最初に、このスキルを本当に適用すべきかを判定する。
適用する
- 実装またはコード変更が発生する
- TDD を厳密に回しにくい
- 変更順序や段階投入を決めた方が安全
- 手動確認、静的チェック、限定実行などの軽量検証が可能
- UI、設定、CI、インフラ、探索実装、軽量リファクタなどで破壊範囲の管理が重要
適用しない
- 純粋な調査のみ
- 単純な文書更新のみ
- 影響範囲が極小で、順序設計や停止条件が不要
- API 契約や入出力境界の固定が主眼で、
contract-driven-developmentの方が適切 - 異常系・回復戦略の設計が主眼で、
failure-driven-development相当の方が適切
Step 0 の出力
以下を 3 行以内で明示する。
適用判定: APPLY / SKIP
主理由: [1文]
代替: [なし / 代替スキル名]
ゲート条件: APPLY と判定できた場合のみ Phase 1 へ進む。SKIP の場合は理由と代替を返して終了する。
Phase 1: リスク棚卸し
変更対象を読み、候補リスクを列挙する。最低でも次の観点を見る。
| 観点 | 確認内容 |
|---|---|
| 影響度 | 壊れたときに何が止まるか |
| 不確実性 | 仕様・既存挙動・依存関係のどこが曖昧か |
| 可逆性 | すぐ戻せるか、フラグや分岐で逃がせるか |
| 可観測性 | 成否をどこで確認できるか |
| 波及範囲 | 何ファイル・何レイヤー・何利用者に広がるか |
| 依存順序 | 先に変えると危ない箇所はどこか |
各リスクは次の形式で整理する。
- R1: [リスク名]
影響: High / Medium / Low
不確実性: High / Medium / Low
可逆性: High / Medium / Low
初期対策: [1文]
優先順位付けルール:
- まず
影響 = Highかつ不確実性 = Highを最優先にする - 同率なら
可逆性が低いものを先に扱う - それでも並ぶ場合は
最小検証で潰せるものを先にする
ゲート条件: 最大リスク 1 件を明示できること。曖昧なら追加調査を 1 回だけ行い、それでも絞れなければユーザーに相談する。
Phase 2: 最小検証の設計
最大リスクを丸ごと解こうとせず、最小変更で事実確認できる検証単位 に落とす。
以下を決める。
- 最初に試す最小変更
- 1ファイル、1設定、1分岐、1コンポーネントなど、可能な限り小さくする
- 検証方法
- 手動確認
- 静的チェック
- 限定テスト
- 限定実行
- ログ・差分確認
- 成功条件
- 何が確認できれば次へ進んでよいか
- 失敗条件
- どの兆候が出たら止めるか
出力形式:
最大リスク: [R番号]
最小変更: [何を最初に変えるか]
検証方法: [どう確かめるか]
成功条件: [次へ進める条件]
失敗条件: [停止条件]
ゲート条件: 実装前に「成功条件」と「失敗条件」の両方が定義されていること。片方でも欠けていたら Phase 2 をやり直す。
Phase 3: 段階適用計画
Phase 2 の最小検証を起点に、変更全体を段階化する。
各段階は以下の粒度で書く。
Stage 1: [最小検証]
目的: [何を確かめるか]
実施: [主に使うプライマリスキル]
確認: [実施後のチェック]
失敗時: [戻し方 or 凍結条件]
Stage 2: [次の拡張]
...
ルール
- いきなり本命変更を入れない
- ステージをまたいで複数の新規リスクを同時に開かない
- 各ステージの完了条件を明示する
- 戻し方がないステージは、原則として最後に置く
ゲート条件: すべてのステージに 確認 と 失敗時 があること。なければ計画不備として修正する。
Phase 4: 実行管理
プライマリスキルに実装を委譲しつつ、各ステージの前後で以下を必ず確認する。
ステージ開始前
- このステージで新たに開くリスクは 1 つに抑えられているか
- 失敗時の戻し方が残っているか
- 検証方法が実行可能か
ステージ完了後
- 成功条件を満たしたか
- 想定外の副作用が出ていないか
- 次のステージへ進む価値があるか
各ステージの結果は次の形式で記録する。
=== Risk Stage [N] ===
対象: [ステージ名]
結果: PASS / HOLD / FAIL
確認結果: [要約]
次アクション: 次へ進む / 同ステージ再試行 / 計画見直し / ユーザー相談
HOLD の扱い
FAIL ではないが不確実性が残る場合は HOLD とし、次のどちらかを選ぶ。
- 追加の最小検証を 1 回だけ挿入する
- その時点でユーザーに相談する
ゲート条件: PASS のステージだけ次へ進める。HOLD と FAIL はそのまま先送りしない。
Phase 5: 完了レポート
最後に、リスク起点でどう進めたかを短くまとめる。
## Risk-Driven 完了レポート
最大リスク: [内容]
最初の最小検証: [内容]
実施ステージ数: [N]
停止・保留の有無: [なし / 内容]
残留リスク: [なし / 内容]
推奨次アクション: [1〜3件]
verdict-json
<!-- 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になったリスクを説明なく先送りする」
このスキルの目的は速度ではなく、危険を早く小さく露出させること である。