implement

機能の実装

ホストに依存しないワークフローです。スキル名（implement）で呼び出します。Claude Code のスラッシュルーティング、YAML フックローダー、.claude/chain については、references/claude-code.md を参照してください。

スコープを制御し、振り返りを行いながら、サブエージェントを並列実行して機能を実装します。

クイックスタート

implement user authentication
implement --model=opus real-time notifications
implement dashboard analytics

---

引数の解決

ほかの手順より先に、対象を確認してください。 このスキルはフォークされるため、会話を参照できません。Read("../../shared/rules/target-resolution.md") を読み込みます。対象からフラグを除いたものが、単独の代名詞または指示語（this、them、that one）であるか、空の場合は、TARGET_UNRESOLVED: <word> をそのまま返して停止します。呼び出し元が対象を解決してから、再度呼び出します。

FEATURE_DESC = "$ARGUMENTS"  # Full argument string, e.g., "user authentication"
# $ARGUMENTS[0] is the first token, $ARGUMENTS[1] second, etc. (CC 2.1.59)

# Model override detection (CC 2.1.72)
MODEL_OVERRIDE = None
for token in "$ARGUMENTS".split():
    if token.startswith("--model="):
        MODEL_OVERRIDE = token.split("=", 1)[1]  # "opus", "sonnet", "haiku", "fable"
        FEATURE_DESC = FEATURE_DESC.replace(token, "").strip()

MODEL_OVERRIDE が設定されている場合は、すべての Agent() 呼び出しに model=MODEL_OVERRIDE として渡します。シンボリック名（opus、sonnet、haiku、Agent ツールに記載されているハーネスでの fable。なお、fable は 2026-07-12 以降、プレミアム API の利用料金が発生します）または CC 2.1.74 に準拠した完全な ID（claude-opus-5-5）を指定できます。

---

ステップ -1：MCP の確認と再開チェック

ほかの手順より先に実行してください。 利用可能な MCP サーバーを検出し、再開可能な状態があるか確認します。

# Probe MCPs (parallel — all in ONE message):
# memory is alwaysLoad in .mcp.json (CC 2.1.121+, #1541) — probe below kept as fallback for older CC:
ToolSearch(query="select:mcp__memory__search_nodes")
ToolSearch(query="select:mcp__context7__resolve-library-id")

Write(".claude/chain/capabilities.json", JSON.stringify({
  "memory": <true if found>,
  "context7": <true if found>,
  "timestamp": now()
}))

# Resume check:
Read(".claude/chain/state.json")
# If exists and skill == "implement":
#   Read last handoff (e.g., 04-architecture.json)
#   Skip to current_phase
#   "Resuming from Phase {N} — architecture decided in previous session"
# If not: write initial state
Write(".claude/chain/state.json", JSON.stringify({
  "skill": "implement", "feature": FEATURE_DESC,
  "current_phase": 1, "completed_phases": [],
  "capabilities": capabilities,
  "budget_remaining_pct": 100  // advisory; see Budget Awareness below
}))

バッチサイズの管理（大規模なリファクタリング）

実装で10 ファイルを超える場合は、エージェント 1 バッチあたり最大 5 ファイルに制限し、バッチ間でテストを実行し、テストに合格したバッチはすぐにコミットし、失敗したら停止してください。--batch-size N で上書きできます。詳細なルールについては、Read("rules/batch-governance.md") を参照してください。

予算の把握（Opus 5.5 のタスク予算、パブリックベータ）

Opus 5.5 では、タスクごとのトークン予算が公開されています。CC 側で GA になるまでは、OrchestKit が state.json 内の参考値 budget_remaining_pct を追跡し、長時間の実行で自動的に消費を抑えます。各フェーズの後に更新してください。

# At end of every phase, estimate remaining budget:
pct = tokensAsContextPct(tokensUsedSoFar)  # from lib/context-window.ts
remaining = max(0, 100 - pct)
state["budget_remaining_pct"] = remaining
Write(".claude/chain/state.json", JSON.stringify(state))

残り予算に応じて動作を調整します。

