flow-define

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

{{PREAMBLE}}

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

共通定義

該当する場合は、プロジェクト既存の用語集と決定事項を読み込んでください。存在しない場合は、 skills/blocks/domain-modeling.mdを使用し、現在の設計成果物に短い定義セクションを 追加してください。別個のコンテキストファイルやメモリファイルを作成しないでください。 インストール、認証、利用資格、準備状況、課金、クォータ、シート、 コントリビューション、投票をそれぞれ区別してください。

定義前：状態の確認

定義を開始する前に：

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

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

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

実行契約

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

STEP 1：視覚的なインジケーターを表示する

必須：バナーを表示する前に、ネイティブのシェルコマンドツールを使って、このプロバイダーチェックを実行してください。省略したり、利用可能だと決めつけたりしないでください。

provider_check_output=$(bash "${HOME}/.claude-octopus/plugin/scripts/helpers/check-providers.sh")
provider_status_lines=$(printf '%s\n' "$provider_check_output" | awk '
  /^PROVIDER_CHECK_START$/ { capture=1; next }
  /^PROVIDER_CHECK_END$/ { capture=0 }
  capture && /^[a-z0-9-]+:(available|missing|degraded)$/ { print }
')

if [[ -z "$provider_status_lines" ]]; then
  echo "Provider availability check returned no usable status lines."
  exit 1
fi

# Exclude providers intentionally disabled by environment, session, or global
# allowlist policy; show every allowed provider, including missing/degraded.
source "${HOME}/.claude-octopus/plugin/scripts/lib/provider-allowlist.sh"
provider_availability=""
available_provider_count=0
while IFS=: read -r provider status; do
  octo_provider_allowed "$provider" || continue
  case "$status" in
    available)
      provider_availability="${provider_availability}🟢 ${provider}: Available ✓"$'\n'
      available_provider_count=$((available_provider_count + 1))
      ;;
    degraded)
      provider_availability="${provider_availability}🟠 ${provider}: Degraded ⚠"$'\n'
      ;;
    missing)
      provider_availability="${provider_availability}🔴 ${provider}: Missing/unavailable ✗"$'\n'
      ;;
  esac
done <<< "$provider_status_lines"

if [[ "$available_provider_count" -eq 0 ]]; then
  printf '%s' "$provider_availability"
  echo "No external provider is available. Run /octo:setup and retry."
  exit 1
fi

# Task status for the banner's Tasks line, if the session has one.
task_status=$("${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh" get-task-status 2>/dev/null || echo "")

Claudeだけでなく、チェックで報告されたすべてのプロバイダーを一覧表示してください。複数のシートが稼働したのに、バナーに1つしか表示されないと、ユーザーが支払っている対象を誤って伝えることになります。

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

