brainstorm

アイデアをデザインに落とし込む

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

エージェントをインテリジェントに選択し、構造化された探索を行うことで、漠然としたアイデアを完成度の高いデザインへと発展させます。

基本原則： トピックを分析し、関連するエージェントを動的に選択し、代替案を並行して検討し、デザインを段階的に提示します。

引数の解決

TOPIC = "$ARGUMENTS"  # Full argument string, e.g., "API design for payments"
# $ARGUMENTS[0] is the first token (CC 2.1.59 indexed access)

---

STEP -1：MCP の確認と再開チェック

スキルの開始時に MCP サーバーを一度確認して機能を保存し、以前クラッシュしたセッションがあれば再開します。各フェーズでは、次のフェーズが読み込む JSON の引き継ぎファイルを出力します。

手順全体と引き継ぎファイルの一覧：Read("references/mcp-probe-resume.md")

---

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

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

echo '{"tool_name":"Bash","tool_input":{}}' | node "${CLAUDE_PLUGIN_ROOT}/hooks/bin/run-hook.mjs" skill/prior-decisions-loader
echo '{"tool_name":"Bash","tool_input":{}}' | node "${CLAUDE_PLUGIN_ROOT}/hooks/bin/run-hook.mjs" skill/brainstorm-instructions-loader

タスクを作成したりエージェントを選択したりする前に、プロジェクトのティアを判定します。これは、以降のすべての判断における複雑さの上限になります。

自動検出（コードベースをスキャン）

# PARALLEL — quick signals (launch all in ONE message)
Grep(pattern="take-home|assignment|interview|hackathon", glob="README*", output_mode="content")
Grep(pattern="take-home|assignment|interview|hackathon", glob="*.md", output_mode="content")
Glob(pattern=".github/workflows/*")
Glob(pattern="**/Dockerfile")
Glob(pattern="**/terraform/**")
Glob(pattern="**/k8s/**")
Glob(pattern="CONTRIBUTING.md")

ティアの分類

シグナル	ティア
README に「take-home」、「assignment」、制限時間の記載がある	1. 面接
ファイルが 10 個未満で、CI も Docker もない	2. ハッカソン
.github/workflows/ があり、依存関係が 10～25 個	3. MVP
モジュールの境界、Redis、バックグラウンドジョブがある	4. 成長期
K8s/Terraform、DDD 構造、モノレポ	5. エンタープライズ
CONTRIBUTING.md、LICENSE、依存関係が最小限	6. オープンソース

**確信度が低い場合は、**ユーザーに尋ねます。

AskUserQuestion(questions=[{
  "question": "What kind of project is this?",
  "header": "Project tier",
  "options": [
    {"label": "Interview / take-home", "description": "8-15 files, 200-600 LOC, simple architecture"},
    {"label": "Startup / MVP", "description": "MVC monolith, managed services, ship fast"},
    {"label": "Growth / enterprise", "description": "Modular monolith or DDD, full observability"},
    {"label": "Open source library", "description": "Minimal API surface, exhaustive tests"}
  ],
  "multiSelect": false
}])

検出したティアを、以降のすべてのエージェントとフェーズにコンテキストとして渡します。 ティアによって適切なパターンが制限されます。全体のマトリックスについては、scope-appropriate-architecture スキルを参照してください。

上書き： ユーザーは検出されたティアをいつでも上書きできます。検出結果より高いティアを選んだ場合は、トレードオフについて警告してください。

---

STEP 0a：AskUserQuestion でユーザーの意図を確認

ブレインストーミングの制約を明確にします。

