# Second Brain Ingest > Ingests a source into the second-brain wiki. Accepts raw text, a file path, a URL, a Google Doc, or Slack context. Also processes files from the Desktop Notes Inbox folder. Reads the source, creates a wiki page, cross-links it with existing pages, and updates the index and log. Use when the user says "ingest this", "add this to my wiki", "save this to second brain", "wiki this", "process my inbox", "check my inbox", or drops content and wants it filed. - Skill: `jaquevan/second-brain-ingest` (Agent Skill, multi-file: 10 files) - Install (CLI): `npx skillmds@latest add jaquevan/second-brain-ingest` - Raw SKILL.md: https://api.skillmd.com/api/skills/jaquevan/second-brain-ingest/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Integrations & APIs - Author: jaquevan (https://skillmd.com/u/jaquevan) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/jaquevan/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 | Input type | How to handle | |---|---| | Raw pasted text | Save to `~/second-brain/sources/YYYY-MM-DD-slug.md` | | File path (local) | Read the file directly | | Google Doc URL | Extract via `gws docs documents get` (see source-reader skill) | | Slack reference | Extract via Slack MCP `search_messages` | | URL (web) | Fetch and extract text content | | Notes Export HTML | Read the HTML, extract text content | | Meeting content (from `meeting-processor`) | Already extracted/structured -- skip straight to Step 2 with the processed summary, decisions, and action items | ## 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](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/.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: - Created: .md — - Tags: #tag1 #tag2 #tag3 - Cross-linked with: - Category: ``` ## 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: ```markdown # 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](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 | Problem | Fix | |---|---| | Reusing the old fixed 7-project list from memory | Always read `personal-context.mdc` fresh in Step 3 -- the list changes as projects change | | Tagging with vague words like `#work`, `#important`, `#misc` | Every tag must be in one of the four categories in `references/tag-taxonomy.md`. If nothing fits, that's a signal the content needs a more specific type tag, not a generic one | | Skipping Step 8 (tag index) because the page itself has tags | The inverted index is what makes tags queryable without re-scanning 40+ files. A page with tags but no index entry is only half-tagged | | Assigning a person tag for someone only mentioned in passing | Person tags are for attendees/owners, not every name that appears in the text | | Tagging every active project because they're all "relevant to Evan" | Assign a project tag only if you can write the one-sentence connection in the page itself. Found by eval: a CI-migration page got tagged `project/automated-usability-testing` and `project/archie` with no stated reason at all. | | Skipping the Sources section on short or pasted-text content | It's mandatory every time, even for a one-paragraph paste with no URL -- write `- Pasted text, ingested YYYY-MM-DD`. Found by eval: a page with real content was missing this section entirely while two sibling pages in the same run had it. | | Using `type/session-log` on a page this skill created directly | That tag is reserved for pages the `session-log` skill creates. Use `type/decision`, `type/tool`, or `type/research` for a feature/decision note instead. Found by eval: a feature-update page got tagged `type/session-log` even though `second-brain-ingest`, not `session-log`, created it. |