brainstorming-to-issue

ブレインストーミングから GitHub Issue へ

基本原則

必須のサブスキル： superpowers:brainstorming（v7）を記載どおりに実行してください。このスキルは、v7 が認める「人間のパートナーの好み」に対応するものです。設計は docs/ ではなく GitHub issue に保存します。v7 にない要素として追加するのは、issue への永続化、issue だけからの再開（どのセッション、どのハーネスからでも可）、[DRAFT] のタイトル接頭辞（「まだブレインストーミング中」を示す）、分割のみです。v7 の対話、プレイバック、規模の見積もり、スパイク、ビジュアルコンパニオン、設計の形式、ビルダーチェックを言い換えたり、解釈し直したりしないでください。その指示に従ってください。

正確な gh コマンド、本文の形式、## Brainstorm state セクションについては、issue-lifecycle.md を参照してください。

開始

番号の指定がない場合：

1. キーワードでオープンな issue を検索します。
2. [DRAFT] in:title を検索します。
3. 該当する可能性のある issue があれば、それを提示して、「#N を採用するか、新しく始めるか」を尋ねます。黙って再利用したり、重複させたりしてはいけません。
4. 該当なし（または「新規」）の場合、最初の質問をする前に、末尾に state セクションを付けた [DRAFT] issue を作成します。その Next: には最初の質問を記載します。
5. v7 の開始メッセージを送ります。ただし、v7 の最初の確認で、すぐに対応できる明確なタスクだと分かった場合は例外です。その場合は、依頼を issue として記載し、サイズを quick task として引き継ぎます（開始時の質問はせず、依頼された場合にのみ実装します）。

番号の指定がある場合： gh issue view N --json title,body,comments で読み込み、次のように振り分けます。

issue の状態	対応
[DRAFT] + ## Brainstorm state	再開
[DRAFT] + 古い ## Brainstorm log または <details> のログ	変換（issue-lifecycle.md を参照）してから再開
[DRAFT] + どちらもなし（ブレインストーミングされる前に差し戻されたもの）	本文はそのままに state セクションを追加してから再開します。競合コメント（下記）がなければ、「開始」ステップ 5 から続けます
[DRAFT] なし + state セクションまたは古い <details> のログあり	改訂（Next: 行があれば進行中です。そこから再開します）
[DRAFT] なし + どちらもなし	プレースホルダーです。採用時に [DRAFT] を追加し、本文を設計に取り込んで state セクションを追加してから、「開始」ステップ 5 に進みます

[DRAFT] から再開する場合は、最新のコメント（createdAt 順）を読みます。plan-to-implementation の競合コメントが Next: または設計にまだ反映されていない場合は、Next: を「これらの競合をユーザーと解決する」に設定し、その後、以下の改訂の 5 つのステップをすべて実行します（引き継ぎ時に [DRAFT] が削除されるまで、[DRAFT] は維持します）。

永続化

ユーザーから各返信が届いたら、ほかのことをする前に（いつ中断しても、未完了の作業が残らないようにするため）、次の手順を実行します。

1. 現在の本文を取得します。
2. 会話の記憶ではなく、その本文をもとに書き直し、結果を該当する設計セクションに反映します。
3. Next: を、次のメッセージで待っている内容と完全に一致させます（新たに確定した記憶事項も追加します）。メッセージを送る前に待っている内容が変わった場合は、再度更新します。
4. 本文を更新します。

v7 の「作業規模の見積もり」に従って、ユーザーに通常の言葉で規模を伝える場合は、同じ書き直しの中で Size: に記録します。保存するのは結果だけです。設計セクションには v7 の記録ルールを適用します。推測には自分の推測であると印を付け、自分が選んだものには自分の判断であると印を付け、ユーザーが発言した内容だけは印を付けずに記載します。プレイバックの文章、Q&A ログ、判断の履歴、ユーザーの発言の引用は保存しないでください。途中の状態では保存せず、手間の少ない作業はやり直してください。対象は、調査、未完了のビルダーチェック、コンパニオンサーバーです。

再開

すでに決着したことを再度尋ねてはいけません。自分の推測として記された行は、ユーザーが確認するまで推測のままです。Next: に従ってください。

