flow-develop

ホスト：Codex CLI — このスキルは Claude Code 向けに設計され、Codex 用に適応されています。 相互参照コマンドでは、/octo:* スラッシュコマンドではなく、Codex にインストールされたスキル名を使用します。 現在のセッションで利用可能であることが確認されるまでは、アクティブな Codex シェルとサブエージェントツールを使用してください。プロバイダー、モデル、ホストのサブエージェントが利用可能だと断言してはいけません。 ホストツールとの対応については、skills/blocks/codex-host-adapter.md を参照してください。

{{PREAMBLE}}

インストール済みプラグインから skills/blocks/engineering-method-selection.md を読み込み、 このタスクに関連する方法のみを適用してください。このエントリーポイントの 実行契約と出力形式を維持してください。参照先のスキルは指示として読み、 現在のコマンドを再帰的に呼び出したり、席からプロバイダー呼び出しを追加したりしないでください。

ポータブルな機能境界

実装前に、既存の機能を選択し、その境界アダプターを実行してください。

OCTO_ROOT="${CLAUDE_PLUGIN_ROOT:-${HOME}/.claude-octopus/plugin}"
bash "$OCTO_ROOT/scripts/helpers/feature-workflow.sh" boundary develop "${OCTOPUS_FEATURE:-}"

バインドされたプロジェクトポリシー、相対ソース、ダイジェストを読み取ってください。返されたマーカーバッチを、利用可能なネイティブのホスト質問ツールを使って一度だけ尋ねてください。スキップされた決定や非対話型の決定は未解決のままにしてください。未解決の件数を報告し、現在の契約が名前付きの未回答の決定に依存するタスクのみを保留してください。ランタイムは、実際にタスクをディスパッチする前にこれらのチェックを繰り返します。

2つ以上の仕様／計画／タスク成果物がある場合、決定論的な分析が自動的に行われます。問題のないパスでは、追加のモデル席は使用されません。未解決の指摘事項がある場合、ホストとランタイムで成果物のそのリビジョンに共有される、最大1つの独立した範囲限定の席が呼び出されることがあります。セマンティックレビューが利用できない、または失敗した場合は警告を出して続行します。分析ではソースからの正確な引用を報告し、成果物を書き換えることはありません。

利用可能な場合は、安定したタスク ID とメタデータを使用してください。親は各ウェーブでパス、依存関係、現在の Git 状態を解決します。ヒントによって並行処理が許可されたり、ユーザーの変更の上書きが認められたりすることはありません。レガシー入力では、既存のプランナーと実行パスを引き続き使用します。

開発前：状態チェック

開発を開始する前に：

1. .octo/STATE.md を読み、Define フェーズが完了していることを確認します
2. STATE.md を更新します：
   • current_phase: 3
   • phase_position: "Development"
   • status: "in_progress"

# Verify Define phase is complete
if [[ -f ".octo/STATE.md" ]]; then
  define_status=$("${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" get_phase_status 2)
  if [[ "$define_status" != "complete" ]]; then
    echo "⚠️ Warning: Define phase not marked complete. Consider running definition first."
  fi
fi

# Update state for Development phase
"${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" update_state \
  --phase 3 \
  --position "Development" \
  --status "in_progress"

⚠️ 実行契約（必須 - 省略不可）

このスキルでは強制実行モードを使用します。必ずこの正確な順序に従ってください。

ステップ 1：作業コンテキストの検出（必須）

ユーザーのプロンプトとプロジェクトを分析して、コンテキストを判断します。

ナレッジコンテキストの指標：

• 成果物を示す用語：「PRD」、「提案書」、「プレゼンテーション」、「レポート」、「戦略文書」、「ビジネスケース」
• ビジネス用語：「市場参入」、「競合分析」、「ステークホルダー」、「エグゼクティブサマリー」

開発コンテキストの指標：

• 技術用語：「API」、「エンドポイント」、「関数」、「モジュール」、「サービス」、「コンポーネント」
• アクション用語：「実装する」、「コードを書く」、「構築する」、「作成する」、「開発する」＋技術用語

あわせて確認：プロジェクトに package.json、Cargo.toml などがあるか（開発コンテキストを示唆します）。

