project-brainstorming

使用する場面

• 要件が明確でない状態で新しいプロジェクトを開始するとき
• 仕様策定の前に問題領域を探索するとき
• 複数のアプローチを体系的に比較する必要があるとき
• プロジェクトの実現可能性と範囲を検証するとき
• ステークホルダー向けに意思決定の根拠を記録するとき
• 解決しようとしている中核的な問題を明確にする必要があるとき

使用しない場面

• 要件と仕様がすでに存在する場合（代わりに Skill(attune:project-planning) を使用してください）
• 既存の仕様を改善する場合（代わりに Skill(attune:project-specification) を使用してください）
• プロジェクトの範囲が明確に定義されている場合（/attune:project-init に進んでください）
• プロジェクト途中で方針転換する場合（戦略的な判断には Skill(attune:war-room) を使用してください）

連携

superpowers との連携：

• ソクラテス式問答法のために Skill(superpowers:brainstorming) に委譲します
• プロジェクト固有のパターンで補強します
• プロジェクトのブレインストーミング用テンプレートを使用します

superpowers がない場合：

• 単独で使える質問フレームワーク
• プロジェクトに焦点を当てたアイデア創出パターン
• 構造化された出力テンプレート

War Room との連携（必須）：

• フェーズ 3（アプローチの生成）の後、Skill(attune:war-room) を自動的に呼び出します
• ブレインストーミングのコンテキストをすべて War Room に渡し、専門家による検討を行います
• War Room では、複数の LLM による厳密な検証と統合を行います
• 明示的にユーザーの確認を得たうえで、Type 2 の判断（RS ≤ 0.40）の場合に限り省略されます

ブレインストーミングのフレームワーク

フェーズ 1：問題の定義

ソクラテス式の質問：

1. どのような問題を解決しようとしていますか？
2. この問題を経験しているのは誰ですか？
3. なぜ今、この問題を解決する価値があるのですか？
4. この問題が解決されなかった場合、何が起きますか？
5. これまでにどのような既存の解決策が試されましたか？
6. このプロジェクトが作成するものを誰が読みますか？また、その人はすでに何を知っていますか？その役割を担う人物を特定できる程度に、具体的な役割を挙げてください。

質問 6 によって、このプロジェクトが生成するすべてのドキュメントに適用される読者層が決まります。読者層は newcomer、practitioner、expert、または一行の persona です。回答を推測して草案を進めてしまいがちな執筆時ではなく、ここで質問してください。 読者層の表と追加の質問については、scribe:slop-detector モジュールの audience-targeting.md を参照してください。

出力：docs/project-brief.md 内の問題の記述

テンプレート：

## Problem Statement

**Who**: [Target users/stakeholders]
**What**: [The problem they face]
**Where**: [Context where problem occurs]
**When**: [Frequency/timing of problem]
**Why**: [Impact of the problem]
**Current State**: [Existing solutions and limitations]
**Doc audience**: [newcomer | practitioner | expert | persona: <one line>]

検証： コマンドに --help フラグを指定して実行し、利用可能であることを確認してください。

フェーズ 2：制約の把握

質問：

1. 技術面で譲れない制約は何ですか？
2. リソース面の制約（時間、予算、チーム）は何ですか？
3. 必要な統合ポイントは何ですか？
4. 適用されるコンプライアンス要件や規制要件は何ですか？
5. 成功基準と失敗の形態は何ですか？

出力：制約マトリックス

テンプレート：

## Constraints

### Technical
- [Constraint 1 with rationale]
- [Constraint 2 with rationale]

### Resources
- **Timeline**: [Duration with milestones]
- **Team**: [Size and skills]
- **Budget**: [If applicable]

### Integration
- [Required system 1]
- [Required system 2]

### Compliance
- [Requirement 1]
- [Requirement 2]

### Success Criteria
- [ ] [Measurable criterion 1]
- [ ] [Measurable criterion 2]

検証： コマンドに --help フラグを指定して実行し、利用可能であることを確認してください。

フェーズ 3：アプローチの生成

手法：異なるアプローチを 3～5 個生成します

各アプローチについて：