• 質問の場合 → 文言を変えずに再度尋ねます
• プレイバックの場合 → 設計セクションから組み立て直して、再提示します
• ビルダーチェックの質問の場合 → 文言を変えずに、1 つのメッセージですべて再度尋ねます。チェックを再実行してはいけません。回答を得たら設計を更新して、引き継ぎます
• 引き継ぎのステップの場合 → そのステップをやり直します
• re-brainstorm — grew from <size>: <what was added> の場合 → 追加された内容に絞って、改訂の 5 つのステップをすべて実行します

記憶事項（Opted out of questions., Visual companion declined., Split:）を尊重してください。各返信後、永続化を続けます。

ハーネスの不足

サブエージェントツールがない場合：自分がビルダーとして issue を読みます。ブラウザーがない場合：選択肢をテキストで説明します。ビジュアルコンパニオンの選択とスパイクで得た知見は、言葉で設計に記載します。

Builder check — プロジェクトのみ

builder-check-prompt.md のドキュメントに課題を指定します：「gh issue view N --json title,body で issue #N を読んでください。」結果は state セクションに記録します（Builder check: ran on this version. Questions for the user: …）。回答済みの質問はそれぞれ削除します。

引き継ぎ — v7 の終了時に適用する唯一の上書き

docs/ の仕様書も、コミットも、writing-plans もありません。v7 がドキュメント（プロジェクト）を引き継ぐ段階、または説明の承認を得た段階（クイックタスク、小規模な変更）になったら、次の 6 つの手順を順番どおりに実行します。

1. 本文が、そのサイズに合った形式になっていることを確認します。プロジェクトの場合は設計書、クイックタスクまたは小規模な変更の場合は、必須セクションのない短い説明です（builder check は不要です）。
2. タイトルから [DRAFT] を削除します。
3. state セクションを、そのサイズに応じた引き継ぎ後の形式にします。
4. issue のリンクと、私の判断の一覧を提示します。
5. そのサイズに応じた引き継ぎの文言を提示します。
   • project：「新しいセッションで issue-to-plan #N を実行してください。」
   • quick task / small change：「#N を直接実装してください。計画は不要です」。続けて state セクションに記載されたビルド手順を示します。
6. 停止します（分割している場合は、まず次の兄弟 issue を提案します）。これ以上のレビューはありません。次の手順を実行することが承認になります。変更は brainstorming-to-issue #N を通じて戻します。

質問への回答を辞退する場合

ユーザーが質問への回答を辞退した場合（開始時でも、その後でも）：それまでの回答を残したうえで、依頼内容から issue を作成します。私の判断を記録し、サイズを決めて、Opted out of questions. を追加し、引き継ぎます。プロジェクトの場合も builder check は不要です。

改訂

1. [DRAFT] を再度追加してはいけません。古い <details> のログは、今すぐ issue-lifecycle.md に変換します。新たな引き継ぎが完了するまでは、state セクションを Next: も含めてドラフト形式にし、通常どおり保存処理を実行します。
2. ユーザーが変更したい内容に絞って v7 の会話を行い、変更箇所だけを提示します。
3. 設計が変更されたプロジェクトは、新しいバージョンで builder check を改めて実行します。
4. サイズを再判定し、私の判断の一覧を更新して、再度引き継ぎます。
5. issue の計画を含む未完了のドラフト PR #M がある場合は、その計画が古くなったことを引き継ぎ時に伝え、引き継ぎの文言を「ドラフト PR #M を閉じてから、新しいセッションで issue-to-plan #N を実行してください。」とします。PR や計画を自分で編集したり、閉じたりしてはいけません。

同じセッションでのビルド

ユーザーが依頼した場合、issue のビルド手順に従って、クイックタスクまたは小規模な変更をこのセッションでビルドできます。ビルドの開始が承認になります。プロジェクトは対象外です。新しいセッションで issue-to-plan #N を実行するよう案内します。

分割

v7 で独立したプロジェクトが複数見つかり、実行順序に合意した場合は、それぞれに [DRAFT] issue を作成し、各 issue に Split: 行を記載して、1 つずつブレインストーミングします。引き継ぎ後に次の兄弟 issue を提案します（ユーザーは中断し、brainstorming-to-issue #next で再開できます）。兄弟 issue 間に実際のビルド依存関係がある場合は、各設計に制約として記載します。65k 制限に対応するために本文を分割する場合は、ユーザーの同意を得ます。

ガードレール

• GitHub issue の操作には gh のみを使い、リポジトリから実行します。--repo は使いません。
• 記録済みの内容を短縮、削除、言い換えしてはいけません。本文が 65,536 文字に近づいた場合は、ユーザーに分割を依頼します。