残り	動作
> 50%	通常 — 任意の詳細化（反対意見の検討、ビジュアルの記録、詳細な探索）をすべて実施します。
20-50%	効率重視 — 任意の詳細化は省略し、中核フェーズを維持します。ユーザーへの警告は一度だけ行います。
< 20%	節約 — 現在のフェーズを完了し、次の手順を引き継ぎとして出力して、新しい作業は開始しません。

CC のネイティブなタスク予算 API が GA になったら、推定値を実際の値に置き換えます。しきい値と動作は変わりません。

読み込み：Read("../chain-patterns/references/checkpoint-resume.md")

---

ステップ -0.5：評価判定ゲート

.claude/chain/assess-verdict.json が存在し、この実行に一致する feature があり、verdict == "fail" の場合（複合スコアが ../assess/rubric.json の 5.5 の min_pass 未満、または任意の評価項目が min_blocker 未満の場合）、フェーズ 1 をブロックします。各 blockers[] エントリ（評価項目、スコア、理由）を提示し、その後、preview を含まないラベルと説明だけの選択肢で AskUserQuestion を行います。

1. まず阻害要因を解消する（推奨） — 阻害要因に対処し、assess を再実行してから、ここに戻ります。
2. 上書きして実装する — そのまま進め、state.json に "assess_gate": "overridden" を記録し、阻害要因をフェーズ 1 のコンテキストに引き継ぎます。

ファイルが存在しない場合、または verdict == "pass" の場合は、ゲートを設けず、ステップ 0 に進みます。

---

ステップ 0：作業量に応じたフェーズの調整（CC 2.1.76、xhigh は 2.1.111 で追加）

/effort の設定を読み込み、実装の詳細度を調整します。作業量に応じたコンテキスト予算のフックが作業量レベルを自動検出するため、それに合わせてフェーズ計画を調整してください。

作業量レベル	実行するフェーズ	エージェント	トークン予算
low	1（調査）→ 5（実装）→ 10（振り返り）	最大 2	約 50K
medium	1 → 2 → 5 → 7（スコープの逸脱）→ 10	最大 3	約 150K
high	10 フェーズすべて	4～7	約 400K
xhigh（Opus 5、CC 2.1.111 以降）	10 フェーズすべて + テスト失敗時、エスカレーション前に追加の修復を 1 回実施	4～7	約 550K

上書き： ステップ 0 でユーザーが明示的に選択した内容（例：「先に計画」や「ワークツリー」）は、/effort による縮小より優先されます。ユーザーが詳細な探索を求めた場合は、作業量レベルにかかわらずそれに従ってください。low が適切なのは、仕様が完全で機械的な作業に限られます。また、low で実行した場合は、常に /ork:verify の high に引き継ぎます。Read("references/effort-ladder.md") を参照してください。

ステップ 0a：プロジェクトコンテキストの確認

作業を始める前に、プロジェクトのティアを判定してください。これが、すべてのパターンの複雑さの上限になります。

コードベースの兆候を調べ、ティア 1〜6（Interview から Open Source）に分類します。各ティアによって、アーキテクチャの上限が設定され、使用するフェーズとエージェントが決まります。

ティアの詳細、ワークフローの対応関係、オーケストレーションモードを読み込みます：Read("references/tier-classification.md")

プロジェクトコンテキストを読み込みます。 フォークされたスキルではフロントマターのフックが実行されないため（#4683）、ローダーを自分で実行し、そのadditionalContextを念頭に置いてください。

echo '{"tool_name":"Bash","tool_input":{}}' | node "${CLAUDE_PLUGIN_ROOT}/hooks/bin/run-hook.mjs" skill/project-convention-loader
echo '{"tool_name":"Bash","tool_input":{}}' | node "${CLAUDE_PLUGIN_ROOT}/hooks/bin/run-hook.mjs" skill/implement-standards-loader
git rev-parse HEAD  # note it as the start sha for the Phase 6 pattern check

ワークツリーの分離（CC 2.1.49）

5 個以上のファイルに影響する機能では、メインのワーキングツリーとの競合を防ぐため、ワークツリーの分離を提案してください。

AskUserQuestion(questions=[{
  "question": "Isolate this feature in a git worktree?",
  "header": "Isolation",
  "options": [
    {"label": "Yes — worktree (Recommended)", "description": "Creates isolated branch via EnterWorktree, merges back on completion"},
    {"label": "No — work in-place", "description": "Edit files directly in current branch"},
    {"label": "Plan first", "description": "Research and design in plan mode before writing code"}
  ],
  "multiSelect": false
}])