context_type = "Dev" または "Knowledge" を記録します

ステップ 1b：開発のサブタイプを検出する（開発コンテキストの場合）

コンテキストタイプが開発の場合は、プロンプトにドメインに適した品質ガイダンスを追加するため、サブタイプを特定します。一致する補足テキストをユーザーのプロンプトの後に追加します。

サブタイプ	判定キーワード	品質補足
frontend-ui	"page", "widget", "component", "UI", "HTML", "CSS", "form", "dashboard", "layout"	frontend-ui の拡張を参照してください。
cli-tool	"CLI", "command-line", "terminal", "script", "flag", "argument"	--help フラグでヘルプテキストを表示します。意味のある終了コードを使用します（0 は成功、1 はユーザーエラー、2 はシステムエラー）。stdin/stdout/stderr を正しく使用します。引数を検証し、明確なエラーメッセージを表示します。
api-service	"API", "endpoint", "REST", "GraphQL", "gRPC", "server", "route"	境界で入力を検証します。一貫したエラーレスポンス形式を使用します。すべてのエンドポイントで認証と認可を行います。レート制限を検討します。OpenAPI／スキーマのドキュメントを用意します。
infra	"deploy", "terraform", "docker", "CI", "pipeline", "Kubernetes", "helm"	操作を冪等にします。シークレットをハードコードしません。ロールバック手順を文書化します。ヘルスチェックを含めます。
data	"ETL", "pipeline", "migration", "schema", "database", "SQL"	マイグレーションを冪等にします。バックアップ／ロールバック戦略を用意します。データ取り込み時にデータを検証します。
general	一致するサブタイプがない場合のデフォルト	補足はありません。基本の実装者ペルソナのみを使用します。

frontend-ui の拡張

サブタイプとして frontend-ui が検出された場合、次の 2 つを行います。

A. 品質補足をプロンプトに追加します。 自己完結型のファイルを優先します。アクセシビリティ：ARIA ラベル、キーボード操作、44px のタッチターゲット（WCAG 2.5.5）。安全な DOM：innerHTML より createElement を使用します。プログレッシブエンハンスメント：API（navigator.share、localStorage）の機能を検出し、フォールバックを用意します。ユーザー設定を localStorage に保存します。

B. 利用可能な場合は、BM25 からデザインインテリジェンスを取得します。

orchestrate.sh を呼び出す前に、デザインインテリジェンスエンジンが存在するかを確認し、関連するデザインコンテキストを取得します。

SEARCH_PY="${HOME}/.claude-octopus/plugin/vendors/ui-ux-pro-max-skill/src/ui-ux-pro-max/scripts/search.py"
if [[ -f "$SEARCH_PY" ]]; then
    # Detect relevant domains from the prompt
    design_context=""
    # Style query — what visual style fits this task?
    style_hit=$(python3 "$SEARCH_PY" "<user's task description>" --domain style --top 1 2>/dev/null || true)
    [[ -n "$style_hit" ]] && design_context+="Design style suggestion: $style_hit\n"
    # UX query — relevant UX patterns
    ux_hit=$(python3 "$SEARCH_PY" "<user's task description>" --domain ux --top 1 2>/dev/null || true)
    [[ -n "$ux_hit" ]] && design_context+="UX pattern: $ux_hit\n"
    # Append to prompt if hits found
    if [[ -n "$design_context" ]]; then
        # Append design intelligence to the orchestrate.sh prompt
        prompt="${prompt}\n\nDesign intelligence (from BM25 search):\n${design_context}"
    fi
fi

これにより、ユーザーが別途 /octo:design-ui-ux を実行しなくても、プロバイダーに具体的なデザインガイダンス（スタイルの方向性、UX パターン）を提供できます。検索エンジンがインストールされていない場合は、品質補足のみを使用して実装を進めます。

適用方法： ステップ 4 で orchestrate.sh を呼び出す際、品質補足（および利用可能な場合はデザインインテリジェンス）をプロンプトに追加します。

orchestrate.sh develop "<user prompt>\n\nQuality requirements for this deliverable:\n<supplement text>\n<design intelligence if found>"