orchestrate.shの実行前に、必ずこのバナーを表示してください：

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider definition mode
🎯 Define Phase: [Brief description of what you're defining/scoping]
📋 Session: ${CLAUDE_SESSION_ID}
📝 Tasks: ${task_status}

Provider Availability:
${provider_availability}
🔵 Claude: Available ✓ - Consensus building and synthesis

💰 Estimated Cost: 0.01-0.05 USD
⏱️  Estimated Time: 2-5 minutes

バナーを表示するまでSTEP 2に進まないでください。 バナーは、どのプロバイダーが稼働し、どのような費用が発生するかをユーザーに示します。この可視性を確保せずにAPI呼び出しを開始すると、コストの透明性が損なわれます。

STEP 2：以前の状態を読み込む

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

# 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-define" "define"

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

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

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

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

これにより、次のコンテキストが得られます：

• Discoveryフェーズの調査（完了している場合）
• 以前のアーキテクチャ上の決定
• 以前に把握したユーザーのビジョン
• claude-memがインストールされている場合、そのMCPツール（search、timeline、get_observations）を利用できます。類似トピックに関する過去の決定を探すために使用してください

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

STEP 3：フェーズのディスカッション — ユーザーのビジョンを把握する

費用のかかる複数AIのオーケストレーションを実行する前に、作業範囲を適切に定められるようユーザーのビジョンを把握してください。

AskUserQuestionを使って、明確化のための質問をしてください：

Use AskUserQuestion tool to ask:

1. **User Experience**
   Question: "How should users interact with this feature?"
   Header: "User Flow"
   Options:
   - label: "API-first (programmatic access)"
     description: "Build API endpoints first, UI later"
   - label: "UI-first (user-facing interface)"
     description: "Build user interface first, API supports it"
   - label: "Both simultaneously"
     description: "Develop API and UI in parallel"
   - label: "Not applicable"
     description: "This feature doesn't have a user interaction"

2. **Implementation Approach**
   Question: "What technical approach do you prefer?"
   Header: "Approach"
   Options:
   - label: "Fastest to market"
     description: "Prioritize speed, use existing libraries"
   - label: "Most maintainable"
     description: "Focus on clean architecture, may take longer"
   - label: "Best performance"
     description: "Optimize for speed and efficiency"
   - label: "Multi-LLM debate (Claude + available providers)"
     description: "Multiple AI models debate the best approach — may use external provider credits or subscriptions"

3. **Scope Boundaries**
   Question: "What's explicitly OUT of scope for this phase?"
   Header: "Out of Scope"
   Options:
   - label: "Testing and QA"
     description: "Focus on implementation, test later"
   - label: "Performance optimization"
     description: "Get it working first, optimize later"
   - label: "Edge cases"
     description: "Handle happy path only initially"
   - label: "Nothing excluded"
     description: "Everything is in scope"
   multiSelect: true

ユーザーがアプローチとして「Multi-LLM debate (Claude + available providers)」を選択した場合： orchestrate.shを実行する前に、技術的なアプローチを決定するため、Multi-LLM debateを実行してください：

/octo:debate --rounds 2 --debate-style collaborative "What is the best technical approach for [feature]? Consider: speed to market, maintainability, performance, and the existing codebase patterns."

議論の統合結果を使用して、Defineフェーズのアプローチコンテキストを設定してください。

回答を集めた後、コンテキストファイルを作成してください：

# Source context manager
source "${HOME}/.claude-octopus/plugin/scripts/context-manager.sh"

# Extract user answers from AskUserQuestion results
user_flow="[Answer from question 1]"
approach="[Answer from question 2]"
out_of_scope="[Answer from question 3]"

# Create context file with user vision
create_templated_context \
  "define" \
  "$(echo "$USER_REQUEST" | head -c 50)..." \
  "User wants: $user_flow approach with $approach priority" \
  "$approach" \
  "Implementation of requested feature" \
  "$out_of_scope"

echo "📋 Context captured and saved to .claude-octopus/context/define-context.md"

このコンテキストは次の用途に使用します：

• 複数AIによる調査（Discoverフェーズ）の範囲を定める
• 要件定義（Defineフェーズ）の焦点を絞る
• 実装の決定（Developフェーズ）の指針とする
• ユーザーの期待に照らして検証する（Deliverフェーズ）

コンテキストを記録するまでSTEP 4に進まないでください。 ユーザーのビジョン（UXのアプローチ、優先事項、対象外項目）によって複数AIによる調査の範囲が決まります。これがないと、プロバイダーの調査範囲が広がりすぎ、定義がユーザーの実際の意図を見落とします。

ステップ 4：orchestrate.sh define を実行する

このコマンドは、ネイティブのシェルコマンドツールを使って必ず実行してください：

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

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

• ❌ orchestrate.sh を呼び出さずに要件を直接定義すること。単一モデルによる分析では、プロバイダーのファンアウトによって得られる技術、ビジネス、外部モデルの視点の分担が欠けるため、要件に見落としが生じます
• ❌ orchestrate.sh の代わりに直接分析を行うこと
• ❌ ワークフローを「シミュレート」していると主張すること
• ❌ このコマンドを実行せずにステップ 5 に進むこと

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

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

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

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

• 🔴 技術要件を分析中（Codex）...
• 🟡 ユーザーニーズとコンテキストを明確化中（Antigravity）...

フェーズ 2 - 統合（逐次）：

• 🔵 問題定義の合意を形成中...

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

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

ステップ 5：実行を検証する

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

# Find the latest synthesis file (created within last 10 minutes)
SYNTHESIS_FILE=$(find ~/.claude-octopus/results -name "grasp-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. 直接分析で代替しないでください。単一モデル分析にフォールバックすると、複数プロバイダーによる合意形成の目的が損なわれ、要件が狭いものになります

ステップ 6：状態を更新する

統合結果を検証した後、調査結果と決定事項を状態に記録してください：

# Extract key definition from synthesis
key_definition=$(head -50 "$SYNTHESIS_FILE" | grep -A 3 "## Problem Definition\|## Summary" | tail -3 | tr '\n' ' ')

# Record any architectural decisions made
# (You should identify these from the synthesis - e.g., tech stack, approach, patterns)
decision_made=$(echo "$key_definition" | grep -o "decided to\|chose to\|selected\|using [A-Za-z0-9 ]*" | head -1)

if [[ -n "$decision_made" ]]; then
  "${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" write_decision \
    "define" \
    "$decision_made" \
    "Consensus from multi-AI definition phase"
fi

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

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

状態が更新されるまで、ステップ 7 に進まないでください。

ステップ 7：問題定義を提示する（ステップ 1～6 の完了後のみ）

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

• 中核となる要件（必須、あるべき、あると望ましい）
• 技術的制約
• ユーザーニーズ
• 対応すべきエッジケース
• 対象範囲外の項目
• すべてのプロバイダーの視点
• 要件チェックリスト
• 次のステップ（通常は実装のための tangle フェーズ）

出典を明記してください：

*Multi-AI Problem Definition powered by Claude Octopus*
*Providers: available external providers + 🔵 Claude*
*Full problem definition: $SYNTHESIS_FILE*

Define ワークフロー - Define フェーズ 🎯

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

define フェーズでは、外部 CLI プロバイダーを使用して問題を明確化し、範囲を定めます：

1. 🔴 Codex CLI - 技術要件の分析、エッジケース、制約
2. 🟡 Antigravity CLI - ユーザーニーズ、ビジネス要件、コンテキストの理解
3. 🧭 Antigravity CLI - 外部モデルによる追加の検証
4. 🔵 Claude（あなた） - 問題の統合と要件定義

これは、広範な調査から具体的な問題定義へと絞り込む、discovery 後の収束フェーズです。

Define を使用するタイミング

次のような場合に define を使用します：

• 要件定義：「認証システムが何を行う必要があるのかを正確に定義する」
• 問題の明確化：「キャッシュ要件を明確にする」
• 範囲の定義：「通知機能の範囲はどこまでか？」
• 制約の特定：「X の技術的制約は何か？」
• エッジケースの分析：「Y について対応が必要なエッジケースは何か？」
• 要件の検証：「Z の要件はすべて網羅されているか？」

次の用途には define を使用しないでください：

• 調査や探索（probe-workflow を使用）
• 実装の構築（tangle-workflow を使用）
• コードレビューと検証（ink-workflow を使用）
• Claude が回答できる単純な質問

視覚的インジケーター

実行前に、次の形式のバナーが表示されます。以下のプロバイダー行は例示です。ステップ 1 のすべてのライブステータスに置き換え、アクティブな許可リストから除外されたプロバイダーのみ省略してください：

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider problem definition
🎯 Define Phase: Clarifying requirements and scope
📋 Session: ${CLAUDE_SESSION_ID}
📝 Tasks: ${task_status}

Provider Availability:
🟢 codex: Available ✓
🧭 agy: Degraded ⚠
🔴 agy: Missing/unavailable ✗
🔵 Claude: Available ✓ - Consensus building and synthesis

動作の仕組み

ステージ A：Grasp フェーズを呼び出す

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

Stage B: 複数プロバイダーによる問題定義

orchestrate.sh スクリプトは、以下を実行します。

1. 技術要件の分析に Codex CLI を呼び出します
2. ビジネス／ユーザーニーズの分析に Antigravity CLI を呼び出します
3. 外部モデルによる追加の検証に Antigravity CLI を呼び出します
4. あなた（Claude）が統合し、明確な問題定義にまとめます
5. 不足している点と要件を特定します

Stage C: 結果を読む

結果は次の場所に保存されます。

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

Stage D: 問題定義を提示する

統合結果を読み、明確で実行可能な要件をユーザーに提示します。

実装手順

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

1. ブロッキングステップ 1：プロバイダーを確認し、リアルタイムの視覚的なインジケーターを表示する
2. ブロッキングステップ 2：以前のワークフロー状態を読み込む
3. ブロッキングステップ 3：ユーザーのビジョンを記録し、永続化する
4. ブロッキングステップ 4：ネイティブのシェルコマンドツールを使って orchestrate.sh define を実行する
5. ブロッキングステップ 5：統合ファイルが存在することを確認する
6. ブロッキングステップ 6：ワークフロー状態を更新する
7. ステップ 7：整形した問題定義を提示する

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

タスク管理との連携

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

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

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

// Mark completed ONLY after synthesis file verified
TaskUpdate({taskId: "...", status: "completed"})

エラー処理

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

• ステップ 1（プロバイダー）：外部プロバイダーがすべて利用できない場合は、/octo:setup を提案して停止します
• ステップ 4（orchestrate.sh）：bash のエラーを表示し、ログを確認して、ユーザーに報告します
• ステップ 5（検証）：統合結果がない場合は、orchestrate.sh のログを表示し、直接分析で代用しないでください

orchestrate.sh の実行に失敗した場合、直接分析に切り替えてはいけません。失敗を報告し、ユーザーが次の対応を判断できるようにしてください。

問題定義の形式

正常に実行された後、次の形式で問題定義を提示します。

# Problem Definition: <task>

## Core Requirements
[Essential requirements that must be met]

## Technical Constraints
[Technical limitations and considerations]

## User Needs
[What users actually need from this]

## Edge Cases to Handle
[Specific edge cases identified]

## Out of Scope
[What is explicitly NOT included]

## Perspectives

### Codex Analysis (Technical)
[Technical requirements and constraints]

### Antigravity Analysis (Business/User)
[User needs and business context]

### Claude Synthesis
[Integrated problem definition]

## Requirements Checklist
- [ ] Functional requirements defined
- [ ] Non-functional requirements defined
- [ ] Technical constraints identified
- [ ] Edge cases documented
- [ ] Out-of-scope items clarified
- [ ] Success criteria established

## Next Steps
[Recommended next actions - usually tangle phase for implementation]

Full problem definition saved to: <synthesis file path>

使用例

例 1：認証要件を定義する

User: Define the exact requirements for our user authentication system

Claude:
🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider problem definition
🎯 Define Phase: Clarifying authentication requirements

[Executes: ${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh define "Define exact requirements for user authentication system"]

[After completion, reads synthesis and presents:]

# Problem Definition: User Authentication System

## Core Requirements

### Must Have (P0)
1. User registration with email + password
2. Secure login with JWT token generation
3. Password reset via email
4. Session management with token refresh
5. Logout (token invalidation)

### Should Have (P1)
6. Remember me functionality
7. Account lockout after failed attempts
8. Email verification on signup
9. Password strength requirements

### Nice to Have (P2)
10. OAuth social login (Google, GitHub)
11. Two-factor authentication
12. Single sign-on (SSO)

## Technical Constraints

- Must work with existing Express.js backend
- Token storage: Redis for production, in-memory for dev
- Password hashing: bcrypt (min 12 rounds)
- Token expiry: Access token 15min, refresh token 7 days
- Rate limiting: Max 5 login attempts per 15min per IP

## User Needs

- Simple registration process (< 2 minutes)
- Secure password recovery without support tickets
- Stay logged in across browser sessions (remember me)
- Clear error messages for failed login
- Ability to log out from all devices

## Edge Cases to Handle

1. **Concurrent logins**: Same user, multiple devices
2. **Expired tokens**: Graceful refresh without re-login
3. **Password reset race condition**: Multiple reset requests
4. **Account enumeration**: Don't reveal if email exists
5. **Token theft**: Detect suspicious login locations
6. **Deleted users**: Handle auth for soft-deleted accounts

## Out of Scope

- ❌ Biometric authentication (fingerprint, face ID)
- ❌ LDAP/Active Directory integration
- ❌ Custom OAuth provider implementation
- ❌ Device fingerprinting
- ❌ Passwordless email magic links

## Perspectives

### Codex Analysis (Technical)
- JWT structure: { userId, role, exp, iat, jti }
- Database schema for users, refresh_tokens, password_resets
- API endpoints: POST /register, POST /login, POST /logout, POST /refresh, POST /reset-password
- Middleware for auth verification
- Security: HTTPS only, secure cookies, CSRF protection

### Antigravity Analysis (Business/User)
- User journey: Registration -> Email verification -> Login -> Access app
- Error handling: Clear messages without security leaks
- Performance: Auth checks < 50ms
- Compliance: GDPR (data deletion), password policies
- Analytics: Track signup conversion, failed login rates

### Claude Synthesis
- Hybrid approach: Core auth (P0) first, iterate on P1/P2
- Security-first: All requirements validated against OWASP
- User experience: Balance security with convenience
- Scalable: Design for 100K users, plan for 1M+

## Requirements Checklist
- ✅ Functional requirements defined (registration, login, reset)
- ✅ Non-functional requirements defined (performance, security)
- ✅ Technical constraints identified (Express, Redis, bcrypt)
- ✅ Edge cases documented (6 critical cases)
- ✅ Out-of-scope items clarified (4 items)
- ✅ Success criteria established (< 2min registration, < 50ms auth)

## Next Steps

1. **Immediate**: Review and confirm requirements with stakeholders
2. **Then**: Use **tangle-workflow** to implement the auth system
3. **Finally**: Use **ink-workflow** to validate implementation

Ready to proceed to implementation?

Full problem definition saved to: ~/.claude-octopus/results/abc-123/grasp-synthesis-20250118-144530.md

例 2：機能の範囲を明確にする

User: What exactly does the notification feature need to do?

Claude:
🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider problem definition
🎯 Define Phase: Clarifying notification requirements

[Executes grasp workflow]

[Presents detailed problem definition with:]
- Core notification types (email, push, in-app)
- Delivery requirements (real-time vs batched)
- User preferences (opt-in/out, frequency)
- Technical constraints (message queue, delivery tracking)
- Edge cases (offline users, rate limits)

Ready to build once requirements are confirmed.

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

Grasp はダブルダイヤモンドの第 2 フェーズです。

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

一般的な流れ：

1. Probe：「認証のベストプラクティスを調査する」（選択肢を見つける）
2. Grasp：「認証システムの具体的な要件を定義する」（範囲を絞り込む）
3. Tangle：「認証システムを実装する」（構築する）
4. Ink：「認証の実装を検証する」（成果物を完成させる）

要件が不明確な場合は、grasp を単独で使用することもできます。

品質チェックリスト

grasp ワークフローを完了する前に、次の点を確認します。

• 中核となる要件（必須、あるとよい、あれば望ましい）が明確に定義されている
• 技術的な制約が文書化されている
• ユーザーニーズが理解され、明確に表現されている
• エッジケースが特定され、文書化されている
• 対象外の項目が明示的に列挙されている
• 成功基準が定められている
• 次のステップがユーザーに提案されている
• 問題定義全体が共有されている

コストに関する注意

外部 API の利用：

• 🔴 Codex CLI は OPENAI_API_KEY を使用します（費用が発生します）
• 🟡 Antigravity CLI は AGY_AUTH_TOKEN を使用します（費用が発生します）
• 🧭 Antigravity CLI は Antigravity アカウント／モデル設定を使用します（費用が発生する場合があります）
• 🔵 Claude の分析は Claude Code に含まれています

grasp ワークフローの費用は、複雑さに応じて通常、タスクあたり 0.01～0.05 USD です。

定義後：状態の更新

定義が完了したら：

1. .octo/STATE.md を更新して完了を記録します
2. .octo/ROADMAP.md に定義したフェーズと成功基準を記入します

# Update state after Definition completion
"${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" update_state \
  --status "complete" \
  --history "Define phase completed"

# Populate ROADMAP.md with defined requirements
if [[ -f "$SYNTHESIS_FILE" ]]; then
  echo "📝 Updating .octo/ROADMAP.md with defined phases..."
  "${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" update_roadmap \
    --from-synthesis "$SYNTHESIS_FILE"
fi

最終状態

要件が統合され、ユーザーが範囲を承認した場合にのみ、Define フェーズは完了です。承認後、実装が依頼されている場合は flow-develop を呼び出します。 そうでない場合は、要件ドキュメントを提示して終了します。承認済みの範囲がない状態で、ここから実装を始めてはいけません。

定義を始める準備ができました！ このスキルは、ユーザーが要件の明確化または問題定義を依頼し、明示的に呼び出した後に使用します。