「Plan first」が選択された場合：

# 1. Enter read-only plan mode
EnterPlanMode("Research and design: $ARGUMENTS")

# 2. Research phase — Read/Grep/Glob ONLY, no Write/Edit
#    - Read existing code in the target area
#    - Grep for related patterns, imports, dependencies
#    - Check tests, configs, and integration points
#    - If context7 available: query library docs

# 3. Design the plan — produce:
#    - File map: which files to create/modify
#    - Architecture decisions with rationale
#    - Task breakdown with acceptance criteria
#    - Risk assessment and edge cases

# 4. Exit plan mode — returns plan to user for approval
ExitPlanMode()

# 5. User reviews plan. If approved → continue to Phase 1 (Discovery)
#    with the plan as input. If rejected → revise or stop.

ワークツリーが選択された場合：

1. EnterWorktree(name: "feat-{slug}")を呼び出して、分離されたブランチを作成します
2. すべてのエージェントがワークツリーディレクトリで作業します
3. 完了したら、変更をマージします：git checkout {original-branch} && git merge feat-{slug}
4. マージの競合が発生した場合は、AskUserQuestionを使って差分をユーザーに提示します

ワークツリーの詳細を読み込みます：Read("references/worktree-isolation-mode.md")

---

ステップ 0b：影響範囲の確認（「方法」の前に「内容」を尋ねる）

フェーズ 1 の前に、回答によってアーキテクチャが変わる可能性のある不明点を、影響範囲の大きい順に解決します。スキーマ／マイグレーション → 認証 → API 契約 → パフォーマンス／スケーラビリティ → 外観（最後）の順です。まず grep し、その後で一度に 1 つずつAskUserQuestionを使って確認します（影響の大きいものから、最大約 5 件まで。明らかなものは省略します）。各回答は Decisions テーブルの行として.claude/chain/decisions.jsonと PR 本文に記録され、制約としてフェーズ 4（アーキテクチャ）に引き継がれます。未解決のスキーマ／認証に関する質問がある状態でフェーズ 1 を開始してはいけません。作業量がlowの場合は省略します。プロトコルの全文：Read("references/blast-radius-clarification.md")

---

完了の条件。 完了とは、計画したすべてのファイルが書き込まれ、新規および既存のテストが合格し、スコープの拡大がないことを確認でき、E2E 検証が実行された状態です。Read("../../shared/rules/long-run-protocol.md")に従ってください。ユーザーからの入力が不要なステップは続行し、ユーザーなしでは続行できない場合や破壊的な操作の前に限り停止して質問してください。サブエージェントの成果を受け入れる前に、それぞれの根拠を確認し、確認できなかった事項には、どこを調べたかを添えてください。

タスク管理（必須）

ほかの作業を始める前に、進捗を追跡するタスクを作成してください。

# 1. Create main task IMMEDIATELY
TaskCreate(
  subject="Implement: {feature}",
  description="Feature implementation with parallel subagents",
  activeForm="Implementing {feature}"
)

# 2. Create subtasks for each phase
TaskCreate(subject="Research best practices and docs", activeForm="Researching best practices")  # id=2
TaskCreate(subject="Micro-plan: scope, files, criteria", activeForm="Micro-planning")            # id=3
TaskCreate(subject="Architecture design (parallel agents)", activeForm="Designing architecture") # id=4
TaskCreate(subject="Implement and write tests", activeForm="Implementing code")                  # id=5
TaskCreate(subject="Integration verification", activeForm="Verifying integration")               # id=6
TaskCreate(subject="Scope creep check", activeForm="Checking scope creep")                       # id=7
TaskCreate(subject="E2E verification", activeForm="Running E2E verification")                    # id=8
TaskCreate(subject="Document and reflect", activeForm="Documenting decisions")                   # id=9

