菜单
異常系、失敗モード、検知方法、回復手段を先に定義してから安全に実装を進める実行手法スキル。障害の起こり方、検出、フォールバック、劣化運転、利用者影響を整理し、主に可用性や回復性が重要な実装系スキルの補助として使う。「失敗モードから先に考えたい」「異常系を先に固めて実装したい」「回復手段を決めてから進めたい」「障害時の振る舞いを先に設計したい」などで発動する。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/ynitto/sandbox --skill failure-driven-development命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
会話中の話題を、最小の視覚表現（擬似コード・呼び出しツリー・コンポーネントツリー・ファイルツリー・Mermaid・diff・HTML）で見せて理解を助けるスキル。「図で説明して」「見せて」「視覚的に説明して」「イメージで教えて」「構造を見せて」「どう変わるのか見せて」「show me」などで発動する。説明が長文になりそうなときに、文章の代わりに図で示す。
agent-flow の orchestrator 向け高精度タスク分解・戦略選択スキル。要求を分析し、7パターン（map-reduce 含む）＋複合パターンから最適な戦略を選定し、実行可能なタスクグラフを生成する。decomposition スキルの分解能力を内包し、agent-flow の `--planner flow-planner` で利用する。
セッションをまたいで知識・決定事項を継続させたいときのスキル。「覚えておいて」でsave、「思い出して」でrecall、「記憶一覧」でlist、「忘れて」でarchive、「共有して」でshare、「整理して」でcleanup、「役立った／間違ってた」でrate、「固定化して」でconsolidate。重要な知見を発見したら自律的にsaveを実行すること。
基于 SOC 职业分类
正在显示 SKILL.md
| name | failure-driven-development |
| description | 異常系、失敗モード、検知方法、回復手段を先に定義してから安全に実装を進める実行手法スキル。障害の起こり方、検出、フォールバック、劣化運転、利用者影響を整理し、主に可用性や回復性が重要な実装系スキルの補助として使う。「失敗モードから先に考えたい」「異常系を先に固めて実装したい」「回復手段を決めてから進めたい」「障害時の振る舞いを先に設計したい」などで発動する。 |
| metadata | {"version":"1.0.0","tier":"experimental","category":"implementation","tags":["failure-driven","resilience","fallback","failure-mode"]} |
失敗モード、検知方法、回復手段を先に定義し、その失敗に耐える形で実装を進める。
このスキルは プライマリスキルではなく補助スキル として使うのが基本である。実装そのものは既存の実装系スキルに委譲し、本スキルは「何が壊れうるか」「どう検知するか」「どこまで劣化を許容するか」「どう回復するか」を先に固定する。
このスキルの駆動源は 失敗モード である。ここでいう失敗モードは、次のいずれかを含む。
判断は「正常系が通るか」ではなく、失敗したときにどこまで壊れずに済むか で行う。
このSKILL.mdが置かれているディレクトリを SKILL_DIR、その親ディレクトリを SKILLS_DIR とする。他スキルは ${SKILLS_DIR}/[skill-name]/SKILL.md を優先して探す。
最初に、このスキルを本当に適用すべきかを判定する。
contract-driven-development の方が適切risk-driven-development の方が適切systematic-debugging の方が適切適用判定: APPLY / SKIP
主な失敗領域: [依存先 / 入力 / 非同期 / 可用性 / その他]
代替: [なし / 代替スキル名]
ゲート条件: APPLY の場合のみ Phase 1 へ進む。SKIP の場合は理由と代替を返して終了する。
最初に、正常系ではなく 先に壊れ方 を列挙する。最低でも次の観点を見る。
| 観点 | 確認内容 |
|---|---|
| 起点 | 何が失敗を引き起こすか |
| 影響範囲 | 誰に・どこに影響するか |
| 検知 | どの信号で気づくか |
| 回復 | 自動回復 / 手動回復 / フォールバックのどれか |
| 許容劣化 | 何を捨ててよいか |
| 再発性 | 一時的か、継続的か、再試行で直るか |
各失敗モードは次の形式で整理する。
- F1: [失敗モード名]
起点: [原因]
影響: High / Medium / Low
検知: [ログ / メトリクス / 画面 / 例外]
回復候補: [再試行 / フォールバック / 劣化運転 / 停止]
優先順位付けルール:
影響 = High の失敗モードを先に扱う検知しづらい ものを優先する回復手段が未定 のものを先にするゲート条件: 最優先の失敗モードを 1 件以上明示できること。失敗モードを挙げられない場合は、依存先と利用者影響の理解が不足しているので追加確認する。
最優先の失敗モードごとに、何で気づき、どう振る舞うかを決める。
失敗モード: [F番号]
検知方法: [どう気づくか]
一次対応: [最初にどう振る舞うか]
回復手段: [どう戻すか]
許容劣化: [何を維持し何を落とすか]
ゲート条件: 検知方法と回復手段の両方が定義されていること。どちらかが欠けた失敗モードは未設計とみなす。
定義した失敗モードを、実装時のガードレールへ落とす。
最低でも次を定義する。
出力形式:
実装ルール:
- R1: [timeout / retry / fallback / fail-fast / degraded mode]
- R2: ...
ゲート条件: 少なくとも 3 個の具体的な実装ルールに変換されていること。抽象的な「気をつける」では不十分。
正常系テストだけで終わらないよう、異常系観点を先に定義する。
最低でも次を含める。
出力形式:
異常系テスト観点:
- FT1: [依存失敗]
- FT2: [timeout]
- FT3: [retry 上限]
- FT4: [fallback / degraded mode]
- FT5: [observability]
ゲート条件: 失敗モードに対応する検証観点が 1 つ以上紐づいていること。検証不能な設計は再設計する。
最後に、先に定義した失敗モードと回復戦略を短くまとめる。
## Failure-Driven 完了レポート
最重要失敗モード: [内容]
検知方法: [要約]
回復手段: [要約]
許容劣化: [要約]
異常系テスト観点数: [N]
残留リスク: [なし / 内容]
推奨次アクション: [1〜3件]
<!-- verdict-json -->
{
"skill": "failure-driven-development",
"verdict": "PASS | HOLD | FAIL",
"primary_failure_mode": "[summary]",
"blocking": false,
"residual_risks": [],
"degraded_modes": []
}
<!-- /verdict-json -->
api-designer — 異常系レスポンスと fallback 契約の設計react-frontend-coder — 依存失敗時の UI 劣化表示や再試行設計ci-cd-configurator — ジョブ失敗、再試行、fail-fast 方針の設計systematic-debugging — 事前に設計した失敗モードを、実障害時の仮説に接続するsystematic-debugging を優先するrisk-driven-development を優先するcontract-driven-development を優先する| 状況 | 対応 |
|---|---|
| 失敗モードが列挙できない | 依存先、入力、非同期処理、利用者影響を追加確認する |
| 検知方法がない | 実装前に observability を足す方針を決める |
| 回復手段が決まらない | fail-fast と degraded mode のどちらかを明示的に選ぶ |
| 許容劣化が決まらない | 利用者影響を優先して、何を守るかをユーザーに確認する |
| 検証観点が作れない | 失敗モード定義が抽象的すぎるため、Phase 1 に戻る |
このスキルの目的は、失敗しても壊れ方を制御できる状態を先に作ること である。