brainstorming — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited brainstorming (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
本プロジェクトの開発ワークフロー (docs/workflow.md) における起点ステージです。ユーザーの曖昧な要望を質問の往復で深掘りし、次の Spec ステージで仕様を書ける状態まで解像度を上げることが役割です。
用語: 「Project Phase」「Workflow Stage (ステージ)」「Release Phase」「Spec」の定義は docs/glossary.md を参照してください。本 skill 内では Workflow Stage を「ステージ」、ユーザープロジェクトのリリース段階 (MVP / Phase 2 等) を「Release Phase」と表記します。
本 skill はワークフローの最上流に位置します。後続のすべてのステージ (Spec → Spec Review → Isolate → Plan → Implement → Verify → Code Review → ship → Learn) は、本ステージの出力である Brainstorming ノートを起点として進みます。
設計原則: ヒアリングを飛ばして Spec ステージに直接進むことは禁止です。曖昧な要件のまま Spec を書くと、Plan / Implement / Code Review すべてが手戻りするため、本 skill を起点として固定化します (docs/workflow.md 設計原則 6 参照)。
以下のような自然言語のフレーズで自動的に起動してください。
ユーザーが上記のような着手意図を示した時点で、本 skill を起動し、ヒアリングを開始します。すでに Spec ファイル (specs/<spec-name>.md) が存在する場合は本 skill をスキップし、Spec Review ステージに進んでください。
本 skill 起動中に以下を行ってはいけません。
特に「これは簡単だから設計不要」という判断は、後続ステージで必ず手戻りを起こすため明確に禁止します。
以下の順序でユーザーと対話してください。各項目で十分な解像度が得られるまで、追加質問を続けます。
各項目を機械的に質問するのではなく、ユーザーの発話から明らかになった項目はスキップし、未解明の項目を優先的に質問してください。
ヒアリングの軸として以下のカテゴリを参照してください。
| カテゴリ | 代表的な質問例 |
|---|---|
| 目的 | 「この機能で何を実現したいですか」「現状の何が不便ですか」 |
| 利用者 | 「誰が使いますか」「使う頻度はどれくらいですか」 |
| 成功条件 | 「完成したと判断する基準は何ですか」「動作確認はどう行いますか」 |
| 制約 | 「既存のどの部分に影響しますか」「期日はありますか」「使える技術スタックの制限はありますか」 |
| スコープ | 「今回含めない機能はありますか」「将来的に拡張予定の機能は何ですか」 |
| 代替案 | 「他に思いついたアプローチはありますか」「既存ライブラリで代替できませんか」 |
| リスク | 「何が起きると困りますか」「失敗パターンを想定していますか」 |
ヒアリングが完了したら、以下のフォーマットで specs/<spec-name>.brainstorm.md を作成してください。<spec-name> はユーザーと相談して決定したケバブケースの名前 (例: add-user-login, fix-payment-bug) を使います。
---
name: <spec-name>
created: YYYY-MM-DD
status: brainstorming-complete
---
# Brainstorming: <spec-name>
## 目的
<なぜこの作業をするのか、解決する問題>
## 利用者
<誰が使うのか>
## 成功条件 (受け入れ基準)
- <条件 1>
- <条件 2>
## 制約
- <技術的制約>
- <時間的制約>
- <既存システムへの影響>
## スコープ
### 含むもの
- <項目 1>
### 含まないもの (明示的に除外)
- <項目 1>
## 代替案の検討
- <検討した代替案 1 と却下理由>
- <検討した代替案 2 と却下理由>
## リスク
- <想定されるリスク 1 と対策方針>
## 未解決事項
- <Spec ステージで決定する事項>
## ヒアリングログ (任意)
<重要なやり取りの抜粋>ファイル配置先は specs/<spec-name>.brainstorm.md です。specs/ ディレクトリが存在しない場合は新規作成してください。worktree 内ではなく、main ブランチ側に配置します。
以下を すべて 満たした時点で本 skill を完了とします。
specs/<spec-name>.brainstorm.md に保存されているユーザー承認なしに自動で次のステージへ遷移してはいけません。承認を得るための問いかけは「以上の内容で Spec ステージに進めますがよろしいですか」のように明確に行ってください。
完了判定を満たしたら、以下の引き継ぎを行います。
writing-spec skill (Phase 3 で実装予定) を起動する旨を伝えるwriting-spec skill 未実装の Phase 3 着手段階では、引き継ぎは口頭での合意で代替し、Brainstorming ノートのパスをユーザーに提示するに留めます。
ヒアリング中にユーザーが要件を確定できない、あるいは前提条件を見直す必要が生じた場合、無理に Brainstorming ノートを作成せず、以下のいずれかを提案してください。
ユーザーの判断を待ち、無断で進行しないでください。
ヒアリングを進めるうちに、要件が単一 Spec として扱うには大きすぎると判明する場合があります。そのまま 1 つの Spec として進めると Plan / Implement ステージで破綻するため、分割を積極的に提案 してください。
以下のうち 2 つ以上 に該当した時点で、ユーザーに分割を提案してください。
判定は硬直的に行わず、上記基準を「分割すべきかの思考補助」として使ってください。ユーザーが「これは絶対に 1 Spec で進めたい」と主張する場合は理由を確認した上で尊重します。
分割を提案する際は、以下の軸から 2〜3 個の候補 を提示し、ユーザーと選定してください。
| 軸 | 分割例 | 向いているケース |
|---|---|---|
| 機能単位 | auth, payment, admin-dashboard | 独立性の高い複数機能を同時に作るケース |
| Release Phase 単位 | mvp, phase2-polish, phase3-scale | MVP → 拡張の段階的開発 (docs/glossary.md の Release Phase 定義参照) |
| データ単位 | user-schema, product-schema, order-schema | データモデル中心の作業 |
| 層 (垂直/水平) | ui-layer, api-layer, data-layer | フルスタック機能で層ごとに責務を分けたいケース |
複数軸を組み合わせる必要がある場合 (例: 機能単位 × Release Phase 単位) はその旨も提示してください。
以下の順序で必ずユーザー承認を得てから複数ノート生成に進んでください。
ユーザーの明示的な承認なしに複数ノートの生成を開始してはいけません。
分割後の Brainstorming ノートは、共通接頭辞を使って関連性を示します。
specs/<project>-<feature>.brainstorm.mdspecs/ecsite-auth.brainstorm.md, specs/ecsite-payment.brainstorm.md, specs/ecsite-admin.brainstorm.mdspecs/<project>-<release-phase>.brainstorm.mdspecs/ecsite-mvp.brainstorm.md, specs/ecsite-phase2.brainstorm.mddepends_on フィールドを追加depends_on: [ecsite-auth]単一 Spec 時のテンプレート (セクション 6 参照) に加え、分割時は以下を必ず含めてください。
本プロジェクトのワークフロー (docs/workflow.md) では、複数 Spec の並列実行は Phase 5 で実装される orchestrator skill が担当します。Phase 3 の時点では分割後の各 Spec を順次手動で進めることになりますが、Brainstorming ノート段階で依存関係 (depends_on) を明記しておくことで、Phase 5 の orchestrator がそのまま DAG 解決に利用できます。
未来の自動化を意識し、依存関係は必ず記述してください。
ヒアリング項目の中には、ユーザーへの質問だけでは引き出せない情報や、ユーザーが忘れている / 知らない情報があります。AI が能動的にコードベースを読めば数秒で判明する事項を、何往復もして質問するのは非効率かつ不正確です。本 skill では コードベース精査を 2 段階で行う ことを必須とします。
skill 起動直後、ヒアリングを開始する前に、以下を必ず実施してください。
ls または Glob でトップレベルのファイル / ディレクトリを取得)CLAUDE.md (プロジェクトルール)README.mdpackage.json / pyproject.toml / Cargo.toml / go.mod 等のマニフェストdocs/ 配下の主要ドキュメントspecs/ ディレクトリ確認 (関連する過去の Brainstorming ノート / Spec の存在確認)これにより、技術スタック・プロジェクトの種類・既存のルール・関連する過去の作業を把握します。把握した情報はヒアリング質問の精度向上に使い、「Node.js プロジェクトと判明したので React か Vue かのみ確認」のように 質問を絞り込んでください。
ヒアリングが進み、要件のキーワード (例: 「認証」「在庫」「メール送信」) が見えてきた段階で、関連コードを能動的に検索してください。
Grep)Grep で auth, login, session, JWT 等を検索Grep で inventory, stock, quantity 等を検索Read)git log)精査結果を踏まえ、ヒアリング項目を更新します。コードから判明した事項は ユーザーに質問せず、推測内容を提示して確認を求める形にしてください (例: 「既存の MailSender クラスを再利用する想定で良いですか」)。
精査結果は Brainstorming ノートの該当セクションに反映してください。
リポジトリが空、または README.md のみ存在する場合、深スキャンはスキップしてください。軽スキャンのみ実施し、Brainstorming ノートに「新規プロジェクトのため精査対象なし」と明記します。
以下の場合は精査範囲を絞ってください。コンテキスト枯渇と精査時間の浪費を避けるためです。
Phase 5 で investigator agent の役割を「Plan ステージ専用」から「Brainstorming + Plan 両ステージで使用」へ拡張する予定です。Phase 3 の時点では本 skill 内で精査を完結させますが、将来は重い精査を investigator agent に委譲することで、本 skill の責務を「ヒアリング進行」に集中させる設計に移行します。
そのため、Phase 3 の精査実装も「将来 investigator に委譲できる粒度」を意識してください。具体的には、精査ステップを「軽スキャン」「キーワード検索」「ファイル読み込み」「テストパターン確認」「commit 履歴確認」のように独立した手順として記述し、agent に切り出しやすい構造にします。
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.