# 3. Set dependencies for sequential phases
TaskUpdate(taskId="3", addBlockedBy=["2"])  # Plan needs research
TaskUpdate(taskId="4", addBlockedBy=["3"])  # Architecture needs plan
TaskUpdate(taskId="5", addBlockedBy=["4"])  # Implementation needs architecture
TaskUpdate(taskId="6", addBlockedBy=["5"])  # Integration needs implementation
TaskUpdate(taskId="7", addBlockedBy=["6"])  # Scope creep needs integration
TaskUpdate(taskId="8", addBlockedBy=["7"])  # E2E needs scope check
TaskUpdate(taskId="9", addBlockedBy=["8"])  # Docs need E2E

# 4. Update status as you progress
TaskUpdate(taskId="2", status="in_progress")  # When starting
TaskUpdate(taskId="2", status="completed")    # When done — repeat for each subtask

---

ワークフロー（10 フェーズ）

フェーズ	アクティビティ	エージェント
1. 調査	ベストプラクティス、Context7 のドキュメントを調査し、タスクに分割します	—
2. マイクロプランニング	タスクごとの詳細な計画（references/micro-planning-guide.md を読み込みます）	—
3. ワークツリー	5 ファイル以上の機能では、git ワークツリーで分離します（references/worktree-workflow.md を読み込みます）	—
4. アーキテクチャ	バックグラウンドで 4 つのエージェントを並列実行します（イベント／CQRS／キュー型の場合は event-driven-architect も追加します）	workflow-architect, backend-system-architect, frontend-ui-developer, llm-integrator
5. 実装 + テスト	並列エージェントを使い、必須テストを含むアーティファクトを一度のパスで作成します	backend-system-architect, frontend-ui-developer, llm-integrator, test-generator
6. 統合検証	コードレビュー + 実サービスとの統合テスト	backend, frontend, code-quality-reviewer, security-auditor
7. スコープクリープ	計画と実際の内容を比較します（references/scope-creep-detection.md を読み込みます）	workflow-architect
8. E2E 検証	ブラウザー + API の E2E テスト（references/e2e-verification.md を読み込みます）	—
9. ドキュメント	決定事項をメモリーグラフに保存します	—
10. 振り返り	得られた教訓、見積もりの精度	workflow-architect

エージェントのプロンプトを読み込みます：Read("references/agent-phases.md")

フェーズ 6 のパターンチェック。 このフォークでは、エンフォーサーを実行できません（Write/Edit #4683）。変更した各ファイルを node "${CLAUDE_PLUGIN_ROOT}/hooks/bin/run-hook.mjs" skill/pattern-consistency-enforcer に一度ずつパイプしてください。Read("references/phase-6-pattern-check.md") に手順が示されています。

Agent Teams モードの場合：Read("references/agent-teams-phases.md")

入れ子の委任（CC 2.1.172+）： フェーズ 4～6 の専門エージェントは、すべてをインラインで実行する代わりに、範囲を限定したサブ問題を自身が宣言したサブエージェントに委任するよう指示してもかまいません（例：backend-system-architect → スキーマ設計を database-engineer に委任）。チェーンは 3 階層以下に保ち、サブタスクが独立している場合は、このオーケストレーターから並列にディスパッチしてください。chain-patterns のパターン 9（CC 2.1.172+）を参照してください。

フェーズ間の引き継ぎ（CC 2.1.71）

主要なフェーズの後に引き継ぎ用 JSON を書き込みます。スキーマについては chain-patterns スキルを参照してください。

フェーズの後	引き継ぎファイル	主な出力
1. 調査	01-discovery.json	ベストプラクティス、ライブラリのドキュメント、タスクの分割
2. マイクロプラン	02-plan.json	ファイルマップ、タスクごとの受け入れ条件
4. アーキテクチャ	04-architecture.json	決定事項、採用したパターン、エージェントの結果
5. 実装	05-implementation.json	作成／変更したファイル、テスト結果
7. スコープクリープ	07-scope.json	計画と実際の内容、PR 分割の推奨事項

段階的な出力（CC 2.1.76+）

各フェーズの後に結果を段階的に出力します。最後までまとめて出力するのは避けてください。

フォーカスモード（CC 2.1.101）： フォーカスモード（/focus）では、ユーザーには最終メッセージのみが表示されます。重要な結果をすべて含む、単独で内容がわかる要約を記載してください。ユーザーが段階的な出力を見たと想定しないでください。

