brainstorm

ブレインストーミング

生のアイデアを、対話を通じて仕様作成に進められる合意済みの形に整えます。コードは書きません。

この段階の位置付け： brainstorm → (write-requirements → write-design → write-plan) → execute-plan。現在は最初の段階である brainstorm です。後続のどの段階を実行するかは、ステップ 5 のティアによって決まります（ティア 0 は tdd に直行し、ティア 1 は write-requirements でミニ仕様を作成して終了し、ティア 2 のみが 3 つの段階すべてを進みます）。それぞれの段階は独自の ToDo リストを管理し、実行時に作成します。このスキルのリストに、それらのステップをあらかじめ追加しないでください。

仕様がまだない新しい機能やプロジェクトの具体化には、このスキルを使います。すでにリリース済みで仕様もある機能への、小規模かつスコープ内の変更には、代わりに amend を使います。これは既存の仕様を読み、変更を簡易レーンに進め、変更が本当に新しいスコープである場合にのみ、ここへ戻して対応します。そのような変更を依頼された場合は、amend に引き継いでください。

このチェックリストを実行し、セレモニーのティアを声に出して伝えるまでは、コードを一切書かず、スキャフォールドを一切作成せず、実装スキルを一切呼び出さないでください。ティア 0 で許可される唯一の終了先は `tdd` であり、ティアを伝えた後に限ります。ティアが 1 以上の場合は、まず要件を作成して承認を得てください。このスキルが触れてよい成果物は、メモ、用語集（CONTEXT.md）、ADR、ロードマップ（`docs/roadmap/INDEX.md`。ステップ 5 で `write-roadmap` を通じてのみ）、およびサブスキルを介した調査メモと、明示的に使い捨てと指定したプロトタイプに限られます。これは、どんなに簡単に見える依頼にも例外なく適用されます。

「設計するほどでもないほど簡単」という落とし穴

小さな依頼こそ、検討されていない前提が最も多くの手戻りを生みます。確認する手間を誰もかけないためです。成果物はごく小さくてもかまいません。ティアの決定と 3 文だけでもよいのです。しかし、プロセスは毎回実行します。

考え	実際
「これは一行で済む。設計するのは余計な手間だ」	ティア 0 と判断すること自体が設計のステップです。そのことを明確に述べて先へ進んでください。判断を省くことが余計な手間になります。
「ユーザーは何を作るべきか、すでに正確に伝えている」	伝えられたのは解決策です。問題、制約、動作し続けなければならないことは、まだ確認できていません。
「考えを整理するために、少しコードを書いてみよう」	それはプロトタイプです。誤って本番コードになるのではなく、契約上使い捨てとなるよう、prototype サブスキルを実行してください。
「アプローチがコンパイルできると確認してから要件を書こう」	コードを先に書くのはゲートの順序を逆転させています。証拠が必要な質問には、調査やプロトタイプで対応します。要件が先です。
「スキャフォールディングは実装というほどではない」	リポジトリの骨組み作成は、承認を得ずに技術スタックを決定して実行することです。これは実装です。
「十分に話し合ったので、答えはほぼ分かっている」	承認済みの requirements.md に記載されていなければ、このチャットにしか存在せず、チャットが終われば失われます。
「他のサブ機能は今はスコープ外なので、Out-of-Scope に記載するのが適切だ」	Out-of-Scope と ADR は、却下を記録するものです。後で取り組む予定の作業は、write-roadmap でマイルストーンとして先送りしてください。却下すると、たった今立てた計画を壊すことになります。

危険信号 — 次のような自分に気付いたら、いったん止まりチェックリストに戻ってください：「ちょっと試すだけ」とエディターを開く、ジェネレーターやスキャフォールダーを実行する、質問せずに自分で未解決の問いに答える、1 つのアプローチを唯一の選択肢として提示する、聞き取りから実装へと逸れていく。

チェックリスト