• 明確な説明（1～2 文）
• 技術スタック
• メリット（3～5 点）
• デメリット（3～5 点）
• リスク（2～3 点）
• 想定される作業量
• トレードオフ

テンプレート：

## Approach [N]: [Name]

**Description**: [Clear 1-2 sentence description]

**Stack**: [Technologies and tools]

**Pros**:
- [Advantage 1]
- [Advantage 2]
- [Advantage 3]

**Cons**:
- [Disadvantage 1]
- [Disadvantage 2]
- [Disadvantage 3]

**Risks**:
- [Risk 1 with likelihood]
- [Risk 2 with likelihood]

**Effort**: [S/M/L/XL or time estimate]

**Trade-offs**:
- [Trade-off 1 with mitigation]
- [Trade-off 2 with mitigation]

検証： コマンドに --help フラグを指定して実行し、利用可能であることを確認してください。

分離を考慮した設計：

アプローチを生成する際は、それぞれを次の 2 つの分離テストで評価してください。

1. 理解度テスト：各ユニットの内部を読まなくても、その役割を理解できますか？ユニットの目的を理解するために実装の詳細を読む必要がある場合、境界の設定が適切ではありません。
2. 変更テスト：利用側を壊さずに、ユニットの内部を変更できますか？実装の詳細を変更すると他の箇所にも変更が必要になる場合、インターフェースが内部に漏れています。

設計上のシグナルとしてのファイルサイズ：500 行（Python/Go）または 300 行（JavaScript/TypeScript）を超えるファイルは、ユニットが多くの役割を担いすぎていることを示す場合がよくあります。これは単なるスタイル上の問題ではなく、設計上の問題の兆候です。大きなファイルを指摘する際は、具体的な関心事を切り出す提案をしてください（例：「テスト容易性を高めるため、検証ロジックを別のモジュールに切り出してください」）。

検証： コマンドに --help フラグを指定して実行し、利用可能であることを確認してください。

フェーズ 3.5：ウォールームでの熟議（必須）

自動トリガー：アプローチを生成した後、専門家による熟議のため、必ず Skill(attune:war-room) を呼び出します。

ウォールームの呼び出し時：

• ブレインストーミングのコンテキスト（問題、制約、アプローチ）がすべて自動的にウォールームに渡されます
• 専門家パネルが各アプローチをレビューし、異議を唱え、厳しく検討します
• 可逆性を評価します
• 複数の LLM による熟議で見落としを特定します
• 最高司令官が根拠とともに統合案を提示します

コマンド：

# Automatically invoked from brainstorm - DO NOT SKIP
/attune:war-room --from-brainstorm

ウォールームの出力：

• 可逆性スコア（RS）と意思決定の種類
• 各アプローチへのレッドチームからの異議
• 選択したアプローチのプレモーテム分析
• 最高司令官の決定書
• 実装指示と監視ポイント

バイパス条件（以下のすべてを満たす場合に限り、ウォールームを省略）：

• RS ≤ 0.40（タイプ 2 の意思決定 — 明らかに可逆的）
• 意味のあるトレードオフがなく、明らかなアプローチが 1 つだけ
• 複雑さが低く、十分に文書化されたパターンがある
• RS 評価を提示された後、ユーザーが明示的に辞退する

ウォールームが完了してから、フェーズ 4 に進みます。

フェーズ 4：アプローチの比較

比較マトリックス：

基準	アプローチ 1	アプローチ 2	アプローチ 3	アプローチ 4
技術的適合性	🟢 高	🟡 中	🟡 中	🔴 低
リソース効率	🟡 中	🟢 高	🔴 低	🟡 中
価値実現までの時間	🟢 短い	🟡 中	🔴 長い	🟢 短い
リスクレベル	🟡 中	🟢 低	🔴 高	🟡 中
保守性	🟢 高	🟡 中	🟢 高	🔴 低

評価：🟢 = 良好、🟡 = 許容範囲、🔴 = 懸念あり

フェーズ 5：決定と根拠

選定基準：

1. 制約との整合性（すべてを満たす必要があります）
2. リスクとリターンのバランス
3. チームの能力と経験
4. 価値実現までの時間
5. 長期的な保守性