フェーズの後	ユーザーに表示する内容
1. 調査	主な調査結果、ライブラリの推奨事項、タスクの分割
4. アーキテクチャ	各エージェントの設計上の決定事項を、結果が返されるたびに表示
5. 実装	エージェントごとの作成／変更ファイル、テスト結果
7. スコープクリープ	計画と実際の差分、PR 分割の推奨事項

エージェントが run_in_background=true で実行される場合、各エージェントの調査結果は返され次第、すぐに出力してください。全エージェントの完了を待たないでください。これにより、ユーザーが体感するフィードバックを約 60% 速められ、エージェントの進め方が計画から逸れた場合に早期介入できます。

チームメイトのバックグラウンドタスクはターン終了後も継続します（CC 2.1.183）： チームメイトが開始した run_in_background タスクは、そのチームメイトのターンが終了しても終了されなくなりました。並列で動作するアーキテクチャ／テスト担当チームメイトは、長時間のビルドを開始し、自分のターン終了後も続行させることができます。リードは後から結果を受け取れます。2.1.183 より前は、バックグラウンドタスクを存続させるには、リードがすべてのタスクを所有する必要がありました。

バックグラウンドストリーミング用の Monitor ツール（CC 2.1.98）

出力ファイルをポーリングする代わりに、Monitor を使ってバックグラウンドのビルド／テストスクリプトからリアルタイムイベントをストリーミングします。

# Start a long-running build in background
Bash(command="npm run build 2>&1", run_in_background=true)
# Stream its output line-by-line as notifications (no polling)
Monitor(pid=build_task_id)

# For background agents with test suites:
Agent(subagent_type="ork:test-generator", run_in_background=true, isolation="worktree", ...)
# Monitor agent progress via task notifications (CC 2.1.98 partial progress)

パターンの完全なリファレンス（TaskOutput との使い分け、until 条件のゲート、部分的な結果の救出、アンチパターン）：Read("../chain-patterns/references/monitor-patterns.md")。

部分的な結果（CC 2.1.98）： worktree で分離されたエージェントが実装途中でクラッシュした場合、再生成するのではなく、部分的な出力を救出します。エージェントの worktree で git diff --name-only を実行し、利用できる変更をコミットして、未完了の項目にフラグを立てます。BLOCKED 状態のエージェントはユーザーにエスカレーションします。救出ロジックの全容については、上記の monitor-patterns リファレンスを参照してください。

Worktree で分離した実装

Agent(isolation="worktree") で並行実装エージェントを起動します。 worktree 分離ガードを回避するサブエージェントの問題は CC 2.1.154 で修正され、2.1.203 で完了しました。ork の最低バージョンは >= 2.1.220 なので、サポートされるすべてのセッションで実際に分離されます。パターンの全容と、ork の worktree 外 ../<repo>-<task> 規約に対して EnterWorktree が確認を求めるようになった 2.1.206 の注意事項については、Read("../chain-patterns/references/worktree-agent-pattern.md") を参照してください。

過去の情報（CC <= 2.1.153 のみ）： このパラメーターはプライマリ worktree の HEAD を繰り返し変更し、エージェントのツール使用を約 60 回で打ち切っていました（Yonatan-HQ/platform#3224）。これを解決した手動の事前作成による回避策は、現在は置き換えられており、記録としてのみ残されています：references/manual-worktree-pattern.md。

デプロイ後のモニタリング（CC 2.1.71）

最終 PR の後、ヘルスモニタリングをスケジュールします。

# Guard: Skip cron in headless/CI (CLAUDE_CODE_DISABLE_CRON)
# if env CLAUDE_CODE_DISABLE_CRON is set, run a single check instead
CronCreate(
  schedule="0 */6 * * *",
  prompt="Health check for {feature} in PR #{pr}:
    gh pr checks {pr} --repo {repo}.
    If healthy 24h → CronDelete. If errors → alert."
)

検出機能付き context7

if capabilities.context7:
  mcp__context7__resolve-library-id({ libraryName: "next-auth" })
  mcp__context7__query-docs({ libraryId: "...", query: "..." })
else:
  WebFetch("https://docs.example.com/api")  # T1 fallback

Issue の追跡

