ingest

/ingest — 人間からの生の入力 → 構造化された作業

あなたは中継ハブです。クライアントからテキストが届き、パートナーからメールが届き、通話は文字起こしされます。それぞれに意思決定、アクションアイテム、バグ、事実が含まれていますが、手作業で処理すると、毎回同じ手順を説明し直すことになります。このスキルは、その手順を記したものです。

取り決め： 内部向けで、取り消し可能な出力（vault への記録、課題の登録）は、仰々しい手続きなしに行います。外部向けの出力（返信）は、常に下書きにとどめ、送信しません。

ファイル

パス	内容
${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/ingest/people.yaml	人物 → プロジェクト／リポジトリ／vault ページ／返信チャネルのルーティング（非公開、gitignore 対象）
<vault>/raw/call-<slug>.md / <vault>/raw/message-<slug>.md	second-brain のスキーマに従った記録
references/people.yaml.example	設定スキーマと具体例

<vault> は ${SECOND_BRAIN_VAULT:-$HOME/Documents/SecondBrain} です。

ステップ 0 — 入力を取得して分類する

順番は、プロンプト内の内容 → クリップボード（macOS では pbpaste、Linux では wl-paste / xclip -o。いずれも利用できないエージェントではスキップ）→ 質問です。

ユーザーが何と呼んだかではなく、形式で分類します。

形式	種類
話者ラベルとタイムスタンプ、または Grain／Zoom／Granola／Fathom の URL やヘッダー	通話
「from X:」／転送されたテキストや DM、一人称で短いもの	メッセージ
メールヘッダー、または挨拶／結びの構成	メール（メッセージとして扱い、フォーマルな口調にする）
構造のない一人称の語り（「そういえば、考えていたんだけど……」）	ボイスメモ（返信の下書きは作成せず、記録とアクションのみ）

長い文字起こしは、チャット上で途中までしか届かないことがあります。文の途中で明らかに切れている場合は、断片を処理せず、ファイル（またはパス）を尋ねてください。

ステップ 1 — 人物とプロジェクトを特定する

people.yaml を読み込みます。参加者／送信者を name と aliases に照らし合わせます。

• 一致した場合 → リポジトリ、vault ページ、返信チャネル、口調に関するメモが分かります。使用するルーティングを1行で伝えます（「ルーティング：Jane → acme-app」）。
• 一致しない場合 → 「これは誰で、どのプロジェクトに関するものですか？」と一度だけ尋ねます。その後、質問を繰り返さずに済むよう、people.yaml への追記を提案します。追加を断られた場合は、既定のルーティングではなく、明示された宛先を使って入力を処理します。
• 1回の通話に複数のプロジェクトが含まれる場合（パートナーとの通話ではよくあります） → 抽出内容をプロジェクトごとに分け、それぞれ個別にルーティングします。

ステップ 2 — 抽出する

まず入力全体を読みます。次に、各項目の根拠となる短い原文引用または言い換えを添えて、以下を抽出します。

1. 決定事項 — 「X はしない」という決定も含め、確定したことすべて。
2. 自分のアクションアイテム — ユーザーが誰かに対して行う必要があること。明示された期限も含めます。
3. 相手のアクションアイテム — 相手がユーザーに対して行う必要があること（課題ではなく、返信のフォローアップ欄に記載します）。
4. バグと機能リクエスト — GitHub の課題にすべきもの。項目ごとに課題を1つ作り、複数項目をまとめた課題にはしません。
5. 回答すべき質問 — 入力内で尋ねられているものの、回答されていない質問。
6. 残しておく価値のある事実 — 長期的に役立つ背景情報（言及された価格、人物の状況、使用しているツールなど）は vault へ。実際に再利用できる参考情報は Keep ノートへ（keep CLI が認証済みの場合のみ。そうでなければ何も言わずにスキップします）。

名前の確認ルール： 文字起こしでは固有名詞（ブランド名、人物名、ツール名）が頻繁に誤認識されます。課題のタイトル、vault ページ、返信に名前を使う前に、ルーティング設定、リポジトリ、または簡単な検索で綴りを確認してください。確認できる名前について、文字起こし内の綴りをそのまま信用してはいけません。

ステップ 3 — 振り分け計画を示す

実行前に、簡潔な表を 1 つ示します。

#	項目	振り分け先
1	「レポートページの一括エクスポートボタン」	Issue → myorg/acme-app
2	決定事項：月払いをデフォルトにする	vault Projects/Acme.md
3	Jane への返信	下書きを以下に記載

その後は確認を待たずに進めます。表の内容はすべて内部情報か下書きです。振り分け先が曖昧な場合（候補となるリポジトリが 2 つある、人名が一致しない）や、入力に機密情報（認証情報、法的・金銭的な確約）が含まれる場合にのみ、確認を求めて一時停止します。

ステップ 4 — 実行する

Issue — まず重複を検索し（gh issue list --search）、次に対応付けられたリポジトリで gh issue create を使って起票します。タイトルは命令形で要約し、本文には入力元からの引用、依頼内容、依頼者を含めます。設定されている場合は、設定の issue_labels を適用します。ユーザー以外の人をアサインしてはいけません。

Vault への記録 — 取り込み 1 回につき 1 ファイルを、セカンドブレインの生データ用スキーマで作成します。

# message-jane-bulk-export (2026-09-04)
source: text message from Jane
project: Acme App

## Summary
…

## Decisions
…

## Action items
- [ ] mine: …
- [ ] theirs: Jane to …

## Filed
- myorg/acme-app#123 — Bulk-export button on the reports page

スラッグは call- または message- + 人名 + トピックにします。Vault の自動コミット規則（セッションごとのセマンティックコミット）に従います。

ToDo — 「自分の」アクション項目は、その人の vault_page でタスクを管理している場合、そこにも記録します。

返信の下書き — そのチャネルに合ったユーザーの文体で作成します（設定の tone とチャネルの慣習に従います。テキストは簡潔でくだけた表現、メールはより丁寧な表現にします）。適している場合は、次の構成にします：受領を伝える → 対応内容 → 相手に必要なこと → 次の連絡時期。最後に、そのまま貼り付けられる形式の下書きを記載します（チャネルごとの /paste ルールに従います。例：X の投稿本文に URL を入れない）。送信してはいけません。

ステップ 5 — 報告する

最後に、簡潔なまとめを記載します。入力の TLDR（2〜3 文）、決定事項、両方のアクション項目リスト、起票した Issue へのリンク、Vault ファイルのパス、返信の下書きを含めます。このまとめが成果物です。入力を見ていない人でも、何が起きたのか、次に何をするのかがわかる内容にします。

連携するもの

• second-brain — 記録内容を raw/ スキーマに保存し、後でコンパイルできるようにします
• paste — 返信の下書きをチャネルに合った書式に整えます
• deep-research — 抽出した質問に答えるため、事前に本格的な調査が必要な場合に使います
• pm — 通話で生じた作業が、Issue だけでなくプロジェクトカードを作るほど多い場合に使います

品質に関する注意

• 最もよくある失敗は平坦化です。入力から作業を抽出せず、要約してしまうことです。出力を見たユーザーが、元の内容を読み直さずに行動できるかどうかを基準にします。
• 2 番目によくある失敗は、Issue の寄せ集めです。「Jane との通話で出た改善点」は Issue ではありません。1 項目につき Issue を 1 件作り、タイトルを明確にします。
• 「相手の」アクション項目も「自分の」アクション項目と同じくらい重要です。フォローアップの記録だからです。ツール呼び出しで処理できないからといって、捨ててはいけません。
• アクション項目が 0 件のボイスメモを取り込んでも問題ありません。記録したことを伝えて、そこで終えます。入力のすべてに作業が含まれているわけではありません。