テンプレート：

## Selected Approach: [Approach Name] ⭐

### Rationale
[2-3 paragraphs explaining why this approach was selected]

Key decision factors:
- [Factor 1]
- [Factor 2]
- [Factor 3]

### Trade-offs Accepted
- **Trade-off 1**: [Description] → Mitigation: [Strategy]
- **Trade-off 2**: [Description] → Mitigation: [Strategy]

### Rejected Approaches
- **Approach X**: Rejected because [reason]
- **Approach Y**: Rejected because [reason]

検証： --help フラグを付けてコマンドを実行し、利用可能であることを確認します。

フェーズ 5.5：トレードオフを記録する（意思決定ジャーナル）

理由がまだ明確なうちに、フェーズ 5 での選択を docs/tradeoffs.md に記録します。セッション後にも残る項目として、決定内容、検討した代替案、断念した内容を記録します。下書きを作成して確認します。

• leyline がインストールされている場合は、Skill(leyline:decision-journal) を呼び出し、その手順に従ってトレードオフの記録を追記します。フェーズ 5 の項目は、直接次のように対応します。Selected Approach は decision、rationale は Y ステートメント、Trade-offs Accepted は consequences_negative、Rejected Approaches は options に対応します。phase は brainstorm に設定します。作成した記録を提示し、ユーザーの確認後に追記します（ステータスは proposed で開始）。
• フォールバック（leyline がない場合）：ファイル内の ENTRY TEMPLATE を使用して、docs/tradeoffs.md に手動で記録を追記します。次の TR-NNN ID を割り当て、active-index の行を追加します。

意味のあるトレードオフがなく、明らかなアプローチが実際に 1 つだけだった場合に限り、省略します（ウォールームをバイパスする条件と同じです）。

出力：プロジェクト概要

最終出力は docs/project-brief.md に保存します。

# [Project Name] - Project Brief

**Date**: [YYYY-MM-DD]
**Author**: [Name]
**Status**: Draft | Approved

## Problem Statement
[From Phase 1]

## Goals
1. [Primary goal]
2. [Secondary goal]
3. [Tertiary goal]

## Constraints
[From Phase 2]

## Approach Comparison
[From Phase 3 & 4]

## War Room Decision
[From Phase 3.5 - includes RS assessment, Red Team challenges, premortem]

## Selected Approach
[From Phase 5, informed by War Room synthesis]

## Next Steps
1. `/attune:specify` - Create detailed specification
2. `/attune:blueprint` - Plan architecture and tasks
3. `/attune:project-init` - Initialize project structure

検証： --help フラグを付けてコマンドを実行し、利用可能であることを確認します。

質問のパターン

ソクラテス式問答法

明確化：

• 「[term] とはどういう意味ですか？」
• 「例を挙げてもらえますか？」
• 「X と Y の違いは何ですか？」

前提を探る：

• 「[aspect] について、どのような前提を置いていますか？」
• 「その前提が妥当だと考える理由は何ですか？」
• 「その前提が誤っていたらどうなりますか？」

推論を探る：

• 「このアプローチが最善だと考える理由は何ですか？」
• 「それを裏付ける根拠は何ですか？」
• 「別の説明は考えられますか？」

見解を問う：

• 「[stakeholder] はこれについてどう考えるでしょうか？」
• 「反論として何が考えられますか？」
• 「どのような失敗が考えられますか？」

影響を探る：

• 「このアプローチを選ぶと、何が起こりますか？」
• 「長期的にはどのような影響がありますか？」
• 「これによって、どのようなことが確定しますか？」

制約に基づく思考

必須（譲れない条件）：

• 成功のために絶対に満たす必要があることは何ですか？
• 変更できない制約は何ですか？

望ましい（重要）：

• 成功の可能性を大きく高めるものは何ですか？
• どのような希望を最も重視しますか？

あればよい（あると望ましい）：

• 重要ではないものの、役に立つものは何ですか？
• 必要に応じて、何を延期または取りやめられますか？

対象外（明示的な除外事項）：

• 明確に実施しないことは何ですか？
• スコープの境界を設けて、どのようにスコープクリープを防ぎますか？