GitHub issue に取り組む場合は、issue-progress-tracking の Start Work セレモニーを実行し、主要なフェーズの後に進捗コメントを投稿します。

フィードバックループ

各タスクの後にチェックポイントを維持します。トリガーの読み込み：Read("references/feedback-loop.md")

---

テスト要件マトリックス

フェーズ 5 の test-generator は、変更の種類に合ったテストを必ず作成する必要があります。変更の種類ごとに、必要なテストとテストルールが定められています。

テストマトリックス、実サービスの検出、フェーズ 9 のゲートを読み込みます：Read("references/test-requirements-matrix.md")

---

主要な原則

• 検証ゲート（ターミナル、必須） — タスクを完了と宣言する前に、必ず Read("../../shared/rules/verification-gate.md") を読み込み、すべてのチェックを満たします。変更したファイルはすべて検証済みであること、テストがすべて成功していること、スコープクリープのスコアを付けていることが必要です。一部だけ合格しても完了ではありません。「これで動くはず」は証拠になりません。
• エージェントステータスプロトコル — すべてのサブエージェントは、Read("../../shared/status-protocol.md") に従って DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT を報告します。
• テストは必須です — 各タスクに、変更の種類に合ったテストを含めます（上記のマトリックスを参照）。
• 独立している場合は並行して実行 — run_in_background: true を使い、1 つのメッセージで全エージェントを起動します。
• 出力制限（CC 2.1.77+）： Opus ティアのデフォルト出力トークン数は 64k（上限 128k）です。可能であれば成果物全体を一度に生成します。出力が制限を超える場合は、ターンを分けて生成します。
• 実装前にマイクロプランを作成 — スコープの境界、ファイル一覧、受け入れ基準を定めます。
• スコープクリープを検出（フェーズ 7）— 0～10 でスコアを付け、重大な場合は PR を分割します。
• 利用可能な場合は実サービスを使う — docker-compose/testcontainers がある場合は、フェーズ 6 で使用します。
• 振り返り、教訓を記録（フェーズ 10）— メモリーグラフに保存します。
• エージェントをクリーンアップ — チームメイトはターン終了時に停止します（CC 2.1.178+ の暗黙的なチーム）。バックグラウンドに残っているエージェントを停止するには、Ctrl+F を 2 回押します。注：/clear（CC 2.1.72+）を実行しても、バックグラウンドエージェントは保持されます。
• worktree を終了 — ステップ 0 で worktree に入っていた場合は、フェーズ 10 で ExitWorktree(action: "keep") を呼び出します。孤立した worktree を残さないでください。

---

次のステップ（実装後にユーザーに提案）

verify {FEATURE}              # Grade the implementation
cover {FEATURE}               # Generate test suite
commit                        # Commit changes
/loop 10m npm test                 # Watch tests while iterating
/loop 30m verify {FEATURE}    # Periodic quality gate

完了時のプッシュ通知（CC 2.1.110+）

implement の実行は、並列エージェントを使うと通常 10～30 分かかります。最終的な統合ステップで、PR を作成し、テストがすべて成功した後に、PushNotification を呼び出してください。ユーザーはほぼ間違いなく、すでに別の作業に切り替えています。

PushNotification(
  message=f"ork:implement complete — {FEATURE}: {tests_passing}/{tests_total} tests · PR #{pr_num} opened · ready for verify",
  status="proactive"
)

通知を送るタイミング、本文の制限、Remote Control を利用できないユーザーへの適切なフォールバックに関する完全なルールは、Read("../chain-patterns/rules/push-notification-on-completion.md") を読み込んでください。

エージェントの連携

ディスパッチ時の設定（CC 2.1.142+ のフラグ — M146-6 / #1849）

サブエージェントをディスパッチするときは、セッション内の Agent ツールを使う場合も、ラッパースクリプトからヘッドレスの claude -p --bare を実行する場合も、インタラクティブ実行と CI 実行の間で動作を一貫させるため、エージェントの役割に応じて --permission-mode と --effort を明示的に設定してください。