# NOTE: AskUserQuestion caps each question at 4 options (CC schema: minItems 2,
# maxItems 4). Use plain `label` + `description` only — the schema permits a
# `preview` field, but on current CC it forces a side-by-side picker layout with
# dead up/down keyboard nav (confirmed 2026-05-28), so skills no longer use it
# (`markdown` was never valid). The 6 legacy
# modes are split across 3 valid questions: Q1 = exploration flow, Q2 folds the
# old "Constrained design" mode into constraints, Q3 carries the orthogonal
# "Plan first" preamble (it composes with any Q1 mode — it was never mutually
# exclusive). "Quick ideation" + STEP 0c /effort=low overlap; both downscale.
AskUserQuestion(
  questions=[
    {
      "question": "What type of design exploration?",
      "header": "Mode",
      "options": [
        {"label": "Open exploration (Recommended)", "description": "Generate 10+ ideas, evaluate all, synthesize top 3"},
        {"label": "Comparison", "description": "Compare 2-3 specific approaches I have in mind"},
        {"label": "Quick ideation", "description": "Generate ideas fast, skip deep evaluation"},
        {"label": "Iterative optimization", "description": "Try, measure, keep/discard, repeat (autoresearch-style)"}
      ],
      "multiSelect": false
    },
    {
      "question": "Any preferences or constraints?",
      "header": "Constraints",
      "options": [
        {"label": "None", "description": "Explore all possibilities"},
        {"label": "Use existing patterns", "description": "Prefer patterns already in codebase"},
        {"label": "Minimize complexity", "description": "Favor simpler solutions"},
        {"label": "Fixed requirements (constrained)", "description": "Hard requirements to work within — skip divergent phase, focus on feasibility (old 'Constrained design' mode)"}
      ],
      "multiSelect": false
    },
    {
      "question": "Research before ideating?",
      "header": "Plan-first",
      "options": [
        {"label": "No — dive straight in (Recommended)", "description": "Go directly to ideation"},
        {"label": "Yes — plan first", "description": "Read-only research (EnterPlanMode): scan codebase, map the solution space, then ExitPlanMode for approval before Phase 1 (old 'Plan first' mode)"}
      ],
      "multiSelect": false
    }
  ]
)

Q3 = 'はい — まず計画する' の場合（Q1 のどのモードとも組み合わせ可能）：

# 1. Enter read-only plan mode
EnterPlanMode("Brainstorm exploration: $TOPIC")

# 2. Research phase — Read/Grep/Glob ONLY, no Write/Edit
#    - Scan existing codebase for related patterns
#    - Search for prior decisions on this topic (memory graph)
#    - Identify constraints, dependencies, and trade-offs

# 3. Produce structured exploration plan:
#    - Key questions to answer
#    - Dimensions to explore
#    - Agents to spawn and their focus areas
#    - Evaluation criteria

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

# 5. User reviews. If approved → continue to Phase 1 with plan as input.

回答に基づいてワークフローを調整します。

• 自由な探索（Q1）：すべてのエージェントを使って 7 フェーズの全プロセスを実行
• 比較（Q1）：アイデア出しを省略し（フェーズ 2 をスキップ）、評価フェーズに進む
• 手早いアイデア出し（Q1）：アイデアを生成し、詳細な評価を省略
• 反復最適化（Q1）：フェーズ 2～6 をスキップし（フェーズ 2 のファンアウトなし）、autoresearch 形式のループに入る（以下を参照）
• 要件を限定したデザイン（Q2 = "固定要件"）：発散フェーズを省略し（フェーズ 2 をスキップ）、明示された要件の範囲内で実現可能性に焦点を当てます。Q1 のどのモードとも組み合わせ可能です

「反復最適化」が選択された場合： フェーズ 2～6 をスキップし、autoresearch 形式のメトリクス駆動ループに入ります。

サブフロー全体（メトリクスに関する質問、ベースライン、ループ本体）：Read("references/iterative-optimization-mode.md")

---

STEP 0b：オーケストレーションモードを選択（ティア 1～2 ではスキップ）

Agent Teams（メッシュ形式。エージェントがアイデアを議論し、異議を唱える）または Agent tool（スター形式。全員がリードに報告する）を選択します。

1. Agent Teams モード（CC 2.1.33 以降で GA）→ 3 つ以上のエージェントに推奨（リアルタイムの議論によって、より良いアイデアが生まれます）
2. Agent tool モード → 手早いアイデア出し向け
3. ORCHESTKIT_FORCE_TASK_TOOL=1 → Agent tool（上書き）