コンテキストが確定するまでステップ 2 に進まないでください。 コンテキストタイプ（開発またはナレッジ）と開発のサブタイプによって、追加する品質補足とデザインインテリジェンスが決まります。コンテキストを誤ると、無関係な分析にプロバイダーのクレジットを浪費します。

ステップ 2：視覚的なインジケーターを表示する（必須・ブロッキング）

必須：バナーを表示する前に、ネイティブのシェルコマンドツールを使用してプロバイダーの確認を実行してください。省略してはいけません。利用可能だと決めつけてはいけません。

bash "${HOME}/.claude-octopus/plugin/scripts/helpers/check-providers.sh"

以下の実際の結果を使用してください。禁止事項：「🔵 Claude: Available ✓」のみを表示し、すべてのプロバイダーを列挙しないこと。

OCTO_ALLOWED_PROVIDERS が設定されている場合は、参加可能なプロバイダーを決定する信頼できる情報源として扱います。この許可リストによって除外されたプロバイダーは、意図的に利用不可として報告されています。ワークフロー内でそれらを呼び出したり、推奨したりしないでください。

orchestrate.sh の実行前に、このバナーを表示します。

開発コンテキストの場合：

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation mode
🛠️ [Dev] Develop Phase: [Brief description of what you're building]

Provider Availability:
🔴 Codex CLI: ${codex_status} - Code generation and patterns
🟡 Antigravity CLI: ${agy_status} - Alternative approaches
🧭 Antigravity CLI: ${agy_status} - Additional external-model challenge
🔵 Claude: Available ✓ - Integration and quality gates

💰 Estimated Cost: 0.02-0.10 USD
⏱️  Estimated Time: 3-7 minutes

ナレッジコンテキストの場合：

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation mode
🛠️ [Knowledge] Develop Phase: [Brief description of deliverable]

Provider Availability:
🔴 Codex CLI: ${codex_status} - Structure and framework application
🟡 Antigravity CLI: ${agy_status} - Content and narrative development
🧭 Antigravity CLI: ${agy_status} - Additional external-model challenge
🔵 Claude: Available ✓ - Integration and quality review

💰 Estimated Cost: 0.02-0.10 USD
⏱️  Estimated Time: 3-7 minutes

バナーを表示するまでステップ 3 に進まないでください。 バナーは、実行されるプロバイダーと発生する費用をユーザーに示します。この可視性を確保せずに API 呼び出しを開始することは、コストの透明性に反します。

STEP 3: 以前の状態を読み込む（必須 — 状態管理）

ワークフローを実行する前に、以前のコンテキストを読み込んでください：

# Initialize state if needed
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" init_state

# Set current workflow
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" set_current_workflow "flow-develop" "develop"

# Get prior decisions (critical for implementation)
prior_decisions=$("${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" get_decisions "all")

# Get context from discover and define phases
discover_context=$("${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" get_context "discover")
define_context=$("${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" get_context "define")

# Display what you found (if any)
if [[ "$discover_context" != "null" ]]; then
  echo "📋 Discovery phase findings:"
  echo "  $discover_context"
fi

if [[ "$define_context" != "null" ]]; then
  echo "📋 Definition phase scope:"
  echo "  $define_context"
fi

if [[ "$prior_decisions" != "[]" && "$prior_decisions" != "null" ]]; then
  echo "📋 Implementing with decisions:"
  echo "$prior_decisions" | jq -r '.[] | "  - \(.decision) (\(.phase)): \(.rationale)"'
fi

これにより、実装に不可欠なコンテキストを把握できます：

• 決定済みの技術スタックとパターン
• 定義済みの範囲と要件
• 実装に役立つ調査結果
• claude-mem がインストールされている場合は、その MCP ツール（search、timeline、get_observations）を利用できます。関連する過去の実装パターンを確認するために使用してください

状態を読み込むまで、STEP 4 に進まないでください。

STEP 4: orchestrate.sh develop を実行する（必須 — Bash ツールを使用）

このコマンドは、ネイティブのシェルコマンドツールを使って実行する必要があります：

${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh develop "<user's implementation request>"

重要：次の行為は禁止されています：

• ❌ orchestrate.sh を呼び出さずに直接実装すること — 単一モデルによる実装では、外部プロバイダーが独立した分析を通じて提示する代替案やエッジケースを見落とします
• ❌ 複数のプロバイダーの視点を取り入れずにコードを書くこと
• ❌ ワークフローを「シミュレート」していると主張すること
• ❌ このコマンドを実行せずに STEP 4 に進むこと

orchestrate.sh の呼び出しには、ネイティブのシェルコマンドツールを必ず使用してください。

実行中にユーザーに表示される内容（v7.16.0+）

Claude Code v2.1.16+ で実行している場合、タスクスピナーにリアルタイムの進行状況インジケーターが表示されます：

フェーズ 1 — 外部プロバイダーの実行（並列）：

• 🔴 コードとパターンを生成中（Codex）...
• 🟡 代替案を検討中（Antigravity）...

フェーズ 2 — 統合（順次）：

• 🔵 統合して品質ゲートを適用中...

これらのスピナーの動詞表示は自動的に更新されます。orchestrate.sh は、各エージェントの実行前に update_task_progress() を呼び出します。ユーザーは、どのプロバイダーが何をしているかを正確に確認できます。

**Claude Code v2.1.16+ で実行していない場合：**進行状況インジケーターはエラーを表示せずに省略されます。

STEP 5: 実行を検証する（必須 — 検証ゲート）

orchestrate.sh の完了後、正常に実行されたことを検証してください：

# Find the latest synthesis file (created within last 10 minutes)
SYNTHESIS_FILE=$(find ~/.claude-octopus/results -name "tangle-synthesis-*.md" -mmin -10 2>/dev/null | head -n1)

if [[ -z "$SYNTHESIS_FILE" ]]; then
  echo "❌ VALIDATION FAILED: No synthesis file found"
  echo "orchestrate.sh did not execute properly"
  exit 1
fi

echo "✅ VALIDATION PASSED: $SYNTHESIS_FILE"
cat "$SYNTHESIS_FILE"

検証に失敗した場合：

1. エラーをユーザーに報告する
2. ~/.claude-octopus/logs/ のログを表示する
3. 結果を提示せずに終了する
4. 直接実装で代替しない — 単一モデルによる実装にフォールバックすると、設計上の欠陥を早期に発見する複数プロバイダーの統合を省略してしまいます

STEP 6: 状態を更新する（必須 — 実行後）

統合結果を検証した後、実装の詳細を状態に記録してください：

# Extract key implementation decisions from synthesis
implementation_approach=$(head -50 "$SYNTHESIS_FILE" | grep -A 3 "## Implementation\|## Approach" | tail -3 | tr '\n' ' ')

# Record implementation decisions
decision_made=$(echo "$implementation_approach" | grep -o "implemented\|using [A-Za-z0-9 ]*\|chose to\|pattern:" | head -1)

if [[ -n "$decision_made" ]]; then
  "${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" write_decision \
    "develop" \
    "$decision_made" \
    "Multi-AI implementation consensus"
fi

# Update develop phase context
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" update_context \
  "develop" \
  "$implementation_approach"

# Update metrics
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" update_metrics "phases_completed" "1"

状態を更新するまで、STEP 7 に進まないでください。

STEP 7: 実装計画を提示する（STEP 1〜6 の完了後のみ）

統合ファイルを読み込み、次の内容を提示します：

• 推奨するアプローチ
• 実装手順
• 利用可能なすべての視点を反映したコードの概要
• 品質ゲートの結果
• 実装前にユーザーの確認を求める

ユーザーの確認後：Write/Edit ツールを使用してソリューションを実装します

クレジット表記を含めてください：

*Multi-AI Implementation powered by Claude Octopus*
*Providers: available external providers + 🔵 Claude*
*Full implementation plan: $SYNTHESIS_FILE*

開発ワークフロー — 開発フェーズ 🛠️

⚠️ 必須：コンテキストの検出と視覚的なインジケーター

ワークフローに関する操作を実行する前に、必ず次のことを行ってください：

Step 1: 作業コンテキストを検出する

ユーザーのプロンプトとプロジェクトを分析し、コンテキストを判断します：

ナレッジコンテキストの指標（プロンプト内）：

• 成果物に関する用語：「PRD」、「提案書」、「プレゼンテーション」、「レポート」、「戦略文書」、「ビジネスケース」
• ビジネスに関する用語：「市場参入」、「競合分析」、「ステークホルダー」、「エグゼクティブサマリー」

開発コンテキストの指標（プロンプト内）：

• 技術用語：「API」、「エンドポイント」、「関数」、「モジュール」、「サービス」、「コンポーネント」
• アクション用語：「実装」、「コード」、「構築」、「作成」、「開発」＋技術用語

次も確認してください：プロジェクトに package.json、Cargo.toml などがあるかどうか（開発コンテキストを示唆します）

Step 1b: 開発のサブタイプを検出する — サブタイプの表と品質補足については、上記の EXECUTION CONTRACT の Step 1b を参照してください。orchestrate.sh を呼び出す前に、該当する補足をプロンプトに追加します。

ステップ 2：コンテキストに応じたバナーを出力

開発コンテキストの場合：

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation mode
🛠️ [Dev] Develop Phase: [Brief description of what you're building]
📋 Session: ${CLAUDE_SESSION_ID}

Providers:
🔴 Codex CLI - Code generation and patterns
🟡 Antigravity CLI - Alternative approaches
🔵 Claude - Integration and quality gates

ナレッジコンテキストの場合：

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation mode
🛠️ [Knowledge] Develop Phase: [Brief description of deliverable]
📋 Session: ${CLAUDE_SESSION_ID}

Providers:
🔴 Codex CLI - Structure and framework application
🟡 Antigravity CLI - Content and narrative development
🔵 Claude - Integration and quality review

{{VISUAL_INDICATORS}}

ダブルダイヤモンドの一部：DEVELOP（発散的思考）

       DEVELOP (tangle)

        \         /
         \   *   /
          \ * * /
           \   /
            \ /

       Diverge with
        solutions

このワークフローで行うこと

develop フェーズでは、外部 CLI プロバイダーを使用して、複数の実装アプローチを生成します。

1. 🔴 Codex CLI - 実装を重視し、コード生成と技術パターンに対応
2. 🟡 Antigravity CLI - 代替アプローチ、エッジケース、ベストプラクティスに対応
3. 🔵 Claude（あなた） - 統合、改善、最終実装を担当

これはソリューションの発散フェーズです。最適なアプローチに収束する前に、さまざまな実装方法を検討します。

develop を使うタイミング

次のような場合に develop を使います。

開発コンテキストの例

• 機能の実装：「ユーザー認証システムを構築する」
• コード生成：「ユーザー登録用の API エンドポイントを作成する」
• 複雑な構築作業：「Redis を使用したキャッシュ層を実装する」
• アーキテクチャの実装：「決済処理用のマイクロサービスを作成する」
• 統合作業：「Stripe の決済処理を統合する」

ナレッジコンテキストの例

• PRD の作成：「モバイルのオンボーディング機能の PRD を作成する」
• 戦略文書：「APAC への市場参入戦略を作成する」
• ビジネスケース：「クラウドへの移行に関するビジネスケースを作成する」
• プレゼンテーション：「第 2 四半期の業績に関する経営陣向けプレゼンテーションを作成する」
• 調査レポート：「競合分析レポートを作成する」

次の用途には develop を使わないでください。

• 1 行で済む簡単なコード変更（Edit ツールを使ってください）
• バグ修正（デバッグスキルを使ってください）
• コードレビュー作業（deliver-workflow またはレビュー用スキルを使ってください）
• コードの読み取りや調査（Read ツールを使ってください）
• 簡単なドキュメントの編集（Write ツールを使ってください）

視覚的なインジケーター

実行前に、次の内容が表示されます。

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation
🛠️ Develop Phase: Building and developing solutions

Providers:
🔴 Codex CLI - Code generation and patterns
🟡 Antigravity CLI - Alternative approaches
🔵 Claude - Integration and refinement

仕組み

ステップ 1：Tangle フェーズを呼び出す

${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh develop "<user's implementation request>"

ステップ 2：複数のプロバイダーによる実装

orchestrate.sh スクリプトは次の処理を行います。

1. 実装タスクを指定して Codex CLI を呼び出します
2. 実装タスクを指定して Antigravity CLI を呼び出します
3. あなた（Claude）が実装分析に貢献します
4. アプローチを統合し、最適な方法を提案します

ステップ 3：品質ゲートを確認する

Tangle フェーズには、自動的な品質検証が含まれます。

• コード品質のチェック
• セキュリティスキャン
• ベストプラクティスの検証
• 実装の完全性の確認

ステップ 3b：エージェントの継続処理（v9.5 / CC v2.1.77 以降）

orchestrate.sh の出力に AGENT_TEAMS_RESUME:${agent_id}:${task_id}:${role}:${phase} が含まれている場合：

1. SendMessage({to: "${agent_id}", message: "<iteration prompt>"}) を使って既存のエージェントにメッセージを送信します。これにより、停止しているエージェントが自動的に再開されます（CC v2.1.77 以降）。
2. 再開指示の JSON（~/.claude-octopus/agent-teams/${task_id}.json）から、イテレーション用のプロンプトを読み取ります。
3. SendMessage がエラーを返した場合（エージェントが GC 済み、または見つからない場合）は、指示ファイルに記載された完全なプロンプトを使って新しいエージェントを作成します。
4. エージェントの応答後、ブリッジ台帳で次のように agentId を保存します：bridge_store_agent_id(task_id, agent_id)

注：CC v2.1.77 では Agent(resume: ...) パラメーターが削除されました。エージェントを継続させる場合は、必ず SendMessage を使ってください。

ステップ 4：結果を読む

結果の保存先：

~/.claude-octopus/results/${SESSION_ID}/tangle-synthesis-<timestamp>.md

ステップ 5：ソリューションを実装する

すべての視点を確認した後、Write/Edit ツールを使って最終的なソリューションを実装します。

実装手順

このスキルが呼び出されたら、上記の実行契約に厳密に従ってください。契約には次の内容が含まれます。

1. ブロッキングステップ 1：作業コンテキストを検出する（Dev または Knowledge）
2. ブロッキングステップ 2：プロバイダーを確認し、視覚的なインジケーターを表示する
3. ブロッキングステップ 3：ネイティブのシェルコマンドツールを使って orchestrate.sh develop を実行する
4. ブロッキングステップ 4：合成ファイルが存在することを確認する
5. ステップ 5：実装計画を提示し、ユーザーの確認を得る
6. 確認後：Write/Edit ツールを使ってソリューションを実装する

各ステップは必須かつブロッキングです。現在のステップが正常に完了するまで、次のステップに進むことはできません。

タスク管理との連携

実行の進捗を追跡するためにタスクを作成します。

// At start of skill execution
TaskCreate({
  subject: "Execute develop workflow with multi-AI providers",
  description: "Run orchestrate.sh develop for implementation",
  activeForm: "Running multi-AI develop workflow"
})

// Mark in_progress when calling orchestrate.sh
TaskUpdate({taskId: "...", status: "in_progress"})

// Mark completed ONLY after implementation finished
TaskUpdate({taskId: "...", status: "completed"})

エラー処理

いずれかのステップが失敗した場合：

• ステップ 1（コンテキスト）：曖昧な場合は Dev Context をデフォルトにします
• ステップ 2（プロバイダー）：外部プロバイダーがすべて利用できない場合は、/octo:setup を提案して停止します
• ステップ 3（orchestrate.sh）：bash エラーを表示し、ログを確認して、ユーザーに報告します
• ステップ 4（検証）：合成ファイルが見つからない場合は、orchestrate.sh のログを表示します。直接実装で代替してはいけません

orchestrate.sh の実行が失敗した場合、直接実装に切り替えてはいけません。失敗を報告し、以降の対応はユーザーに委ねてください。

実装計画の形式

正常に実行できたら、次の内容を含む実装計画を提示します。

# Implementation Plan: <task>

## Recommended Approach
[Your strategic recommendation based on all perspectives]

## Implementation Steps
1. [Step-by-step implementation plan]
2. ...

## Code Overview

### Codex Approach
[Key implementation details from Codex]

### Antigravity Approach
[Alternative considerations from Antigravity]

### Final Implementation
[Your integrated solution]

## Quality Gates
- [ ] Security validation: PASSED/FAILED
- [ ] Best practices: PASSED/FAILED
- [ ] Code quality: PASSED/FAILED

Would you like me to proceed with implementation?

6. ソリューションを実装する ユーザーの確認後、Write/Edit ツールを使って実装を作成します。
   • 必要なファイルを作成する
   • 合成されたアプローチに基づいてコードを記述する
   • 該当する場合はテストを追加する
   • 実装内容を文書化する

使用例

例 1：認証システムを構築する

User: Build a user authentication system with JWT

Claude:
🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation mode
🛠️ Develop Phase: Building authentication system

[Executes: ${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh develop "Build a user authentication system with JWT"]

[After completion, reads synthesis and presents:]

# Implementation Plan: User Authentication System

## Recommended Approach

Based on multi-provider analysis, I recommend a layered approach:
1. Auth middleware for JWT validation
2. Login/register endpoints
3. Token refresh mechanism
4. Secure password hashing (bcrypt)

## Implementation Steps

1. Create `src/auth/middleware.ts` - JWT validation middleware
2. Create `src/auth/controller.ts` - Login/register endpoints
3. Create `src/auth/service.ts` - Business logic
4. Create `src/auth/utils.ts` - Token generation/validation
5. Update `src/routes.ts` - Register auth routes

## Code Overview

### Codex Approach
- Modern TypeScript with strict types
- Express middleware pattern
- Redis for token blacklisting
- Comprehensive error handling

### Antigravity Approach
- Passport.js integration suggestion
- Rate limiting on auth endpoints
- Multi-factor auth consideration
- Session management alternatives

### Final Implementation
- Hybrid: Modern TypeScript + Express patterns
- JWT with refresh tokens
- bcrypt password hashing
- Rate limiting included
- Optional MFA hooks for future

## Quality Gates
- ✅ Security validation: PASSED (bcrypt, secure tokens)
- ✅ Best practices: PASSED (TypeScript, error handling)
- ⚠️  Code quality: WARNING (consider adding request validation)

Would you like me to proceed with implementation?

[User: Yes, proceed]

[Claude creates files and implements the solution]

例 2：API エンドポイントを作成する

User: Create an API endpoint for fetching user notifications

Claude:
🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation mode
🛠️ Develop Phase: Creating API endpoint

[Executes tangle workflow]

[Presents implementation plan with multi-provider perspectives]
[Implements the endpoint after user confirmation]

品質ゲートとの連携

tangle フェーズでは、.claude/hooks/quality-gate.sh を通じて品質チェックが自動的に実行されます。

# Triggered after tangle execution (PostToolUse hook)
./hooks/quality-gate.sh

{{QUALITY_GATES}}

他のワークフローとの連携

Tangle は Double Diamond の第 3 フェーズです。

PROBE (Discover) → GRASP (Define) → TANGLE (Develop) → INK (Deliver)

tangle の完了後、次に進むことができます。

• Ink：実装を検証して納品する

または、実装タスクに単独で使用することもできます。

実装前チェックリスト

コードを書く前に、次の点を確認してください。

• すべてのプロバイダーから実装アプローチの回答が得られている
• 品質ゲートで評価済みである（セキュリティ、ベストプラクティス、コード品質）
• ユーザーが実装計画を確認している
• ファイル構成とアーキテクチャが明確である
• 依存関係が特定され、利用可能である
• テストが計画されている（該当する場合）

実装後：コードレビューと E2E 検証の自動実行（必須）

実装の完了後、結果をユーザーに提示する前に、2 つの検証エージェントを並行して起動する必要があります。 この手順を省略したり、実行するかどうかをユーザーに尋ねたりしてはいけません。これは自動的に行います。

2 つのエージェントを同時に起動します。

エージェント 1 — コードレビュー（Sonnet）：

Agent(
  model: "sonnet",
  subagent_type: "feature-dev:code-reviewer",
  background execution: true,
  description: "Code review: post-develop",
  prompt: "Review the code changes from this development session. Focus on:
1. Bugs, logic errors, security vulnerabilities
2. Hidden dependencies or coupling issues
3. Whether error handling covers failure modes
4. Adherence to project conventions (check CLAUDE.md)

Check git diff for the changed files. Report only high-confidence issues."
)

エージェント 2 — E2E 検証（Sonnet）：

Agent(
  model: "sonnet",
  background execution: true,
  description: "E2E test: post-develop",
  prompt: "Run end-to-end verification of the development changes:
1. Run the project's test suite (detect from package.json scripts, Makefile, or pyproject.toml)
2. Verify no regressions in existing tests
3. Check that new files are properly integrated (imported, registered, sourced)
4. Verify the implementation matches the original task requirements

Report: tests passed/failed, any integration issues found."
)

両方のエージェントの完了後：

• 結果の一部として、調査結果をユーザーに提示します
• コードレビュー担当が信頼度の高い問題を見つけた場合は、目立つように示します
• テストに失敗した場合は、「次にすることは？」のプロンプトを表示する前に明示します
• レビューをブロッキングにせず、結果と併せて調査結果を提示します

理由：開発作業後にユーザーが手動でコードレビューを依頼する必要がなくなります。別のモデル（実装担当の Opus に対して Sonnet）による新鮮な視点でのレビューにより、実装者が見落としがちな問題を発見できます。テストを自動実行することで、ユーザーが問題に気づく前にリグレッションを検出できます。

実装後のチェックリスト

コードを書いた後、以下を確認してください。

• すべてのファイルを作成／更新した
• コードが統合結果で推奨されているパターンに従っている
• コードがプロジェクト既存のコメント規約に従っている（依頼された場合、またはプロジェクトのスタイル上必要な場合を除き、コメントを追加しないでください）
• セキュリティ上の懸念に対処した
• エラー処理を実装した
• テストを作成した（該当する場合）
• lint／型チェックのコマンドを実行した（package.json、pyproject.toml、Cargo.toml、Makefile から検出してください。見つからない場合はユーザーに確認してください）
• lint／テストのコマンドが見つかり、CLAUDE.md に記載されていない場合は、追加を提案した
• 自動コードレビューを完了した（Sonnet エージェント）
• E2E 検証を完了した（Sonnet エージェント）
• レビュー結果を添えて、完了をユーザーに通知した
• 検証のために ink-workflow の実行を提案した

コストへの配慮

外部 API の利用：

• 🔴 Codex CLI は OPENAI_API_KEY を使用します（費用が発生します）
• 🟡 Antigravity CLI は AGY_AUTH_TOKEN を使用します（費用が発生します）
• 🔵 Claude Code には Claude による分析が含まれます

Tangle ワークフローの費用は、複雑さとコードの長さに応じて、通常 1 タスクあたり 0.02～0.10 USD です。

開発後：チェックポイント

開発完了後：

1. skill-verification-gate を通じて、変更した動作を対象とする新しいテストを実行してください。失敗した場合は停止してください。
2. チェックポイントを作成してください：git tag octo-checkpoint-post-develop-$(date +%Y%m%d-%H%M%S)
3. .octo/STATE.md を更新して完了を記録し、変更したファイルを含む履歴エントリーを追加してください。

# Enter this block only after fresh targeted tests pass.
checkpoint_tag="octo-checkpoint-post-develop-$(date +%Y%m%d-%H%M%S)"
git tag "$checkpoint_tag" -m "Post-develop checkpoint from embrace workflow"
echo "📌 Created checkpoint: $checkpoint_tag"

# Update state only after verification and checkpoint creation succeed.
"${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" update_state \
  --status "complete" \
  --history "Develop phase completed"

# Record files modified in this phase
modified_files=$(git diff --name-only HEAD~1 2>/dev/null || echo "See git log")
"${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" update_state \
  --history "Files modified: $modified_files"

ターミナル状態

Develop フェーズが完了するのは、実装が存在し、開発後のチェックポイントタグが作成され、対象のテストを新たに実行して合格した場合に限ります（skill-verification-gate を参照）。 その後、検証のために flow-deliver を呼び出してください。ここで作業完了を宣言しないでください。完了の報告は、レビュー後の Deliver フェーズで行います。

ビルドを始める準備ができました！ このスキルは、ユーザーが実装または機能の構築を依頼した際に、明示的な呼び出しの後で使用します。