Second Brain Ingest

Second Brain Ingest

Quickly adds a new source to ~/second-brain/ and turns it into a cross-linked wiki page. This is the fast path -- one prompt, full integration.

There is exactly one inbox in this pipeline: ~/Desktop/Notes Inbox/, fed by inbox-processor and meeting-processor. There used to be a second, separate ~/Desktop/Second Brain Inbox/ folder for this skill, but it went unused (checked empty for months) while meetings piled up in the other inbox -- two inbox concepts for one wiki is exactly the kind of fragmentation that causes things to get lost, so it's gone. If the user still says "check my second brain inbox", tell them the inbox was retired and point them at ~/Desktop/Notes Inbox/ via inbox-processor instead.

Step 1: Detect the input

Step 2: Read existing wiki pages

Scan ~/second-brain/wiki/ for all .md files (excluding index.md, log.md, and tags.md). Read each file's first 10 lines to get titles and topic summaries for cross-linking decisions.

Step 3: Assign tags and relate to active work

Follow references/tag-taxonomy.md to assign 3-8 tags (project/person/type/status). This reads personal-context.mdc's Projects Folder and Key People lists fresh each time rather than a fixed list baked into this skill, so tagging doesn't go stale as projects and collaborators change.

For each project/* tag assigned, check whether a wiki page for that project already exists (from Step 2's scan) and note it for cross-linking in Step 4 -- this is how the new content gets connected to the user's active work, even when the source material is only tangentially related (e.g., an article about usability testing connects to project/prototype-creator if it's relevant to that work). The value of the wiki is in the connections -- but only real ones. Before assigning a project/* tag, you must be able to write one sentence in the page explaining the connection. If you can't, don't assign the tag. "It's one of Evan's projects" is not itself a connection -- every page would qualify under that logic, which is exactly how tags stop meaning anything. Content about a CI/build-pipeline decision does not automatically connect to automated-usability-testing or archie just because those are active projects; it connects to whichever project's actual build pipeline is being discussed, or to no project tag at all if the connection is genuinely a stretch. Zero project tags is a better outcome than three unjustified ones.

Step 4: Create the wiki page

Write a new file at ~/second-brain/wiki/<slug>.md following these rules:

• Start with # Title matching the filename
• Second line: **Tags:** #tag1 #tag2 #tag3 using the tags from Step 3
• Summarize key points in bullet-friendly format
• Add cross-links to any related existing wiki pages using [Title](file.md), including the project pages identified in Step 3
• Include a "Related" section at the bottom with links
• MANDATORY: Include a "Sources" section listing the raw source file, even when the content came from pasted text with no URL or file behind it -- in that case write - Pasted text, ingested YYYY-MM-DD rather than omitting the section. A page with no Sources section can't be traced back to where it came from, which defeats the point of keeping a source-of-truth wiki. "The content was short/simple/obviously self-contained" is not a reason to skip it -- short pages are exactly the ones nobody will remember the origin of a month from now.

Step 5: Update existing pages

For each related wiki page, add a link back to the new page in its "Related" section (if not already present).

Step 6: Update index.md

Add the new page under the appropriate category in ~/second-brain/wiki/index.md. Create a new category if none of the existing ones fit.

Step 7: Update log.md

Append an entry to ~/second-brain/wiki/log.md:

## YYYY-MM-DD — Ingested: <source name>
- Created: <new-page>.md — <one-line summary>
- Tags: #tag1 #tag2 #tag3
- Cross-linked with: <list of updated pages>
- Category: <category in index>

Step 8: Update the tag index

Update ~/second-brain/wiki/tags.md — an inverted index (tag -> pages) so tag lookups don't require re-scanning every wiki page. Create the file if it doesn't exist yet. For each tag assigned in Step 3, add or update its entry:

# Tag Index

## project/prototype-creator
- [Page Title](page-slug.md) — YYYY-MM-DD

## person/andy-braren
- [Page Title](page-slug.md) — YYYY-MM-DD

Keep entries sorted newest-first within each tag section.

Step 9: Update the KB files

Follow references/kb-files.md for the exact format. Two checks, both against ~/second-brain/ (not wiki/):

1. Action items. If the ingested content contains an action item owned by Evan Jaquez -- same owner-classification rule meeting-processor already uses (explicitly asked of him, or ambiguous-but-tied-to-his-projects) -- append it to ~/second-brain/pending-actions.md under ## Open, linking back to the page just created in Step 4.
2. Active threads. If a project/* or person/* tag from Step 3 already appears 2+ times in tags.md within the last 2 weeks, check ~/second-brain/active-threads.md for an existing entry. Update its Last touched date and Next step if this page changes what's next. If no entry exists yet, create one. Don't create a thread for a tag that only shows up once -- that's a one-off mention, not a thread.

Skip either check silently if it doesn't apply -- most ingested content won't have an action item, and not every tag rises to thread-level activity.

If the calling skill already populated pending-actions.md directly (e.g. meeting-processor does this itself from its own owner-classified action items, before ever calling this skill) -- skip the action-items check here to avoid double-appending the same item. The active-threads check still applies regardless of who's calling.

Step 10: Confirm

Tell the user what was created, which tags were assigned, what was cross-linked, and suggest related pages they might want to read. If Step 9 appended a pending action or touched an active thread, mention that too.

Example: good vs bad tagging

Good — a meeting note about a prototype-creator eval review with :

**Tags:** #project/prototype-creator #person/andy-braren #type/meeting #status/decision

Specific, matches an active project and a real attendee, one type tag, one status tag because a decision was actually made.

Bad — the same meeting, tagged generically:

**Tags:** #meeting #work #important

#work and #important aren't in the taxonomy and don't connect to anything -- no other page will ever share #important in a meaningful way. Generic tags don't build connections; specific ones do.

Common Mistakes