項目	Agent Tool	Agent Teams
アイデア生成	各エージェントが個別に生成	エージェントが互いのアイデアを発展させる
デビルズアドボケイト	全員の完了後にリードが異議を唱える	エージェント同士がリアルタイムで異議を唱える
コスト	約 150K トークン	約 400K トークン
最適な用途	手早いアイデア出し、要件を限定したデザイン	自由な探索、詳細な評価

フォールバック： Agent Teams で問題が発生した場合は、残りのフェーズで Agent tool に切り替えます。

---

ステップ 0c：労力に応じたフェーズのスケーリング（CC 2.1.76；xhigh は 2.1.111 で追加）

/effort の設定を読み取り、ブレインストーミングの深さを調整します。low ではフェーズ 0／2／5 のみ、high（デフォルト）では全 7 フェーズ、xhigh では追加の悪魔の代弁者ラウンドと統合ラウンドを実行します。STEP 0a でユーザーが明示的に選択した場合は、常にダウンスケーリングより優先されます。

レベルの全一覧と判定ルール：Read("references/effort-scaling.md")

フェーズ 2 は、上記のレベルにかかわらず、常に労力レベル low で実行されます。ループ内のアイデア創出では低い労力が効果を発揮しますが、スコアリングではそうではありません。このスキルに effort: のフロントマターがないのは意図的です（指定するとフェーズ 4 の労力まで下げてしまうため）。代わりに、workflows/brainstorm-diverge.js がすべてのジェネレーターに effort: "low" を渡します。詳細は同じリファレンスを参照してください。

ファンアウトのルール： 選択したモードでフェーズ 2 を実行する場合、単一パスでの実行をフォールバックにすることはできません。フェーズ 2 は Workflow 呼び出し、Agent Teams、または Agent ツールを通じて実行します。このスキルは Workflow ツールを使えないため、インラインで実行されます（#4696）。いずれの方法でもジェネレーターを起動できない場合は、実行を BLOCKED として終了し、その理由を説明してください。フェーズ 2 をスキップするモード（Comparison、Iterative optimization、Constrained design）は違反ではありません。

---

完了条件。 上位のアプローチすべてについて 7 つの評価軸で採点し、ユーザーが選択できるようトレードオフを提示すれば完了です。Read("../../shared/rules/long-run-protocol.md") に従ってください。ユーザーからの入力が不要なステップでは続行し、ユーザーなしでは続行できない場合、または破壊的な操作の前にのみ停止して質問してください。各サブエージェントの証拠を確認してから採用し、確認できなかった項目には、どこを調べたかを記載してください。

🚨 重要：タスク管理は必須です（CC 2.1.16）

# 1. Create main task IMMEDIATELY
TaskCreate(
  subject="Brainstorm: {topic}",
  description="Design exploration with parallel agent research",
  activeForm="Brainstorming {topic}"
)

# 2. Create subtasks for each phase
TaskCreate(subject="Analyze topic and select agents", activeForm="Analyzing topic")          # id=2
TaskCreate(subject="Search memory for past decisions", activeForm="Searching knowledge graph") # id=3
TaskCreate(subject="Generate divergent ideas (10+)", activeForm="Generating ideas")          # id=4
TaskCreate(subject="Feasibility fast-check", activeForm="Checking feasibility")              # id=5
TaskCreate(subject="Evaluate with devil's advocate", activeForm="Evaluating ideas")          # id=6
TaskCreate(subject="Synthesize top approaches", activeForm="Synthesizing approaches")        # id=7
TaskCreate(subject="Present design options", activeForm="Presenting options")                # id=8

# 3. Set dependencies (sequential chain: 2→3→4→5→6→7→8)
for i in range(3, 9):
    TaskUpdate(taskId=str(i), addBlockedBy=[str(i-1)])

# 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

---

🔄 7 フェーズのプロセス

