brainstorm

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項目>

動作手順

1. ユーザー入力を解析 — テーマ・スコープ・制約を抽出
2. 既存 docs/ideas/ を確認 — 同じメタフォルダ内に近いテーマがないか軽くチェック
3. メタフォルダ判定（鉄則 0） — 上表から 1 つ選ぶ
4. パターン選択 — A/B/C どれが合うか判断
5. トピック名決定 — snake_case でフォルダ名を決める
6. ファイル一覧設計 — 5〜8ファイルの構成案を作る
7. README から書く — 構成と論点一覧、メタフォルダ配置理由を先に固める
8. 各ファイル順次書く — 並列に書ける場合は並列
9. 最後に横断観察 — 最終ファイルに「気づき」をまとめる
10. ユーザーに簡潔報告 — ファイル一覧（メタフォルダ込みパス）とキー論点 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 B
• docs/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 には反しない（むしろ複数案を提示するのが 解釈固定の回避になる）