エージェントの役割	--permission-mode	--effort	理由
読み取り専用の分析（Explore、code-quality-reviewer、debug-investigator）	dontAsk	low	書き込みがなく、リスクもありません。コストを最小限に抑えます。
テスト生成（test-generator）	acceptEdits	medium	テストファイルを書き込みます。権限の確認を求めると、並列処理が妨げられます。
本番コード（frontend-ui-developer、backend-system-architect）	default または acceptEdits	medium～high	機能の複雑さに応じて設定します。default にすると、ユーザーが関与し続けられます。
禁止	bypassPermissions	—	監査証跡を省略するため、一時的なサンドボックス内でのみ許容されます。

セッション内の Agent ツール呼び出しは、親セッションの権限モードを引き継ぎます。この表は、既定値に関する方針です。cron や CI など、真にヘッドレスな呼び出しでは、claude -p --bare にフラグを明示的に渡してください。

claude -p --bare \
  --permission-mode dontAsk \
  --effort low \
  --max-turns 8 \
  "<prompt>"

コンテキストの引き継ぎ

起動したすべてのエージェントに、変更したファイルの一覧、プロジェクトのティア、アーキテクチャ上の制約、前のフェーズ（調査、計画）で決定した内容を渡してください。「X を実装する」と伝えるだけでなく、エージェントのプロンプトに含めて渡します。

SendMessage（能動的な連携）

セッション間の返信は親セッションに届きます（CC 2.1.248）： サブエージェントが別のセッションに SendMessage を送ると、返信はサブエージェントではなく、親セッションの会話に届きます。サブエージェントはメッセージを送信したら作業を続け、親セッションが返信を確認します。セッション間の SendMessage / ListAgents は、テレメトリーが無効な場合でも、Bedrock、Vertex、Foundry で利用できます（CC 2.1.248）。

バックエンドエージェントとフロントエンドエージェントが API コントラクトを調整する必要がある場合：

SendMessage(to="frontend-ui-developer", message="API endpoint is POST /api/auth with {token, refreshToken} response shape")
SendMessage(to="test-generator", message="Backend uses JWT — mock auth middleware in test fixtures")

スキルチェーン

実装が完了したら、検証につなげます。

TaskCreate(subject="Verify implementation", activeForm="Verifying changes")
TaskUpdate(taskId=verify_id, addBlockedBy=[impl_task_id])
# Then: verify {feature}

品質基準

次のすべてを満たしたら完了です。

• 変更したすべてのファイルについて、ターミナル検証ゲートに従って検証済みであること。「動作するはず」で済ませないでください。
• フェーズ 5 の各タスクで、変更の種類に応じたテストを追加し、テストスイートが成功していること。結果の要約行を引用してください。
• フェーズ 7 でスコープクリープを 0～10 で評価し、差分が大きい場合は PR を分割すること。
• ステップ 0 で作成したワークツリーを ExitWorktree で終了し、孤立させないこと。

関連スキル

• ork:explore：実装前にコードベースを調査します
• ork:verify：実装が正しく動作することを検証します
• ork:issue-progress-tracking：コミットの進捗に合わせて GitHub のイシューを自動更新します

参照資料

Read("references/<file>") で必要に応じて読み込みます。

ファイル	内容
agent-phases.md	エージェントのプロンプトと起動テンプレート
agent-teams-phases.md	Agent Teams モードのフェーズ
interview-mode.md	面接／持ち帰り課題の制約
blast-radius-clarification.md	ステップ 0b：影響範囲を把握するための「方法の前に何をするか」を尋ねるインタビューと判断表
orchestration-modes.md	Agent ツールと Agent Teams の選択
feedback-loop.md	チェックポイントのトリガーとアクション
cc-enhancements.md	CC のバージョン固有の機能
agent-teams-full-stack.md	チーム向けのフルスタックパイプライン
team-worktree-setup.md	チームの worktree 設定
micro-planning-guide.md	詳細なマイクロプランニングガイド
scope-creep-detection.md	計画と実績の比較
worktree-workflow.md	Git worktree ワークフロー
e2e-verification.md	ブラウザー＋API の E2E テストガイド
worktree-isolation-mode.md	worktree の分離に関する詳細
tier-classification.md	ティア分類、ワークフローのマッピング、オーケストレーションモード
test-requirements-matrix.md	変更の種類ごとのテストマトリクス、実サービスの検出、フェーズ 9 のゲート