フェーズ	作業内容	出力
0. トピック分析	キーワードを分類し、3～5 人のエージェントを選択	エージェント一覧
1. メモリとコンテキスト	グラフを検索し、コードベースを確認し、実験ジャーナルを読む	既存のパターン
2. 発散的探索	フィルタリングせずに 10 個以上のアイデアを生成	アイデアプール
3. 採否ゲート	実現可能性を二択で判定：採用、却下、またはクラッシュ（アイデアごとに 10 秒）	生き残ったアイデアのみ
4. 評価と採点	0～10 で採点（シンプルさを含む 7 つの評価軸）、悪魔の代弁者	ランキング済みアイデア
5. 統合	上位 2～3 件に絞り、トレードオフ表を作成し、各アプローチのテスト戦略を提示	選択肢
6. デザインの提示	200～300 語のセクションに分けて提示し、実験ジャーナルに記録	検証済みデザイン
6.4. Living Plan Playground（任意。依頼時または複数ウェーブの計画の場合）	visualize-plan の living-plan パスを介して、更新可能な LPP プレイグラウンドを出力	<slug>.html（living）
6.5. 音声ポッドキャスト（シグナル発火時、任意）	複合スコアが 8.0 以上かつアプローチ数が 4 以上の場合、brainstorm-podcast.m4a を自動出力	.m4a ファイル

フェーズ 6.4 — Living Plan Playground（任意）

ユーザーがプレイグラウンドの出力を求めた場合、または統合の結果が複数ウェーブの計画（検証可能な項目を含む 2 つ以上の実行ウェーブ）になった場合は、一度限りのレンダリングではなく、デザインをリビングプラン・プレイグラウンドとして出力します。ウェーブにはフェーズ 5 の統合結果、7 つの評価軸のスコアにはフェーズ 4、却下したアイデアとその理由にはフェーズ 3 の内容を使用します。各作業単位には項目を 1 つずつ割り当て、「完了条件」となる証拠確認を含めます。visualize-plan の living-plan パスを使用します（例：living-plan.template.html、更新モードの仕様は references/format-dispatch.md の §Living-plan update mode）。成果物はその後の実行状況を追跡します。後続のセッションでは、埋め込みの lpp-state JSON 内で項目のステータスを変更し、変更履歴に追記します。1 つの計画につき 1 つのファイルとし、分岐は作成しません。

フェーズ 6.5 — 合成後の音声ポッドキャスト（シグナル発火時、任意）

フェーズ 6 の完了後、必要に応じて scripts/post_synth_podcast.py <session-dir> を実行すると、主なアプローチとトレードオフをまとめた音声ポッドキャストを自動生成します。正常に進まない場合は常に自動スキップするため、ブレインストーミングが妨げられることはありません。

python3 ${CLAUDE_SKILL_DIR}/scripts/post_synth_podcast.py "$CLAUDE_JOB_DIR"

自動スキップ条件（すべて終了コード 0、すべて WARN ログに記録）：

スキップ理由	トリガー
signal absent	composite[recommended] < 8.0 OR len(approaches) < 4
design-doc.md not found	フェーズ 6 でセッションディレクトリに設計ドキュメントが書き込まれなかった
yg-mcp-core not importable	yg-mcp-core>=0.3.0 がインストールされていない（orchestkit は公開されており、yg-mcp-core はプライベートな pypi.yonyon.ai にあります — HQ 専用）
hq-content MCP unreachable	MCP サーバーが停止している OR .mcp.json で hq-content が定義されていない

セッションディレクトリには brainstorm-output.json（recommended、composite、approaches を含む）と design-doc.md が必要です。ハンドオフ JSON の <session-dir>/brainstorm-podcast.json には、status（fired / skipped）と、成功時の m4a_path が記録されます。

Yonatan-HQ/hq-ext-plugin#194（/hq-ext:decide の audio_podcast ハンドラー）を反映しています。

段階的な出力（CC 2.1.76）

各フェーズの完了後に結果を段階的に出力してください。最後までまとめて出力しないでください。

フェーズ完了後	ユーザーに表示する内容
0. トピック分析	選択されたエージェント、ティア分類
1. メモリ + コンテキスト	過去の決定、関連するパターン、実験ジャーナルの要約
2. 発散的な探索	各エージェントのアイデアが返ってきたら順次表示（全員を待たない）
3. 採用／却下ゲート	残ったアイデアと却下理由（各アイデアを採用／却下／クラッシュに分類）
4. 評価	7 つの評価軸でのスコアが高いアイデア