最初に Todo — GATE。 ブレインストーミングのたびに、最初に行うことは、CONTEXT.md を読む前、スキャンを依頼する前、質問を一つでもする前に、Todo リストを作成することです。以下のチェックリスト項目（ステップ 1〜6）ごとに Todo を一つ作成し、実行環境の Todo ツール（Claude Code の TodoWrite、Kimi、Codex、または実行環境に応じた同等のツール）を使ってください。これは、どれほど簡単に見えるリクエストでも必ず実行します。上記の HARD-GATE は、してはならないことです。これが、最初に必ず行うことです。このリストには、このスキルの 6 つのステップだけを含めてください。後続のステージ（write-requirements、write-design、write-plan）は追加しないでください。引き継ぎ時に各ステージで独自のリストが作成されます。リストができるまで先に進まず、各項目の 完了条件 を満たしたときにのみチェックを付けて、順番に完了してください。

早い段階でティアを判断し、規模を適切に調整します。 ステップ 1 でコンテキストを把握したら、暫定的なティア判断を行います。

• 明らかにティア 0 — 動作変更がなく、未確認の前提も守るべき対象もない、誤字、色の変更、ラベル、文言の編集の場合 → ステップ 2 は簡潔に行い、ステップ 3〜4 は省略して、ステップ 5 に進みます。
• それ以外 — 動作変更、不明点、または実質的な設計上の選択がある場合 → 通常のフローに進みます。

暫定判断はあくまで暫定です。ステップ 2 で上記のいずれかが明らかになった場合、それはそもそもティア 0 ではありません。通常のフローに切り替えてください。

1. プロジェクトのコンテキストを調査する

CONTEXT.md（以降はここに記載された用語を使ってください）と docs/specs/INDEX.md（既存の機能コードと仕様）を直接読みます。どちらも小さなファイルなので、コンテキストとして把握しておく必要があります。docs/agents/project.md がある場合は、その Project posture を読みます。提供意図とライフサイクルの段階に応じて、ヒアリング全体の規模を適切に調整してください。Prototype / Research / Learning の方針では、データ移行、後方互換性、非推奨化のコストについて質問に時間をかけないでください。Released / Scaling / Maintenance の方針では、これらを特に重視してください。方針のセクションがない場合は、方針を推測せず、規模の調整なしで進めます。同じファイルに ## Team がある場合は、roster が空でないか、Workflow band のオーバーライドが設定されているとき、同セクション内のルールとマトリックスに基づいて band を導き、packaging を適用してください（ここでルールやマトリックスを再掲しないでください）。band は一度だけ伝えてください。Solo の場合、アプローチではピア間の調整に関する記述を簡潔にします。Small/Multi の場合、アプローチのトレードオフで、オーナーシップとレビュー能力を明示します。roster が空でオーバーライドも空欄の場合、または Team が存在しない場合は、チームを勝手に想定したり、ハードフェイルしたりしないでください。Band によってティアのルールや Iron Laws が変わることはありません。 docs/product/vision.md がある場合は、それも読み、アイデアを理解したうえで、明示された製品スコープに含まれるかどうかを伝えてください（スコープ外のアイデアは、仕様作業の前に指摘する価値があります）。ファイルがない場合は、このレイヤーは任意なので省略します。このアイデアに関するコード、ドキュメント、最近のコミットなど、より広範な調査が必要な場合は、スキャンサブエージェントを起動して調査を行い、調査結果の要約を .skills/<slug>-scan.md に書かせます（アイデアに関連する既存の要素、関係するファイルや接点、適用される制約を記載します。調査結果であり、ファイルのダンプではありません）。サブエージェントからはそのパスだけを返させ、元ファイルをこの会話に読み込まず、要約をもとに作業してください。（この実行環境にサブエージェントがない場合は、関連するファイルを少数だけ直接読みます。）docs/agents/project.md またはこれらのファイルが見つからない場合は、その旨を伝え、setup-repo の実行を提案してから、手元にある情報で続けてください。

