| name | brainstorm |
| description | ユーザーから投げられたアイデア・テーマを docs/ideas/<group>/<topic>/ フォルダに 「複数選択肢を並べる・採否を決めない・実装は考えない」方式で ブレインストーミング展開するスキル。レビュー前のアイデア整理用。 以下の場面でトリガーする: - 「ブレスト」「ブレインストーミング」「アイデアを整理」「アイデア化」と言われたとき - 「色々な選択肢を考えて」「網羅的に並べて」「いっぱい案を出して」と言われたとき - 「docs/ideas/に入れて」「idea化」「実行に移せる程度に詳細化された設計を作って」と言われたとき - ユーザーが新しいテーマや機能アイデアを投げてきて「フォルダ作って」「整理して」と言うとき - 「採用するかは決めない」「実装は考えない」前提で考えてほしいと言われたとき
|
brainstorm — docs/ideas/ ブレスト展開スキル
ユーザーの思いつきを docs/ideas/<group>/<topic>/ フォルダに展開する。
採否は決めない・実装詳細は決めない・複数案を並べる が大原則。
レビュー前のアイデアプール段階。後でユーザーが選択肢から選んで実装方針を確定する。
いつ使うか
- 新しい機能アイデアや概念を整理したい
- 「決めずに広く考えたい」段階
- 後でレビューする前提で網羅性を優先したい
- 複数のテーマを横断的に並べたい
逆に 使わない 場面:
- 既に方針が決まっている実装タスク（普通にコードを書く）
- 短い思いつきメモ（
tomd skill を使う、または m3e-scratch skill）
- 即座にマップに残したいだけのアイデア（
m3e-scratch skill）
出力構造
docs/ideas/<group>/<topic>/
├── README.md # 索引 + 全体俯瞰 + 論点一覧
├── 01_<theme>.md # 第一の切り口（コンセプト/ユースケース等）
├── 02_<theme>.md # 第二の切り口（実装方式の選択肢）
├── 03_<theme>.md # 第三の切り口（UI/体験のバリエーション）
├── 04_<theme>.md # 第四の切り口（データ/永続化）
└── 05_<theme>.md # 最終ファイル（MVP/未決質問/戦略）
<group> は 必ず以下のメタフォルダのいずれか を選ぶ:
| メタフォルダ | 守備範囲 | 既存トピック例 |
|---|
00_meta/ | M3E 自身に関するメタ機能・自己改善・自動化障害 | meta_m3e, automation_obstacles |
10_io/ | 入出力・取り込み・公開・外部ツール統合 | capture_ingest, export_publish, tool_integration |
20_ai/ | AI エージェント・LLM 連携・思考パートナー | ai_agent_deep |
30_ux/ | UI・操作・可視化・体験・ゲーム化 | slideshow, keyboard_modes, map_views, gamification |
40_data/ | データ・履歴・性能・整理・スケール | maintenance_hygiene, time_history, performance_scale |
50_collab/ | 協調・デバイス連携・セキュリティ・プライバシー | collaboration, cross_device, privacy_security |
60_workflow/ | 研究・学習・生産性・教育プロセス | personal_productivity, cognitive_science, education |
70_concept/ | 思想・哲学・隠喩・実験的コンセプト | thought_physics, philosophical |
新ブレスト開始時に必ずメタフォルダを判定する（鉄則 0）。
複数候補がある場合は最も中心的なものを選び、その判断理由を README に 1 行残す。
どこにも収まらない新領域なら、新メタフォルダ追加をユーザーに提案する（自動で増やさない）。
ファイル数の目安: 5〜8ファイル（README含む）。
1ファイル500〜2000行程度。短すぎず長すぎず。
標準テンプレート
過去事例で実証済みの構成パターン:
Pattern A: 機能アイデア展開（slideshow 型）
01_concept.md — 何か、なぜ、ユースケース、既存ツール差分
02_options.md — 実装方式の選択肢（決めない）
03_runtime_ui.md — UI / 体験のバリエーション
04_data_model.md — データモデル / 永続化 / 互換性
05_mvp_path.md — 最小実装案 + 未決質問 + 段階導入ロードマップ
Pattern B: 候補列挙型（keyboard_modes / map_views 型）
01_global_design.md — 共通論点（命名規約・分類軸）
02_<group1>.md — グループ1 の候補列挙
03_<group2>.md — グループ2 の候補列挙
...
N_implementation.md — 横断: 共通基盤・優先順・実装方針
Pattern C: 障害分析型（automation_obstacles 型）
01_obstacles.md — 問題の網羅的分類
02_solution_patterns.md — 解決パターンの抽象化
03_pairs.md — 障害 × 解決のマトリクス
04_what_not_to_do.md — やらない領域・反例
05_strategy.md — M3E（or 対象）の介入戦略
テーマに応じてどのパターンを採用するか判断する。
迷ったら Pattern A から。
書き方の鉄則
鉄則0. メタフォルダを先に決める
新ブレストを始める前に上表からメタフォルダを 1 つ選ぶ。
判断に迷ったら推し 1 個 + 候補 2 個を README に残し、ユーザー確認を待たずに推しで配置。
（後で git mv すれば動かせるので、止まらない）
鉄則1. 採否を決めない
「推し: B3」のような軽い見立てはOK。
ただし「B3 で確定」「他は不採用」とは書かない。
全選択肢を後から見直せる状態を保つ。
鉄則2. 実装詳細を決めない
「~50行で書ける見込み」程度のボリューム感はOK。
コード片や具体ファイル設計は最後の MVP ファイルだけに留める。
鉄則3. 論点 ID を打つ
各論点に A1. B2. Md1. などの ID を付ける。
ユーザーが後で「論点 B3 を採用して」と1ID指定で選べる構造にする。
鉄則4. ユースケースを具体化
抽象論を避け、「誰が」「いつ」「どんなシーン」を最低3〜5個挙げる。
研究者向けなら研究シーン、開発者向けなら開発シーンに即す。
鉄則5. 比較表を多用
複数選択肢は表形式（Markdown table）で並べる。
| 案 | 良い点 | 悪い点 | 推し度 | のような列構成。
鉄則6. 横断的気づきを末尾に
最終ファイルには「組み合わせの相性」「共通パターン」「優先順位」など
ファイルを横断する観察 を入れる。
鉄則7. 既存事例・既存メモリと接続
m3e-map.json の既存ノード構造docs/ backlog/ の既存ドキュメントMEMORY.md の既存メモリ（project_, feedback_）- 既存のフォルダ（docs/ideas// 内の他ブレスト、特に同じメタフォルダ内）
これらと矛盾しない、または接続できる形で書く。
鉄則8. README に論点一覧
README 末尾に「論点 A〜K」のような一覧を置き、
ユーザーが論点 ID 単位で選択肢を選べるようにする。
ファイル名規約
- メタフォルダ名:
NN_<group>/（NN は 00/10/20/.../70 の刻み、増やす場合は中間 05/15 等を使う）
- トピックフォルダ名: snake_case（既存例
keyboard_modes, map_views, automation_obstacles に合わせる）
- ファイル名:
NN_<theme>.md（NN は2桁ゼロパディング）
- ファイル順序が意味を持つ（読む順）
README の標準構成
# <Topic 日本語タイトル>
<1〜2文の概要>
> メタフォルダ: `docs/ideas/<group>/` （配置理由を 1 行）
## 方針
- 採用判断はしない
- 実装は考えない
- 複数案を並べる
- ...（テーマに応じた追加方針）
## ファイル構成
- [01_xxx.md](01_xxx.md) — 一行説明
- [02_xxx.md](02_xxx.md) — 一行説明
...
## 全体俯瞰 / 論点一覧
<表 or 箇条書きで全体マップ>
## 関連ブレスト（任意）
- `docs/ideas/<group>/<other_topic>/` — 一行関係性
## キーメッセージ（任意）
<このブレストの結論的観察、3〜5項目>
動作手順
- ユーザー入力を解析 — テーマ・スコープ・制約を抽出
- 既存 docs/ideas/ を確認 — 同じメタフォルダ内に近いテーマがないか軽くチェック
- メタフォルダ判定（鉄則 0） — 上表から 1 つ選ぶ
- パターン選択 — A/B/C どれが合うか判断
- トピック名決定 — snake_case でフォルダ名を決める
- ファイル一覧設計 — 5〜8ファイルの構成案を作る
- README から書く — 構成と論点一覧、メタフォルダ配置理由を先に固める
- 各ファイル順次書く — 並列に書ける場合は並列
- 最後に横断観察 — 最終ファイルに「気づき」をまとめる
- ユーザーに簡潔報告 — ファイル一覧（メタフォルダ込みパス）とキー論点 3〜5個
ユーザー応答テンプレ
ブレスト完了時の応答は、長すぎず短すぎず:
`docs/ideas/<group>/<topic>/` に N ファイル構成でまとめました。
- [README.md](docs/ideas/<group>/<topic>/README.md) — 索引と論点一覧
- [01_xxx.md](docs/ideas/<group>/<topic>/01_xxx.md) — <1行説明>
- ...
- [0N_xxx.md](docs/ideas/<group>/<topic>/0N_xxx.md) — <1行説明>
**主要な気づき**:
- <観察1>
- <観察2>
- <観察3>
**最重要の未決**:
- <未決1>
- <未決2>
過去ブレストの参照
実例として既に存在するブレスト（メタフォルダ込みパス）:
docs/ideas/30_ux/slideshow/ — 機能アイデア展開（Pattern A）の典型例docs/ideas/30_ux/keyboard_modes/ — 候補列挙＋共通基盤（Pattern B）の典型例docs/ideas/30_ux/map_views/ — 100候補列挙の大規模 Pattern Bdocs/ideas/00_meta/automation_obstacles/ — 障害分析（Pattern C）の典型例docs/ideas/00_meta/meta_m3e/ — メタ機能（Pattern A）docs/ideas/10_io/capture_ingest/ export_publish/ tool_integration/ — 入出力系docs/ideas/20_ai/ai_agent_deep/ — AI 深化docs/ideas/40_data/maintenance_hygiene/ time_history/ performance_scale/ — データ系docs/ideas/50_collab/collaboration/ cross_device/ privacy_security/ — 協調系docs/ideas/60_workflow/personal_productivity/ cognitive_science/ education/ — 研究プロセス系docs/ideas/70_concept/thought_physics/ philosophical/ — 概念系docs/ideas/00_topic_pool.md — メタ「アイデアのアイデア」プール（単一ファイル例外、docs/ideas/ 直下）
新ブレスト時はこれらを参考にしてよい。
ただし機械的にコピーせず、テーマに応じて構造を調整する。
アンチパターン（やってはいけない）
- ❌ 1案だけ書いて「これがベスト」と結論する
- ❌ 実装計画書を書く（タスク分解・スケジュール）
- ❌ コードを大量に書く（コード片は MVP ファイルで参考程度のみ）
- ❌ ユーザーに承認を求める質問を多発する（一気にブレスト完了させる）
- ❌ ファイルを書かずチャット内だけで答える（docs/ideas/ に必ず物として残す）
- ❌ 既存 docs/ideas/// を上書きする（新トピックは新フォルダ）
- ❌ 1ファイルで全部書く（5ファイル前後に分割）
- ❌ 英語で書く（日本語で揃える、既存事例に合わせる）
- ❌ メタフォルダを跨いで
docs/ideas/ 直下にトピックを置く（必ず <group>/ 配下）
- ❌ 勝手に新メタフォルダを作る（既存 8 個で収まらない時はユーザー確認）
拡張: 既存ブレストへの追記
既存 docs/ideas/<group>/<topic>/ に新しい角度を追加する場合:
- 新しい番号のファイルを追加（既存 README を更新）
- 既存ファイルは大きく書き換えない（追記のみ）
- 末尾の「論点ID」連番は既存と被らせない
例: docs/ideas/30_ux/keyboard_modes/ に追加した
08_queue_mode_pattern.md （横断パターン分析）09_numpad_quick_input.md （特定ユースケース深掘り）
注意点
- 「ブレスト」と言われても、ユーザーが 既に方針を決めている ことがある
→ その場合は「決めずに広げて」と確認するか、普通の実装タスクに切替
- 大量のファイルを生成するのでコンテキスト消費に注意
→ 各ファイル 200〜400 行程度を目安に、過剰な肉付けは避ける
- 既存事例（slideshow/keyboard_modes 等）の長さ・粒度を真似ると外さない
- ユーザーが日本語なら日本語、英語なら英語で書く
- 既存メモリ（feedback_no_interpretation）に注意:
タスク文言を勝手に解釈・補足しない。不明瞭なら質問する
→ ブレストはユーザーの曖昧な指示に対しても複数案で展開するので、
feedback_no_interpretation には反しない（むしろ複数案を提示するのが
解釈固定の回避になる）