フェーズ 2 の並列エージェントについては、各エージェントのアイデアが返ってきたらすぐに出力してください。全員の完了を待たないでください。こうすることで、ユーザーは早い段階でアイデアを確認し、必要に応じて探索の方向を変えられます。アイデアを段階的に表示することで、最後にまとめて出力するよりも、ユーザーが解決策の全体像をすばやく把握できます。

詳しい手順については、フェーズのワークフローを読み込んでください。

Read("references/phase-workflow.md")

---

⚠️ 使用しない場合

次の場合はブレインストーミングをスキップしてください。

• 要件が非常に明確で具体的である
• 明らかなアプローチが 1 つしかない
• ユーザーがすでに解決策を設計している
• 時間に制約のあるバグ修正や緊急の問題である

---

クイックリファレンス：エージェントの選択

トピックの例	起動するエージェント
"ユーザー向けの API をブレインストーミングする"	workflow-architect, backend-system-architect, security-auditor, test-generator
"ダッシュボード UI をブレインストーミングする"	workflow-architect, frontend-ui-developer, test-generator
"RAG パイプラインをブレインストーミングする"	workflow-architect, llm-integrator, data-pipeline-engineer, test-generator
"キャッシュ戦略をブレインストーミングする"	workflow-architect, backend-system-architect, frontend-performance-engineer, test-generator
"デザインシステムをブレインストーミングする"	workflow-architect, frontend-ui-developer, design-context-extractor, component-curator, test-generator
"イベントソーシングをブレインストーミングする"	workflow-architect, event-driven-architect, backend-system-architect, test-generator
"価格戦略をブレインストーミングする"	workflow-architect, product-strategist, web-research-analyst, test-generator
"デプロイパイプラインをブレインストーミングする"	workflow-architect, infrastructure-architect, ci-cd-engineer, test-generator

必ず含めること： システム設計の観点を担う workflow-architect と、テスト容易性を評価する test-generator。

---

エージェントチームの代替案：ブレインストーミングチーム

エージェントチームモードでは、エージェントがリアルタイムでアイデアを議論するブレインストーミングチームを編成します。トピック分析（フェーズ 0）に基づいて、チームメイトを動的に選択します。

# CC 2.1.178+: one implicit team per session — no TeamCreate.
# Spawn teammates directly via Agent(name=...). Requires
# CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 (set in ork.settings.json).

# Always include the system design lead
Agent(subagent_type="ork:workflow-architect", name="system-designer",
     team_name="brainstorm-{topic-slug}",
     prompt="""You are the system design lead for brainstorming: {topic}
     DIVERGENT MODE: Generate 3-4 architectural approaches.
     When other teammates share ideas, build on them or propose alternatives.
     Challenge ideas that seem over-engineered — advocate for simplicity.
     After divergent phase, help synthesize the top approaches.""")

# Domain-specific teammates (select 2-3 based on topic keywords)
Agent(subagent_type="ork:backend-system-architect", name="backend-thinker",
     team_name="brainstorm-{topic-slug}",
     prompt="""Brainstorm backend approaches for: {topic}
     DIVERGENT MODE: Generate 3-4 backend-specific ideas.
     When system-designer shares architectural ideas, propose concrete API designs.
     Challenge ideas from other teammates with implementation reality checks.
     Play devil's advocate on complexity vs simplicity trade-offs.""")

Agent(subagent_type="ork:frontend-ui-developer", name="frontend-thinker",
     team_name="brainstorm-{topic-slug}",
     prompt="""Brainstorm frontend approaches for: {topic}
     DIVERGENT MODE: Generate 3-4 UI/UX ideas.
     When backend-thinker proposes APIs, suggest frontend patterns that match.
     Challenge backend proposals that create poor user experiences.
     Advocate for progressive disclosure and accessibility.""")