スキャンの要約（または直接読み込んだ内容）には、必ず Blindspot セクションを含めてください。そこには、このリポジトリに根差した、領域固有の落とし穴、過去の制約、新参者には思いもよらない質問を記載します。一般的なアドバイスではなく、このリポジトリに基づく内容にしてください。ユーザーがモジュールや領域について詳しくないと示した場合は、ステップ 2 の最初の希望確認質問をする前に、その Blindspot の一覧を伝えてください。 次に、そのアイデアがすでに存在するか確認します。docs/specs/ を検索し、候補となる機能コードと主要な用語を requirements.md ファイル全体で検索して、重複がないか調べます。スキャンで見つかった候補ファイルパスを、既存の仕様がすでに所有しているパス（design.md／tasks.md でそのパスを検索）と照合してください。一致するものがあれば、該当する仕様全文ではなく、近接する仕様の要約 カード を提示します。その機能コード、所有するパス、対象外リストから、すでにカバーされている範囲が分かります。まず docs/specs/INDEX.md で一覧を確認してください。これはゲートを妨げるものではありません。重複がなければ、その旨を伝えて先に進みます。docs/specs/ がまだ存在しない場合は、その旨を記して手動での調査を続けてください。

既知事項の一覧（ステップ 2 の前に必須）。 後続の一連の作業で再利用できるよう、短い箇条書きを 4 つ作成してください（チャットで構いません。任意で .skills/<slug>-knowns.md に記録できます）。

• 既知の既知事項／確定事項 — 確定した厳格な制約と結果（維持必須の動作、方針上の制約、明示された譲れない条件）。
• 既知の未知事項 — 調査、プロトタイプ、またはユーザーの判断が必要な未解決の質問。
• 未知の既知事項 — ユーザーは好みや基準を認識できるものの、まだ言語化できていない事項（文章で質問を重ねるだけではなく、prototype や参考資料を通じて明らかにします）。
• 前提（確定事項ではない） — ユーザーが提案した解決策の形で、領域（コードベース、API、履歴）に照らして確認されるまでは仮説にすぎないもの。前提を、選択されて確定事項になる前に、必須要件としての SHALL に昇格させてはいけません。

完了条件： プロジェクトの内容、このアイデアに近接する既存のもの、該当する用語集の用語について、1 段落で説明できる状態になっていること。また、既存機能のうち、このアイデアと同じ領域を共有するものと新しいアイデアの違いを機能コードを挙げて説明するか、同じ領域を共有する既存機能はないと明示していること。さらに、既知事項の一覧と盲点リストが存在すること。

2. インタビュー

これは引き続きブレインストーミングのステップ 2 です。ステージの引き継ぎではなく、新しいスキルセッションでもありません。 単一の質問チャネルには grilling プロトコルを適用し、このスキルの ToDo リストを継続して使ってください。競合するリストを作成したり、「grilling に切り替える」と再度宣言したりしないでください。

プロトコル（常時適用）： このステップでは、最初から最後まで grilling を適用します。チャネル、未解決事項がなくなるまで続けるルール、詳細なカード項目、終了時のパッケージを含みます。この段落をもとに、簡略化したインタビューを独自に作らないでください。カードの作成手順と終了ルールは grilling のみに記載されています。

必須サブスキル：全ルール（チャネルに関する絶対ルール、未解決事項に関する絶対ルール、詳細な質問カードの作成手順、実装前のインタビューマップ、終了時のパッケージ、方針の絞り込み、チーム規模に応じたパッケージ化、実行しないゲート、入れ子の ToDo 契約）について、grilling を使用してください。このステップの開始時に、まだコンテキストにない場合は一度読み込み、その後はこのチェックリストに沿って進めてください。

（初期確認では暫定的にティア 0 ですか？ 適切な規模に調整してください。問題、1 つの制約、そして維持必須の動作を 1、2 問で確認し、意思決定ツリー全体をたどらないようにします。新しい情報が何も出てこなければ、ステップ 5 に進んでください。）

