菜单
API 契約、I/O 契約、モジュール境界を先に固定してから安全に実装を進める実行手法スキル。入出力、境界条件、互換性、契約テスト観点を整理し、主に API 開発や境界のある実装系スキルの補助として使う。「契約から先に固めたい」「API 契約を決めてから実装して」「I/O を固定して進めたい」「境界条件を先に整理したい」などで発動する。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/ynitto/sandbox --skill contract-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 | contract-driven-development |
| description | API 契約、I/O 契約、モジュール境界を先に固定してから安全に実装を進める実行手法スキル。入出力、境界条件、互換性、契約テスト観点を整理し、主に API 開発や境界のある実装系スキルの補助として使う。「契約から先に固めたい」「API 契約を決めてから実装して」「I/O を固定して進めたい」「境界条件を先に整理したい」などで発動する。 |
| metadata | {"version":"1.0.0","tier":"experimental","category":"implementation","tags":["contract-driven","api-contract","interface-design","compatibility"]} |
API 契約、I/O 契約、モジュール境界を先に固定し、その契約を破らない形で実装を進める。
このスキルは プライマリスキルではなく補助スキル として使うのが基本である。実装そのものは既存の実装系スキルに委譲し、本スキルは「何を契約として固定するか」「互換性をどう守るか」「何で契約充足を確認するか」を管理する。
このスキルの駆動源は 契約 である。ここでいう契約は、少なくとも次のいずれかを含む。
判断は「何を作るか」より先に、何を守れば統合が壊れないか で行う。
このSKILL.mdが置かれているディレクトリを SKILL_DIR、その親ディレクトリを SKILLS_DIR とする。他スキルは ${SKILLS_DIR}/[skill-name]/SKILL.md を優先して探す。
最初に、このスキルを本当に適用すべきかを判定する。
risk-driven-development の方が適切failure-driven-development 相当の方が適切適用判定: APPLY / SKIP
契約対象: [API / モジュール / イベント / その他]
代替: [なし / 代替スキル名]
ゲート条件: APPLY の場合のみ Phase 1 へ進む。SKIP の場合は理由と代替を返して終了する。
最初に、どの境界を契約として扱うかを決める。
最低でも次を列挙する。
| 観点 | 確認内容 |
|---|---|
| 提供者 | 契約を満たす側は誰か |
| 利用者 | 契約に依存する側は誰か |
| 入力 | 必須項目、型、制約、順序 |
| 出力 | 正常系、異常系、型、意味 |
| 境界条件 | 空、最大値、欠損、重複、順序違い |
| 互換性 | 何が breaking で何が non-breaking か |
出力形式:
契約名: [名称]
提供者: [コンポーネント名]
利用者: [クライアント / モジュール]
対象境界: [何と何の境界か]
ゲート条件: 契約対象が 1 つ以上具体化されていること。誰が使うかわからない契約は固定してはならない。
契約を実装前の基準として書き下す。形式は対象に合わせてよいが、最低限次の要素を持たせる。
以下のどれか、または複数を選ぶ。
契約サマリー:
- 入力: [要約]
- 出力: [要約]
- 境界条件: [要約]
- breaking 条件: [要約]
- non-breaking 条件: [要約]
ゲート条件: 入力・出力・境界条件・互換性ルールの 4 つがすべて揃っていること。1つでも欠けていれば Phase 2 をやり直す。
実装の前に、契約が満たされたかを何で確認するかを決める。
契約テストは実コードでなくてもよいが、最低でも以下の観点を持つ。
出力形式:
契約テスト観点:
- CT1: [正常系]
- CT2: [必須欠落]
- CT3: [型・制約違反]
- CT4: [境界値]
- CT5: [互換性確認]
ゲート条件: 最低 3 観点、可能なら 5 観点を列挙すること。互換性のある境界なら CT5 を省略しない。
ここから先の実装はプライマリスキルに委譲するが、以下を実装開始前に固定する。
実装に渡すべき要約:
実装前提:
- 守る契約: [名称]
- 重要な境界条件: [要約]
- 禁止事項: [黙った breaking change など]
- 検証方法: [契約テスト観点 or schema validation]
ゲート条件: 実装を始める前に「守る契約」が 1 つに定まっていること。複数版が併存する状態で進めてはならない。
最後に、固定した契約と実装への影響を短くまとめる。
## Contract-Driven 完了レポート
契約対象: [内容]
固定した契約: [形式と要約]
契約テスト観点数: [N]
breaking change の有無: [なし / あり]
残留未確定事項: [なし / 内容]
推奨次アクション: [1〜3件]
<!-- verdict-json -->
{
"skill": "contract-driven-development",
"verdict": "PASS | HOLD | FAIL",
"contract_target": "[summary]",
"contract_format": "[schema/table/signature]",
"blocking": false,
"open_questions": []
}
<!-- /verdict-json -->
api-designer — API 契約の固定と OpenAPI / GraphQL 生成requirements-definer — 契約に落とす前の要求整理react-frontend-coder — API 契約確定後のクライアント実装test-driven-development — 契約テストを先頭に置く場合のサイクル管理risk-driven-development を優先するfailure-driven-development 系を優先するrequirements-definer や brainstorming で整理する| 状況 | 対応 |
|---|---|
| 利用者が不明で契約対象が定まらない | 契約を固定せず、対象の利用者と境界を追加確認する |
| 実装中に契約変更が必要になった | 実装を止めて Phase 2 に戻る |
| breaking / non-breaking の線引きが曖昧 | 既存利用者影響を優先し、曖昧な間は breaking 扱いにする |
| 契約テスト観点が定義できない | 契約が抽象的すぎるため、入力・出力を具体化し直す |
| 2 回以上契約が揺れる | 契約前提が未熟と判断し、ユーザーに再確認する |
このスキルの目的は、実装前に境界を固定して統合コストを下げること である。