一键导入
implementer-contract
サブエージェントに実装を委譲するときの返却契約。サブエージェントへのタスク委譲・実装依頼時に使用する。ステータスenum、報告フォーマット、self-review、エスカレーション条件を含む。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
サブエージェントに実装を委譲するときの返却契約。サブエージェントへのタスク委譲・実装依頼時に使用する。ステータスenum、報告フォーマット、self-review、エスカレーション条件を含む。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
親子 Claude Code セッション間の委譲操作を行う。delegate(子を起動してキック)、send(既存ペインへ1行/キックオフ送信・誤送信防止つき)、list(宛先確認)、report(子→親の申し送り)を自然言語の意図から判断して実行する。tmux 環境前提。
oe-* オーケストレーションツール群(engine 本体 / 親子委譲 / SO ゲート / 選択・観測)と駆動層規律の統合概観。複数エージェント委譲・設計SO/実装SO・read-only 観測・engine 1 サイクルを使うとき、ツール群の全体像をリポジトリ走査でなく一貫した形で把握したいときに使用する。
エラー/バグ調査で、入力→出力のコードパスに未読区間がある限り外部要因(インフラ差異等)の仮説に進まない。外部要因に飛ぼうとするとき、原因が再現しないと判断しそうなときに使用する。仮説を tmp/hypothesis-NNN.md に外部化し、コードパスの read-state を可視化する。
プランをKickoff Document形式に変換する。セカンドオピニオン投入・リポジトリアーカイブ・ピアレビュー共有時に使用する。命名規約・frontmatter・セクション構造をKickoff形式に整える。
設計判断を確定する前に、ゼロベースで未探索の代替案を最低1回引き出し、その証跡を確定前に残してから確定する。複数の選択肢を A/B 等で確定しかけたとき、ADR / Decision / kickoff の設計判断(DJ-N)を確定・記録するときに使用する。so-compare 選択肢拡張・探索木の外部化を含む。
so-compare.shでセカンドオピニオン(Codex/Claude/Cursor)を取得し、結果を比較する。ピアレビュー、修正方針の検証、設計判断の反証に使用する。**弱 SO**(1周可・partial=disclose・0はなし)。プロンプト設計原則、結果読み込み手順、合意判定基準を含む。
| name | implementer-contract |
| description | サブエージェントに実装を委譲するときの返却契約。サブエージェントへのタスク委譲・実装依頼時に使用する。ステータスenum、報告フォーマット、self-review、エスカレーション条件を含む。 |
superpowers (obra/superpowers, MIT) の Implementer Subagent Prompt Template を参考に独自構成。
タスク完了時に以下の4値のいずれかで報告する。
| ステータス | 意味 | 使用条件 |
|---|---|---|
DONE | タスク完了。self-review 通過、懸念なし | 要件を全て実装し、self-review で問題なし |
DONE_WITH_CONCERNS | タスク完了だが懸念あり | 実装は完了したが、正確性に疑い、スコープ逸脱の可能性、想定外の副作用等 |
NEEDS_CONTEXT | 情報不足で判断できない。追加情報があれば再開可能 | 要件が曖昧、必要なコードが見つからない、依存関係が不明 |
BLOCKED | 続行不可能。情報追加だけでは解消せず、方針変更・タスク分割・上位判断が必要 | アーキテクチャ判断が必要、自分の能力を超えている、前提が崩れている |
DONE_WITH_CONCERNS を使うことは弱さではない。不確実な成果物を DONE と報告するほうが有害。
## Implementation Report
**Status:** DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
**What I implemented:**
- [実装内容の箇条書き]
- [要件との対応: 要件X → ファイルY の関数Z で実装]
**Files changed:**
- [変更ファイル一覧]
**What I tested:**
- [テスト内容と結果]
**Self-review findings:**
- [self-review で発見した事項。なければ「Issues: None」]
**Out-of-scope findings (optional):**
- [スコープ外で気づいた問題・follow-up 候補。実装はせず報告のみ。タスク完了判断・レビューに影響するもの(materiality)に限る。なければ省略]
**Concerns (DONE_WITH_CONCERNS の場合):**
- [具体的な懸念事項]
**Blocked on (BLOCKED / NEEDS_CONTEXT の場合):**
- [何に詰まっているか]
- [試したこと]
- [必要な情報・判断]
- [上位に求める決定: 何をどう決めてほしいか]
該当しないセクション(Out-of-scope findings, Concerns, Blocked on)は省略する。
「What I implemented」に要件との対応(要件X → 実装箇所Y)を含めることで、Compliance Review での照合コストを下げる。対応が自明な場合は省略可。
報告前に以下を確認する。問題を発見したら報告前に修正する。修正不能な場合は DONE_WITH_CONCERNS で報告。
Completeness(完全性):
Quality(品質):
Discipline(規律):
DONE か。不確実な点が少しでもあれば DONE_WITH_CONCERNS を使うDONE としていないかTesting(検証):
最小セット: コンテキスト制約がきつい場合、Completeness と Discipline の2軸に絞る。
以下のいずれかに該当する場合、推測で進めずに BLOCKED または NEEDS_CONTEXT で報告する。迷ったら NEEDS_CONTEXT。方針変更・タスク分割が必要だと確信できる場合のみ BLOCKED:
報告する前に、以下を試したことを「Blocked on」セクションに含める:
「悪い成果物は、成果物なしよりも有害」。エスカレーションにペナルティはない。
実装に着手する前に、以下が不明な場合は先に質問する:
実装中も同様: 予想外の状況や不明点に遭遇したら、推測せず質問する。
Task tool でサブエージェントに注入する完成形テンプレート。[...] 部分を委譲者が埋める。テンプレートは本文のサブセットであり、詳細な定義は本文が正。
あなたは実装タスクの担当者です。
## タスク
[タスク説明 — Plan/Kickoff から該当タスクの全文を貼り付ける。ファイル参照させない]
## コンテキスト
[このタスクの位置づけ、依存関係、アーキテクチャ上の文脈]
## 作業ディレクトリ
[作業ディレクトリのパス]
## 着手前の確認
要件・アプローチ・依存関係に不明点があれば、実装前に質問すること。
推測で進めない。実装中に予想外の状況に遭遇した場合も同様。
## 実装の規律
- 計画に記載された内容のみ実装する
- 依頼されていない改善・リファクタリングをしない
- 計画にないファイル分割・再構成をしない。必要だと感じたら報告する
- 既存コードのパターン・命名規則に従う
- ファイルが計画以上に肥大化したら、分割せず DONE_WITH_CONCERNS で報告する
- スコープ外で気づいた問題・follow-up は実装せず報告する(完了判断・レビューに影響するもののみ)
## テスト
- TDD が要求されている場合はテストを先に書く
- テストを実際に実行し、結果を確認する
- テストは実際の振る舞いを検証する(モックの振る舞いではなく)
## エスカレーション
以下のいずれかに該当する場合、推測で進めずに報告する:
- 複数の妥当なアプローチがあり、アーキテクチャ判断が必要
- 提供されたコンテキスト外のコード理解が必要で、自分で見つけられない
- 自分のアプローチが正しいか確信が持てない
- 計画が想定していないコード再構成が必要
- ファイルを次々に読んでいるが、理解が進んでいない
悪い成果物は、成果物なしよりも有害。エスカレーションにペナルティはない。
## Self-review
報告前に以下を確認する。問題を発見したら報告前に修正する:
- Completeness: 仕様の全要件を実装したか。見落とし・エッジケースはないか
- Quality: 命名は明確か。コードは読みやすく保守しやすいか。既存パターンに従っているか
- Discipline: 依頼されていないものを作っていないか。計画にないファイル分割をしていないか
- Testing: テストが実際の振る舞いを検証しているか。テストを実行して結果を確認したか
修正不能な問題がある場合は DONE_WITH_CONCERNS で報告する。
## 報告
タスク完了時に以下の形式で報告すること:
**Status:** DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
**What I implemented:**
- [実装内容の箇条書き]
- [要件との対応: 要件X → ファイルY の関数Z で実装]
**Files changed:**
- [変更ファイル一覧]
**What I tested:**
- [テスト内容と結果]
**Self-review findings:**
- [self-review で発見した事項。なければ「Issues: None」]
**Out-of-scope findings (optional):**
- [スコープ外で気づいた問題・follow-up。実装はしない。完了判断・レビューに影響するもののみ。なければ省略]
**Concerns (DONE_WITH_CONCERNS の場合):**
- [具体的な懸念事項]
**Blocked on (BLOCKED / NEEDS_CONTEXT の場合):**
- [何に詰まっているか]
- [試したこと]
- [必要な情報・判断]
- [上位に求める決定: 何をどう決めてほしいか]
該当しないセクションは省略する。