インタビュー全体を通じて、domain-modeling を受動的なサイドエフェクトとして有効にしておきます。用語が確定したら直ちに CONTEXT.md に記録し、コードへの相互参照を追加してください。ただし、2 つ目の質問チャネルは開きません。ユーザーへの確認が必要な用語（異議の提示、曖昧さの解消、エッジケースの確認）は、割り込みを別途行うのではなく、インタビュー内で一度に 1 つずつ進める質問の次の項目にしてください（必須サブスキル：domain-modeling を使用）。

詳細を掘り下げる前に、スコープを確認してください。依頼が複数の独立したサブシステムにまたがる場合、詳細化を止め、先に分解してください（ステップ 5）。

完了条件： 大きな影響を及ぼしうる判断事項が未解決事項に残っておらず、grilling の終了時パッケージが確認されていること。

3. 質問に意見ではなく根拠が必要な場合は、迂回する

フルパスのみ。tier 0 ではこの手順をスキップします。

好みだけでは答えられない質問もあります。正直に「確認が必要です」と答える場合は、次のとおりです。

• 外部システム、API、ライブラリ、標準規格に関する事実 → 必須サブスキル：research を使用します（一次情報に基づき、出典を示したメモを作成します。トレーニングデータのカットオフ時点の記憶ではなく、Context7 MCP を利用して、最新かつバージョンに即したライブラリの情報を確認します）。
• 「このモデル／フローは実際に適切に感じられますか？」→ 必須サブスキル：prototype を使用します（実行可能な使い捨ての回答）。

根拠を得たらインタビューに戻り、判断をユーザーに委ねます。

完了条件： 推測で回答している保留中の質問がないこと。

4. アプローチを提案する

フルパスのみ。tier 0 ではこの手順をスキップします。

トレードオフが明確に異なるアプローチを2〜3案提示します。推奨案とその理由を最初に示します。YAGNI に基づいて各案を絞り込みます。ユーザーが選択します。

完了条件： ユーザーがアプローチを選んでいること（複数案を組み合わせたものでもかまいません）。

5. 儀式のティアを明示して決める

ティアとその理由を明確に述べます。

ティア	該当する場合	その後の手順
0	タイポレベルで、動作変更がない	仕様なし — そのまま tdd へ
1	動作変更が半日以内で済む程度	ミニ仕様：該当する requirements.md に REQ と SHALL-CONTINUE-TO ガードを追加
2	複数タスクにわたる機能	requirements → design → plan の3点セットを作成

作業が複数の独立したサブシステムにまたがる場合は、ここで分解します。サブ機能、その相互関係、実装順を明示してください。各サブ機能に、それぞれ完全な仕様作成サイクルを設けます。

サブ機能が2つ以上ある場合は、先に進む前に分解内容を書き残す必要があります。 必須サブスキル：write-roadmap を使用し、すべてのサブ機能を ROAD-N 項目として記録します。docs/roadmap/INDEX.md がすでに存在する場合は追記し、存在しない場合は新規作成します。最初に実装しないサブ機能は、却下ではなく後続マイルストーンに延期します。Out-of-Scope の記述や ADR は「却下」を記録するものであり、分解は却下ではありません。その後、最初の項目だけを続けます。

完了条件： 「これは tier N です。理由は……」と述べていること。分解した場合は、各サブ機能が docs/roadmap/INDEX.md の ROAD-N として記録され、最初に着手する項目を明示していること。

6. 終了時の状態

• Tier ≥ 1： 必須サブスキル：write-requirements を使用します。これだけが終了への道筋です。コードを書いたり、スキャフォールドを作成したり、実装または設計スキルを直接呼び出したりしないでください。まず requirements を作成し、requirements 自体の承認ゲートを通します。
• Tier 0： ティアを述べたうえで、必須サブスキル：tdd を使用します。

完了条件： write-requirements が呼び出されている（tier ≥1）か、tier 0 への引き継ぎが明示されていること。