jackin-brainstorm

jackin-brainstorm

既存のロードマップ項目の意図と、収集済みの調査内容があればそれも踏まえ、オペレーターとの自由なやり取りを通じて具体的な設計上の決定を行い、項目の ## Design セクションに段階的に書き込みます。

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

使用する場面

• オペレーターが、未着手のロードマップ項目を設計するために jackin-brainstorm <slug> を実行します。

使用しない場面

• 項目の作成 → jackin-propose。
• 大規模な外部調査やコードベース調査 → jackin-research。
• 実装 → /goal Implement <slug>.md。

引数

• --research — 項目の情報が不足しているようであれば、先に jackin-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-research の調査資料を作成し、## Design からリンクします。その後、決定の議論を再開します。
5. 方針を固めます。 ## Design でアプローチ全体が網羅されたら、内容を要約し、実装の手順（/goal Implement <slug>.md）を案内します。
6. コミットしてプッシュします。 まとまった単位ごとに docs: でコミットし、コミットのたびにプッシュします。

よくある間違い

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