brainstorm

ブレインストーミング

既存のロードマップ項目の意図（および収集済みの調査結果）を、担当者との自由なやり取りを通じて具体的な設計上の決定に落とし込み、項目の ## Design セクションに段階的に記述します。

判断を行うタスクです。説明して決定するものであり、スクリプトを作成したり、コードを書いたり、作業をタスクに分割したりしないでください（それは plan の役割であり、ここでは扱いません）。

使用する場面

• 担当者が /jackin-dev:brainstorm <slug> を実行し、未対応のロードマップ項目を設計する場合。

使用しない場面

• 項目を作成する場合 → /jackin-dev:propose。
• 大規模な外部調査またはコードベースの調査を行う場合 → /jackin-dev:research。
• 実装する場合 → /goal Implement <slug>.md。

引数

• --research — 項目の情報が不足しているようであれば、まず /jackin-dev:research を実行します。
• --resume — 現在の ## Design の状態から続行します。

プロセス

1. コンテキストを読み込む。 docs/content/docs/roadmap/<slug>.mdx の Problem、Why It Matters、Design-so-far、Related Files と、すでにリンクされている調査資料を読みます。
2. 自由形式で話し合う。 自由なやり取りを通じて、選択肢、トレードオフ、未解決の質問を提示します。制約として、jackin' の設計原則と関連するルールファイル（ENGINEERING.md、HOST_AND_CONTAINER.md、TUI／ドキュメントのルール）を参照します。質問は一度に1つを基本とし、各項目が固まるたびに確認します。
3. 段階的に書き込む。 各ポイントが固まったら、その決定と一行の理由を .mdx の ## Design 内の該当箇所に追記または更新します。--resume を指定すると、そこから再開します。
4. 不明点が出た場合。 すばやく情報を集めます（Explore／grep、または deep-research）。大規模な調査の場合は、別途 /jackin-dev:research で調査資料を作成し、## Design からリンクします。その後、決定を続けます。
5. 結論をまとめる。 ## Design でアプローチを最初から最後まで網羅できたら、要約し、実装のステップ（/goal Implement <slug>.md）を示します。
6. コミットしてプッシュする。 固まった内容のまとまりごとに docs: でコミットします（コミットのたびにプッシュします）。

よくある間違い

• コードを書く、または ## Tasks を埋める（対象外です）。
• 自由なやり取りをせずに完成した設計を一気に書き込む、または一度に多くの質問をする。
• 決定事項を ## Design ではなくチャット内にだけ記録する（再開できる状態にしておく必要があります）。
• ルールファイルの内容を繰り返し記述し、ファイル名での参照にしない。