# Always include: testability assessor
Agent(subagent_type="ork:test-generator", name="testability-assessor",
     team_name="brainstorm-{topic-slug}",
     prompt="""Assess testability for each brainstormed approach: {topic}
     For every idea shared by teammates, evaluate:
     - Can core logic be unit tested without external services?
     - What's the mock/stub surface area?
     - Can it be integration-tested with docker-compose/testcontainers?
     Score testability 0-10 per the evaluation rubric.
     Challenge designs that score below 5 on testability.
     Propose test strategies for the top approaches in synthesis phase.""")

# Optional: Add security-auditor, llm-integrator based on topic

主な利点： エージェントは個別にアイデアを生成するのではなく、リアルタイムで互いのアイデアを発展させ、あえて反対意見を述べます。 フォークパターン（CC 2.1.89 #1227、CC 2.1.232 から明示的に適用）： すべてのブレインストーミングエージェントはフォークの対象になります。プロンプトは500語未満で、カスタムモデルもワークツリーも使用しません。CCはフォーク間で親のキャッシュ済みAPIプレフィックスを共有するため、コストを約60％削減できます。エージェント呼び出しに model= を追加しないでください。CC 2.1.232 以降、フォークはデフォルトで有効になっており、subagent_type: "fork" で明示的に選択できます。そのため、適用条件が関係するのは通常の Agent() 呼び出しのみです。chain-patterns/references/fork-pattern.md を参照してください。

ネストされた委任（CC 2.1.172 以降）： チームメイトには、推測してその場で回答する代わりに、宣言済みのサブエージェントへ範囲を限定した小問を委任するよう指示できます（例：スキーマ案の妥当性を確認するため、backend-thinker から database-engineer へ委任）。チェーンは3階層以内にしてください。分岐するアイデア出し自体はフラットな構成を維持します。上記の並列チームメイトが、独立したアイデアを広げる役割を担います。chain-patterns のパターン9（CC 2.1.172 以降）を参照してください。

統合後にチームを終了します：

# After Phase 5 synthesis and design presentation
# CC 2.1.178+: no TeamDelete — teammates wind down at turn end
# (press Ctrl+F twice to stop lingering background teammates).

# Worktree cleanup (CC 2.1.72) — for Tier 3+ projects that entered a worktree
# If EnterWorktree was called during brainstorm (e.g., Plan first → worktree), exit it
ExitWorktree(action="keep")  # Keep branch for follow-up implement

フォールバック： チームの編成に失敗した場合は、Read("references/phase-workflow.md") を読み込み、標準的な Phase 2 の Task 起動を使用してください。

部分的な結果（CC 2.1.76、2.1.246 で拡張）： 強制終了されたバックグラウンドエージェント（タイムアウト、コンテキスト上限）は、[PARTIAL RESULT] のタグが付いた応答を返します。CC 2.1.246 以降では、maxTurns の上限に達して停止したエージェントも部分的な結果として報告されます。要約には「Nターンの上限で停止しました（部分的な結果。task-id に SendMessage を送信して続行できます）」と表示され、出力も完了済みではなく部分的なものとしてマークされます。Phase 2 で分岐したアイデアを収集する際は、各エージェントの出力にどちらの形式が含まれているか確認してください。含まれている場合は、部分的なアイデアも取り入れたうえで、Phase 3 の実現可能性評価では未完了であることを明記してください。ターン上限に達した場合は、そのエージェントの ID に「停止したところから続けて」と SendMessage を送ると、コンテキストを再利用できます。エージェントを再起動すると最初から始まり、プロンプトの分も再度コストがかかります。ターン上限に達したエージェントを、完了済みとして扱わないでください。

別セッションへの返信は親に届きます（CC 2.1.248）： サブエージェントが別のセッションに SendMessage を送信した場合、返信はサブエージェントではなく親セッションの会話に届きます。サブエージェントは送信後に処理を続け、親が返信を読みます。セッションをまたぐ SendMessage／ListAgents は、Bedrock、Vertex、Foundry、およびテレメトリーが無効な場合にも利用できます（CC 2.1.248）。

