brain-dump

Brain Dump

ユーザーのまとまりのない考えを受け止め、実際に取り組める形にします。構造化されたプロジェクトとタスクリストにまとめ、これまでの作業とのつながりも示します。

ユーザーの頭がいっぱいで、考えを吐き出したいときに使うスキルです。具体的な質問があるときに使うものではありません。

ダンプを受け取る方法

ユーザーは、思いついたことを一連の流れで貼り付けたり、入力したり、音声から文字起こししたりします。内容はまとまりがないでしょう。処理を始める前に確認の質問をしないでください。中断されたくない、というのがこのスキルの目的です。渡された内容を処理してください。本当に曖昧な点があれば、最後に未解決の質問として挙げてください。

「以上です」と言っていなくても、メッセージが明らかにブレインダンプなら、完了したものとして処理してください。続きがあれば、ユーザーが送ってくれます。

ステップ 1：作業フォルダーの内容を読む

内容を整理する前に、Cowork が参照しているフォルダーを確認します。次の項目について、タイトルを確認し、内容にざっと目を通してください。

• プロジェクトファイル
• 過去のブレインダンプ
• 意思決定ログや日誌
• 計画書、ロードマップ、戦略資料

目的は、新しいダンプを白紙の状態として扱うのではなく、既存の作業と結び付けることです。ユーザーはこの瞬間より前にも考えを巡らせており、ダンプはその続きである可能性があります。

ステップ 2：ダンプを分類する

ダンプの内容を、次のいずれかに分類します。

• プロジェクト — 完了までに単一のアクション以上が必要なもの
• タスク — 単一のアクション
• 意思決定 — ユーザーが検討中で、まだ実行に移していないこと
• アイデア — 興味深い考えだが、まだプロジェクトではないもの
• 懸念事項 — 心配事、摩擦、気になっていること
• 質問 — 答えがわからないこと

ダンプ内の一文が複数の分類に当てはまることもあります。問題ありません。それぞれの分類に記載してください。

ステップ 3：出力を作成する

brain-dump-YYYY-MM-DD-HHMM.md として保存します。構成は次のとおりです。

# Brain dump — [date, time]

## TL;DR
One paragraph: what was on their mind. Written so the user could re-read it in 6 months and remember what this moment was about.

## Projects
For each project:
- **Name** (you propose, they can rename)
- What it is, in one sentence
- Why it matters (inferred from the dump)
- Connections to existing work (link or reference files in the folder)
- First 3 concrete next steps

## Tasks
A flat checklist. Group by context if useful (errands, calls, writing, etc.). Don't pad.

## Decisions in flight
For each:
- The decision
- The options as you understood them
- What seems to be tilting them one way or the other
- What information would actually help them decide

## Ideas worth keeping
Brief — title + one sentence each. Don't expand.

## Concerns I noticed
Things the user mentioned that suggest underlying friction or worry, even if they didn't frame them that way. Be honest but not alarmist.

## Open questions
Anything ambiguous in the dump that I couldn't resolve.

## How I can help right now
A menu of 3–5 specific next moves I can take, e.g.:
- Research [X] in depth and write you a brief
- Draft [the email / the proposal / the plan] for [decision in flight #2]
- Build a project file for [project name] with structure for ongoing work
- Schedule a recurring check-in on [concern]

Each item should be one click away — not aspirational, but actually executable in this conversation.

各セクションが重要な理由

• 要約 — ユーザーが後から振り返るときに読み返します。前提知識がなくても理解できるように書いてください。
• プロジェクトとタスク — ユーザーのダンプには両方が混在します。それらを切り分けることが、最も価値のある作業です。
• 既存の作業とのつながり — ダンプを単発のものではなく、継続的な流れの一部にします。これがなければ、ブレインダンプは毎回孤立してしまいます。
• 気付いた懸念事項 — ユーザーが何かを気にしていて、それを直接口にしないまま考えを吐き出していることがあります。そうした兆候を捉えてください。
• どのように支援できるか — 次の行動につなげます。ユーザーは頭の中を整理するためにダンプをしたので、文書をただ残すのではなく、そこからすぐに行動できるようにします。

ルール

1. 心理分析をしないでください。 「気付いた懸念事項」は観察に基づく内容にし、セラピーのようにしないでください。「共同創業者の件に3回触れていました。別途話し合う価値がありそうです」のように書き、「共同創業者のことでストレスを感じているようですね」とは書かないでください。
2. ユーザーが言っていないタスクを追加しないでください。 あなたの役割は入力を整理することであり、新しい作業を生み出すことではありません。
3. 印象に残る名前を付けてください。 プロジェクトには覚えやすく具体的な名前を付けます。「価格設定のプロジェクト」より「第2四半期の価格設定リファクタリング」のほうが適切です。
4. 書式を凝りすぎないでください。 表や複雑な構成は事務的な印象になります。シンプルな文章と箇条書きが適切です。
5. ダンプと同じか、それより短くしてください。 ユーザーが800語を渡したなら、出力は800語以下にします。500語のダンプから4,000語の文書を作るのは適切ではありません。