| name | second-brain-ingest |
| description | Ingests an item (inline text and/or attached on-device files) into the domain-split knowledge wiki. Classifies the item's domain (work | life), writes a factual source page, copies attached artifacts into raw/assets, re-synthesizes the affected entity and concept pages, resolves entities to canonical [[wikilinks]] via aliases.md, and maintains the strong per-domain index and log. Knowledge-only — no tasks, no board, no channel polling. Invoked headlessly by the vault Agent SDK client via the MCP ingest route.
|
| allowed-tools | Read Write Edit Glob Grep |
Second Brain — Ingest (knowledge-only)
This skill turns one incoming item into durable knowledge in the domain-split
wiki. It does one thing: ingest. It does not route to a board, does not
create tasks/reminders/events, does not poll Gmail / OpenWhispr / Calendar, and
does not own any watermark. It receives marshalled inputs from the MCP ingest
route: the inline text of the item, and zero or more absolute file paths to
attached on-device files. Work the inputs you are given; do not go looking for more.
The vault is knowledge-only: a fact / context / who-what-why. Never write task
checkboxes (- [ ]) into any page. Open work and to-dos live on the board, which this
skill has no access to and must not invent.
Vault layout
The wiki is split by domain. Each domain has its own self-contained wiki tree:
| Root | When |
|---|
work/wiki/ | Professional knowledge — the venture, the role, advisory, work entities/concepts/sources. |
life/wiki/ | Personal knowledge — trips, health, admin, personal entities/concepts/sources. |
shared/wiki/ | Truly-dual entities only — pages referenced by both domains (the user themself, the city they live in). Lives under shared/wiki/entities. |
Each domain tree holds:
<domain>/wiki/index.md — the strong index (see format below) — the entry point.<domain>/wiki/log.md — the append-only ingest log.<domain>/wiki/entities/ — people / orgs / products / tools.<domain>/wiki/concepts/ — ideas / projects / themes.<domain>/wiki/sources/ — one factual page per real source.
Other shared resources at the vault root:
aliases.md — the manual entity-resolution map (surface forms → canonical [[Entity]]).raw/assets/ — preserved copies of attached artifacts. Drop attachments into
raw/assets/ inside your vault (the path is relative to the vault root, which is this
session's cwd).
CORE LOOP
1. Classify the DOMAIN
Decide whether the item is work or life from its content:
- work — your company or venture, your job/role, professional projects,
work contacts, deliverables. Default to
work for ambiguous professional context.
- life — trips, health, citizenship/admin, family, friends, personal logistics.
Default to
life for personal context.
The chosen domain selects the wiki root: work/wiki or life/wiki. A truly-dual
entity (one referenced by both sides of life — the user themself, the home city) is
written under shared/wiki/entities and linked from both domains' pages. Everything
else stays inside its single domain tree.
If an item genuinely spans both domains, ingest its knowledge into the primary
domain and link out to the relevant shared/ entities; do not duplicate a work concept
into life/wiki or vice versa.
2. Write the source page (for a real source / attached file)
For a real source — an inline note worth preserving verbatim context, or any attached
file — create <domain>/wiki/sources/<Title>.md:
- Standard frontmatter:
tags, sources, created, updated (and read-only cases:
only if a board id was passed in — see step 7).
- The source's factual summary and key claims (no interpretation — save synthesis
for concept pages).
- Entities Mentioned —
[[…]] for each actor.
- Concepts Covered —
[[…]] for each idea/project/theme.
- Filename == H1.
A bare inline thought with no real source artifact may not need a source page — route its
knowledge straight to the entity/concept pages.
3. Preserve attached artifacts
For each absolute file path handed to you in the inputs:
- Copy the file into
raw/assets/ (relative to the vault root, which is this
session's cwd) under a sensible, human-readable name (keep the original extension; disambiguate
with a date or topic if the name is generic like image.png). Use Read to load the
file and Write to write the copy (or Read+Write for text; for binary you cannot
transform, copy by reading then writing the bytes through — preserve the original).
- Reference the preserved copy from the source page via a relative markdown link,
e.g.
[Original deck](../../raw/assets/2026-05-12-guadeloupe-deck.pdf) from a page in
<domain>/wiki/sources/. (Sources sit two levels under the vault root, so the relative
path back to raw/assets/ is ../../raw/assets/<file>.)
This keeps the artifact preserved and retrievable — the query skill surfaces these
linked assets as associated artifacts.
4. Re-synthesize the affected pages (rewrite, don't append)
For each entity and concept the item touches, rewrite the page to reflect
everything now known — do not tack new bullets onto the end:
- Fold the new facts into the existing prose; resolve any contradiction in place and note
it with both sources cited.
- Add the source to the page's
sources: frontmatter and bump updated:.
- Create new entity / concept pages where the item introduces something with no page yet.
- A single substantive source touches 10-15 pages — that cross-page re-synthesis
is the entire value. If you only wrote the source page and the index, you missed it.
5. Resolve entities to canonical [[wikilinks]]
Before linking any actor, collapse it to one canonical entity:
- Heuristic first — match on name, known email, and existing wiki entity pages (read
the domain
index.md and the candidate entity page).
- Then
aliases.md (vault root) — the hand-curated map of surface forms → canonical
[[Entity]]. A sender email, a spoken name, and a written name must all collapse to the
same page.
- If you discover a new reliable mapping, append it to
aliases.md in the documented
format (surface · surface · … → [[Canonical Entity]]). Never fabricate a mapping.
Every mention of a page-bearing entity/concept is [[linked]]. Never use raw file paths
for internal references — only [[wikilinks]].
6. Maintain the strong index + log
-
Strong index — update <domain>/wiki/index.md so every concept, entity, and source
page in the domain appears under exactly one overarching theme (see the verbatim
format below). New pages slot under their theme; a page that fits no theme goes under a
final ## Unfiled so nothing is dropped.
-
Log — append to <domain>/wiki/log.md:
## [YYYY-MM-DD] ingest | <Source Title>
Pages: created [[A]]; re-synthesized [[B]], [[C]], … (N total).
Entities: [[X]], [[Y]]. Concepts: [[P]], [[Q]]. Assets: raw/assets/<file>.
7. (Optional) Record a board case id passed in the prompt — READ-ONLY
If — and only if — the ingest route passes you an explicit board case id in the prompt,
you may record it on the affected pages as a read-only reference:
- A
cases: frontmatter list, e.g. cases: [CASE-12].
- A human-readable body line:
**Board:** [[CASE-12]] — <title>.
Never call a board tool (you have none), never invent or guess a case id, and
never add task checkboxes. This is the only board reference allowed on a knowledge
page, and only when an id was explicitly handed to you.
STRONG-INDEX FORMAT (per domain, <domain>/wiki/index.md)
The spec calls for an ultra strong index: an overarching concept which handles multiple
concepts. So the index is NOT a flat list; it is a navigable MAP whose
top-level sections are OVERARCHING THEMES, each grouping its constituent concepts +
entities + sources:
# <Work|Life> Wiki — Index
> One-line statement of what this domain covers. Overarching map: each ## is a theme that handles multiple concepts.
## <Overarching Theme> (e.g. for work: "Flagship venture", "Day job & team", "Skill-building"; for life: "Big trip 2026", "Health", "Citizenship & admin")
One-line framing of the theme.
- **Concepts:** [[Concept A]] — 6-word gist · [[Concept B]] — 6-word gist
- **Entities:** [[Entity X]] — role · [[Entity Y]] — role
- **Sources:** [[Source 1]], [[Source 2]]
## <next theme> ...
## Shared (cross-domain)
- [[Your Name]], [[Your City]] — live in shared/wiki/entities (referenced by both domains).
Rules: every concept, entity, and source page in the domain MUST appear under exactly one
theme (sources may repeat under the theme they evidence). A page that fits no theme goes
under a final "## Unfiled" so nothing is dropped. Keep each gist <=8 words. The themes
themselves are the "overarching concepts".
Conventions
- Knowledge-only. Never write
- [ ] task checkboxes into any wiki page.
- Rewrite, don't append. Re-synthesize each touched page to reflect everything known.
- Source pages are factual. Save interpretation/synthesis for concept pages.
- A substantive source touches 10-15 pages. The cross-page work is the value.
[[wikilinks]] for every internal reference. Never raw file paths.- Filename == H1 on every page.
- Domain-split is real. Keep work knowledge in
work/wiki, life in life/wiki;
only truly-dual entities live in shared/wiki. No cross-domain leaks.
- Resolve entities first — heuristic, then
aliases.md; append new reliable aliases.
- Strong index, not a flat list — themes that group concepts/entities/sources.
- No board, no channels, no watermarks. This skill receives marshalled inputs and
produces knowledge. It owns nothing outside the wiki.