PostCompact による復旧： 長時間のブレインストーミングセッションでは、コンテキストの圧縮が発生することがあります。PostCompact フックはブランチとタスクの状態を再注入します。ブレインストーミングの途中で圧縮が発生した場合は、最後に完了したフェーズを確認するために .claude/chain/state.json を調べ、次のハンドオフファイルから再開してください（Phase Handoffs の表を参照）。リアクティブ圧縮（CC 2.1.142 以降）では、最初の要約のサイズが実際のオーバーフロー量に合わせられるため、ターンの途中で停止することはまれです。2回目の処理を想定する必要はありません。

コンテキストがいっぱいになった場合（CC 2.1.141 以降）： セッションを終了する代わりに、巻き戻しメニューの「Summarize up to here」を使って、直近のコンテキストを保ったまま以前のターンを圧縮してください。これは、前述の改善されたリアクティブ圧縮と組み合わせられる、意図的な圧縮ポイントです。

セッションの要約（CC 2.1.108 以降）： アイドル期間の後は、チェックポイントからの再開に加えて /recap を使い、会話のコンテキストを復元してください。CC 2.1.110 以降はデフォルトで有効です（テレメトリーが無効な場合も含む）。

プッシュ通知（CC 2.1.110 以降）： 長時間のブレインストーミングセッションでは、統合の完了時に通知するため PushNotification を使用してください（「Push when Claude decides」を指定した Remote Control が必要です）。

より軽量な代替手段（CC 2.1.141 以降）： フックは、フック JSON 出力の terminalSequence フィールドを介して、デスクトップ通知、ウィンドウタイトル、ベルをネイティブに出力できます。Remote Control は不要で、Anthropic との往復通信もありません。Ork の通知フック（notification/desktop、notification/sound）は、すでに terminalSequence を介して出力しています（#1847、リリース済み）。

手動でのクリーンアップ： 残っているバックグラウンドのチームメイトを停止するには、Ctrl+F を2回押します（フォアグラウンド／停止）。注：/clear（CC 2.1.72 以降）を実行してもバックグラウンドエージェントは保持されます。消去されるのはフォアグラウンドのタスクのみです。 チームメイトのバックグラウンドタスクはターン終了後も継続します（CC 2.1.183）： チームメイトが開始したバックグラウンドタスクは、そのチームメイトのターンが終了しても強制終了されなくなりました。Phase-2 のチームメイトは、長時間かかる run_in_background タスク（例：実現可能性を確認するビルド）を安心して開始し、自分のターン終了後も実行させられます。結果は統合時に引き続き取得できます。2.1.183 より前は、バックグラウンドタスクをリードが所有する必要がありました。

この主張は自動的にバックグラウンド化された処理には当てはまりません（#3448）： タイムアウト時にハーネスがバックグラウンド化するフォアグラウンドの Bash 呼び出しは、別の経路です。完了通知はそれを起動したエージェントに送られます。そのエージェントが「待ちます」と言ってすでにターンを終えている場合、通知の送信先はなく、ログにエラーがまったく記録されないまま出力が失われます。ここから導かれるルールは 2 つあります。ドキュメントに記載された実行時間が Bash のタイムアウトに近づく可能性がある調査呼び出し（tavily-research の公称実行時間は 30～120 秒で、実際のクエリは 180 秒を超えることがあります）は、リードが所有します。また、X を取得するか、X の所有権をリードに引き継ぐことなく、チームメイトが「X を待ちます」と言ってターンを終えることはできません。

---

主な原則

原則	適用方法
エージェントの動的な選択	トピックのキーワードに基づいてエージェントを選択します
並行調査	1 つのメッセージでエージェントを 3～5 個起動します
メモリ優先	調査の前にグラフを確認し、過去の決定を調べます
発散を先に行う	絞り込む前に 10 個以上のアイデアを生成します
タスク追跡	進捗を可視化するために TaskCreate/TaskUpdate を使用します
YAGNI を徹底する	不要な複雑さを取り除きます

---

/goal を使った無人実行

/goal（CC 2.1.139 以降。このスキルでは 2.1.143 以降を推奨）で完了条件を設定すると、その条件が満たされるまで、このスキルはターンをまたいで作業を続けます。インタラクティブモード、-p、Remote Control で動作します。オーバーレイパネルには、経過時間、ターン数、トークン数がリアルタイムで表示されます。

