brainstorm-to-issue

ブレインストーム → インテント issue

Superpowers との関係

Superpowers がインストールされている場合、その brainstorming スキルが通常、 このスキルが捕捉する会話になります。まだインテント issue がない作業では、 ブレインストーミングは 2 通りの終わり方をします。今すぐ構築するか（通常の 設計、計画、コード）、まず追跡するかです。このスキルは「まず追跡する」側の 終わり方です — superpowers-issue-bridge が、問題が理解された時点で、 ブレインストーミングがアプローチを提案する前に、その選択肢を提示します。

issue は インテントを記録するものであり、仕様ではありません。つまり、 問題、成果、そしてユーザーがすでに下した決定です。検討されただけの アプローチ、エッジケースの分析、誰も決定していない設計の詳細は省きます。 後でその issue を構築する人が、その時に設計します。その際、 superpowers-issue-bridge がこの issue からブレインストーミングのきっかけを 与えます。

これが適用される場合

ユーザーが問題、ニーズ、アイデアについて話し合い — Superpowers の ブレインストーミングで、あるいは任意の AI エージェントとの会話で（これは コーディングセッションに限った話ではありません）— それをすぐに構築するのではなく、 追跡したいと望んでいます。問題がまだ探索されている間ではなく、 ユーザーがその意思を示した時点（「これを起票して」「これを issue に しよう」、あるいは「まず追跡する」を選ぶ）でこれを実行します。

前提条件

1. docs/agents/issue-tracker.md を確認します。存在しない場合は、ユーザーに 先に setup-issue-tracker スキルを実行するよう伝え、停止します — トラッカーや リポジトリを推測しないでください。
2. そのファイルからトラッカー設定を読み取ります:
   • GitHub バックエンド: そこに記録されている owner/repo を使用します。gh が認証済みであることを確認し（gh auth status）、そうでない場合は、ユーザーに gh auth login を実行するよう伝えて停止します。
   • ローカル Markdown バックエンド: GitHub issue を作成する代わりに .scratch/<feature>/ に書き込みます — 以下のすべての gh ステップを スキップし、スラッグ化したタイトルをファイル名として使用します。
   • その他/自由形式のバックエンド: 記録されたメモに書かれている内容に 従います。メモがこのケースをカバーしていない場合は、ユーザーに尋ねます。
   • ユーザーがこの 1 回の実行のために別のリポジトリ/トラッカーを明示的に 指定した場合は、設定の代わりにそれを使用します — 一度限りの上書きでは セットアップを再実行する必要はありません。

手順

1. ブレインストーミングの会話を読み返し、できる限りユーザー自身の 言葉で以下を抽出します。

   • タイトル — 問題/機能の短い名前(これはイシューのタイトルになり、 本文内の # 見出しにはなりません)。
   • 問題 — 現状の何が、誰にとって、なぜ問題なのか。
   • 提案する成果 — 「より良い」状態とは何か。実装ではなく成果として 記述します。
   • 影響を受けるユーザーとシステム — これが誰と何に影響するか。
   • 制約 — すでに言及された厳格な制限(コンプライアンス、セキュリティ、 スコープの境界、期限)と、ユーザーが明示的に下したすべての決定を 要件として記述します(「既存のジョブキューを再利用する」)。 イシューを作成する側は、質問できないエージェントも含め、このセクションを 拘束力のあるものとして扱います。そのため、会話で検討されただけの選択肢 ではなく、ユーザーが決定したことを記録してください。
   • 未解決の問い — 真に未解決の事項。自信ありげな答えをでっち上げる のではなく、実際の不確実性をそのまま残してください。

2. 会話から実質的な内容がないセクションには、詳細を捏造するのではなく 「None identified」と記述してください。セクションを埋めて完成したように 見せかけないでください。

3. assets/intent-issue.md を読み、正確に記入してください — 同じ見出し、 同じ順序。タイトルは 2 回使用されます — 1 回はトラッカー内のイシュー 自身のタイトルとして、もう 1 回は本文冒頭の H1 として。これにより、 エクスポート、印刷、またはトラッカー外で表示した場合でも内容が正しく 読めます。

4. 下書きしたタイトルと本文をユーザーに示し、何かを作成する前に確認または 修正を求めてください。黙ってイシューを作成しないでください。

5. 確認が取れたら、設定されたバックエンドで作成します。GitHub では:

   gh issue create \
     --repo <owner>/<repo> \
     --title "<title>" \
     --body-file <tmp-file> \
     --label <label from docs/agents/issue-tracker.md, default: intent>
   

   (まだ存在しない場合は、まず gh label create <label> でラベルを作成して ください — ラベルが見つからない場合に黙って失敗しないでください。)

6. イシューの URL(またはファイルパス)をユーザーに報告してください。この インテントイシューは作業の入口です。後でこれを構築する側 — ユーザーまたは エージェント — はここから始め、superpowers-issue-bridge はここから ブレインストーミングの種をまき、完成した作業をここにリンクします。

7. これが Superpowers のブレインストーミングの track-first エンディングとして 実行された場合、セッションはここで終了します。ユーザーが今すぐ構築を 希望した場合にのみ、spec、plan、またはコードへ進んでください。

やってはいけないこと

• ブレインストーミングの途中でこれを実行しないでください — 議論が終わった という明示的な確認を待ってください。
• 空のセクションに内容をでっち上げないでください。
• 会話で検討されただけの選択肢を制約として記録しないでください — ユーザーが決定したことだけを記録してください。
• 下書きを先に示さずにイシューを作成しないでください。
• 推測できない場合、対象リポジトリを推測しないでください。
• イシューを提出した後、spec、writing-plans、またはコードへ進まないで ください。

---

Non-Claude-Code 版(プレーンプロンプト)

skills/自動検出の仕組みがないツール向けに、ブレインストーミングが終わったら これを一度きりのプロンプトとして貼り付けてください:

上記の会話に基づいて、まさにこのテンプレートを使ってイシューを下書きして ください — タイトルの H1、続いて 問題、提案する成果、影響を受けるユーザーと システム、制約、未解決の問い — 各セクションは数文で、実際に議論していない 事項には「None identified」を使用してください。制約には、厳格な制限と、 私たちが明示的に下したすべての決定を要件として記述してください。検討した だけの選択肢は省いてください。タイトルと本文をプレーンテキストで示して ください。まだ何も作成せず、下書きを見せるだけにしてください。

その後はご自身で作成してください — GitHub では、次で:

gh issue create --repo <owner>/<repo> --title "<title>" --body-file draft.md --label intent