表面化させるべき危険信号

ブレインストーミング中は、次の点に注意します：

• ⚠️ 曖昧な問題の説明（「もっとよくする」など）
• ⚠️ 不明確な成功基準
• ⚠️ ユーザーやテクノロジーに関する隠れた前提
• ⚠️ 1つのアプローチへの偏り（代替案を検討していない）
• ⚠️ 要件のスコープクリープ
• ⚠️ 非現実的な制約やスケジュール
• ⚠️ ステークホルダーの視点の欠落

セッション状態の管理

セッションを .attune/brainstorm-session.json に保存します：

{
  "session_id": "20260102-143022",
  "started_at": "2026-01-02T14:30:22Z",
  "current_phase": "approach-selection",
  "problem": {
    "statement": "...",
    "stakeholders": ["..."]
  },
  "constraints": {
    "technical": ["..."],
    "resources": {"timeline": "...", "team": "..."}
  },
  "approaches": [
    {
      "name": "...",
      "pros": ["..."],
      "cons": ["..."]
    }
  ],
  "selected_approach": null,
  "decisions": {}
}

確認： --help フラグを付けてコマンドを実行し、利用可能か確認します。

フェーズ6：ワークフローの続行（必須）

自動トリガー：フェーズ5（決定と根拠）が完了し、docs/project-brief.md が保存された後、必ず次のフェーズを自動的に呼び出します。

続行を呼び出す際の手順：

1. docs/project-brief.md が存在し、空でないことを確認します
2. チェックポイントメッセージをユーザーに表示します：

   Brainstorming complete. Project brief saved to docs/project-brief.md.
   Proceeding to specification phase...
   

3. 次のフェーズを呼び出します：

   Skill(attune:project-specification)
   

続行をスキップできる条件（以下のいずれかに該当する場合のみ）：

• ユーザーが --standalone フラグを指定した
• docs/project-brief.md が存在しない、または空である（フェーズが失敗した）
• ユーザーがブレインストーミング後に停止するよう明示的に依頼した

ユーザーに確認を求めないでください：これは軽量なチェックポイントであり、対話型のゲートではありません。必要に応じて、ユーザーはいつでも中断できます。

フェーズ6.5：仕様レビューゲート

自動トリガー：フェーズ6でプロジェクト概要が保存された後、次のフェーズを呼び出す前に、仕様レビューのループを実行します。

手順：

1. レビュー用のプロンプトテンプレートとして modules/spec-review-loop.md を読み込みます
2. 仕様の内容を添えて、haiku-model サブエージェントに処理を割り当てます
3. 問題が見つかった場合：問題を修正し、再度処理を割り当てます（最大3回）
4. 承認された場合、または3回繰り返した場合：フェーズ6の続行に進みます

スキップできる条件：

• --standalone フラグが指定された
• --skip-review フラグが指定された
• 仕様ドキュメントが200語未満である（レビューするには短すぎる）

終了基準

• 互いに異なる3～5個のアプローチを作成し、比較している。
• 1つのアプローチが、明示的な根拠、受け入れるトレードオフ、却下した代替案とともに選択されている。
• 選択内容が docs/tradeoffs.md に proposed エントリーとして記録されている（または、明白な単一のアプローチであるためのスキップ条件が文書化されている）。
• 決定をまとめたプロジェクト概要が作成されている。

関連スキル

• Skill(superpowers:brainstorming) - ソクラテス式問答法（利用可能な場合）
• Skill(attune:war-room) - 必須の自動統合 - 複数のLLMによる審議のため、フェーズ3の後に呼び出されます
• Skill(imbue:scope-guard) - スコープクリープの防止
• Skill(attune:project-specification) - ブレインストーミング後の次のフェーズとして自動的に呼び出されます
• Skill(attune:mission-orchestrator) - ライフサイクル全体のオーケストレーション

関連コマンド

• /attune:brainstorm - このスキルを呼び出します
• /attune:specify - ワークフローの次のステップ
• /imbue:feature-review - 機能の価値を評価します

例

完全な例については、/attune:brainstorm コマンドのドキュメントを参照してください。