2.1.143 以降を推奨する理由： 2.1.143 より前は、バックグラウンドシェルや委任されたサブエージェントがまだ実行中のときに /goal の評価が発生することがあり、このスキルが Phase 2 で起動する並列エージェントと競合していました。これは CC 2.1.143 で修正されました（変更履歴：「バックグラウンドシェルまたは委任されたサブエージェントの実行中に /goal の評価が発生する」）。

このスキルの完了条件の例：

/goal until design.options_count >= 2 AND user_chose_option, or stop after 8 turns

2 つ以上の評価済み設計案が提示され、ユーザーが 1 つを選択した時点で停止します（または、-p で無人実行する場合は Phase 6 の後に停止します）。claude.ai Remote Control の実行にも対応しています。

---

品質基準

以下をすべて満たしたら完了です。

• Phase 2 で、絞り込みを行う前に 10 個以上の異なるアイデアが作成され、それぞれのエージェントから返された時点で提示されている
• 採用／却下の判定を通過した各アイデアに、採用／却下／クラッシュのいずれかを示す 1 行の判定が付いている
• 残った各アイデアが、7 つすべての評価軸（シンプルさを含む）で 0～10 点の評価を受け、さらに悪魔の代弁者による課題が 1 つ提示されている
• 統合によって 2～3 個のアプローチに絞り込まれ、トレードオフ表とアプローチごとのテスト戦略が示されている
• 出力の最後に、ユーザーが選択する順位付きの案が提示されている（または、-p で無人実行する場合は Phase 6 が完了している）

📜 関連スキル

• ork:architecture-decision-record - ブレインストーミングで行った重要な決定を記録します
• ork:implement - ブレインストーミング完了後に実装計画を実行します
• ork:explore - 既存のパターンを理解するためにコードベースを詳しく調査します
• ork:assess - 品質を 0～10 点で評価し、評価軸ごとに内訳を示します
• ork:design-to-code - ブレインストーミングで作成した UI デザインをコンポーネントに変換します
• ork:component-search - 新しいコンポーネントを作成する前に既存のコンポーネントを探します
• ork:competitive-analysis - 製品のブレインストーミングに Porter のファイブフォース分析と SWOT 分析を活用します

ピッカーのフォールバック（#1795）

orchestkit#1795 で報告されたピッカーの停止は、CC の入力バグではなく、スキーマの破損が原因でした。4 個を超える選択肢、または markdown フィールド（markdown キーは無効です。スキーマのフィールドは preview です）を含む質問は、AskUserQuestion の検証に失敗するため、ピッカーが表示されません。すべてのスキルの質問はスキーマに準拠しており（選択肢は 2～4 個、multiSelect では preview を使用しない）、これは tests/skills/structure/test-askuserquestion-schema.sh によって検証されます。別の問題として、スキーマでは preview フィールドが許可されていますが、現在の CC ではこれを使用する質問がサイドバイサイドのピッカーレイアウトで表示され、キーボードの↑/↓キーによる移動が機能しません（2026-05-28 に確認済み）。そのため、スキルでは label と description のみを使い、preview は設定しないよう統一しています。今後の CC ビルドで停止が発生する場合に備えた防御的なオプトイン設定として、ORK_ASK_FALLBACK=text も引き続き利用できます。この場合、lifecycle/ask-fallback-injector フックが、番号付きリストをインラインで使って選択肢を提示するようアシスタントに指示します。このフックはグローバルに適用されるため、スキルごとの編集は不要です。

参照資料

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

ファイル	内容
phase-workflow.md	7 フェーズの詳細な手順
divergent-techniques.md	SCAMPER、マインドマッピングなど
evaluation-rubric.md	0～10 の評価基準
devils-advocate-prompts.md	課題提示のテンプレート
socratic-questions.md	要件の把握
common-pitfalls.md	避けるべき間違い
example-session-dashboard.md	完全な例
mcp-probe-resume.md	STEP -1 のプローブ＋再開＋引き継ぎファイルの表
iterative-optimization-mode.md	Autoresearch 形式のメトリックループのサブフロー
effort-scaling.md	/effort のレベルとフェーズのスケーリングルール