/ingest — Raw human input → structured work

You are a relay hub: clients text you, partners email you, calls get transcribed. Each of these carries decisions, action items, bugs, and facts — and processing one by hand means re-explaining the same routine every time. This skill is that routine, written down.

The contract: internal, reversible outputs (vault captures, filed issues) happen without ceremony. Outward-facing outputs (replies) are always drafted, never sent.

Files

<vault> is ${SECOND_BRAIN_VAULT:-$HOME/Documents/SecondBrain}.

Step 0 — Get the input and classify it

In order: content in the prompt → clipboard (pbpaste) → ask.

Classify by shape, not by what the user called it:

Long transcripts arrive truncated in chat sometimes — if the content visibly cuts off mid-sentence, say so and ask for the file (or a path) rather than processing a fragment.

Step 1 — Identify who and which project

Read people.yaml. Match participants/senders against name and aliases.

• Matched → you now have the repo, vault page, reply channel, and tone notes. Say which routing you're using in one line ("Routing: Jane → acme-app").
• Unmatched → ask once: "Who is this and what project does it belong to?" Then offer to append them to people.yaml so the question never repeats. If the user declines to add them, process the input with explicit destinations instead of routed defaults.
• Multiple projects in one call (common on partner calls) → split extraction by project; route each piece separately.

Step 2 — Extract

Read the whole input first. Then pull out, with a short verbatim quote or paraphrase anchoring each:

1. Decisions made — anything settled, including "we're NOT doing X."
2. Action items — mine — things the user owes someone. Include any stated deadline.
3. Action items — theirs — things owed to the user (these become the follow-up section of the reply, not issues).
4. Bugs & feature requests — anything that should become a GitHub issue. One issue per item, never a grab-bag.
5. Questions to answer — asked but unanswered in the input.
6. Facts worth keeping — durable context (pricing mentioned, a person's situation, a tool they use) → vault; a genuinely reusable reference → Keep note (only if the keep CLI is authed; skip silently otherwise).

Name verification rule: transcripts mishear proper nouns constantly (brand names, people, tools). Before a name lands in an issue title, vault page, or reply, verify the spelling against the routing config, the repo, or a quick search — never trust the transcript's spelling of a name you can check.

Step 3 — Show the routing plan

One compact table before acting:

Then proceed without waiting — everything in the table is internal or a draft. Pause for confirmation only when routing is ambiguous (two plausible repos, an unmatched person) or the input includes something sensitive (credentials, legal/financial commitments).

Step 4 — Execute

Issues — search for duplicates first (gh issue list --search), then file with gh issue create in the mapped repo. Title = imperative summary; body = context quote from the source, what was asked, and who asked. Apply issue_labels from config if set. Never assign anyone but the user.

Vault capture — one file per ingest, second-brain raw schema:

# 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

Slug: call- or message- + person + topic. Follow the vault's auto-commit convention (semantic commit per session).

Todos — action items of "mine" also land wherever the person's vault_page tracks tasks, if one is configured.

Reply draft — in the user's voice for that channel (config tone + channel norms: text = brief and casual; email = fuller). Structure when it fits: acknowledge → what I'm doing about it → what I need from you → when they'll hear back. End with the draft in a paste-ready block (compose with /paste rules for the channel — e.g. no URLs in an X post body). Never send it.

Step 5 — Report

Close with a compact recap: TLDR of the input (2–3 sentences), decisions, both action-item lists, links to filed issues, the vault file path, and the reply draft. This recap is the deliverable — someone who never saw the input should understand what happened and what's next.

Composes with

• second-brain — captures land in its raw/ schema for later compile
• paste — channel formatting for the reply draft
• deep-research — when an extracted question needs real research before it's answerable
• pm — when a call produces enough work to deserve a project card, not just issues

Notes on quality

• The most common failure is flattening: summarizing the input instead of extracting work from it. The test: could the user act on your output without rereading the source?
• Second most common: issue grab-bags. "Improvements from call with Jane" is not an issue. One item, one issue, one clear title.
• "Theirs" action items are as valuable as "mine" — they're the follow-up ledger. Don't drop them because no tool call captures them.
• A voice-note ingest with zero action items is fine: capture it, say so, stop. Not every input contains work.