context-ingest

Context Ingest

Purpose

This skill IS:

• The entry point for getting new knowledge INTO your context architecture
• A router that sends information to the correct owning data point
• A classifier that determines what type of knowledge you're adding
• The mechanism that makes your context system compound over time

This skill IS NOT:

• Creating the initial context architecture (use context-onboarding for that)
• Auditing existing context (use context-audit for that)
• A raw file storage system (it extracts and integrates, not archives)

When to Use

• "Here's our new brand guidelines PDF — integrate it" → integrate into active docs
• "Save these meeting notes for later" → dump to _inbox/
• "I have an idea about enterprise pricing" → park in _planned/
• "I read this article — not sure if it's relevant" → triage — Claude reads, recommends a path
• "Our competitor just launched a new product" → integrate into competitive positioning
• "Watch this YouTube video and capture what matters" → triage — Claude extracts, asks where
• "I pasted some notes — figure out where they belong" → triage — Claude classifies, user decides
• "Fetch our brand doc from Google Drive" → fetch + integrate via MCP connector
• "We have hundreds of call recordings in Notion" → map as external reference, don't copy

Front-door dispatch (use first)

context-ingest is the single public entry point for new material. Detect the input shape before asking the user, and dispatch to the specialist skill when one fits — don't make the user know which slash command to type.

| Input shape | Dispatch to | Why | |-------------|-------------|-----| | HTTP/HTTPS URL (article, GitHub, YouTube) | /wiki run <url> (the bcos-wiki skill, Path A) | Wiki owns external-source ingest, banner citations, schema validation, refresh tier | | Path inside docs/_inbox/ and user says "make this a wiki page" | /wiki promote <path> (Path B) | Wiki owns the _inbox/ → _wiki/pages/ promotion | | Local file or pasted text — runbook, SOP, decision narrative, post-mortem, glossary entry, FAQ, transcript, research clipping, customer-call notes | /wiki create from <path-or-paste> (Path B) | Per [plugin-storage-contract.md](../../../docs/_bcos-framework/architecture/plugin-storage-contract.md) Rule 2, the wiki is the universal long-form / cross-cutting content destination. Don't route to _collections/ (legal-weight only) or docs/operations/<custom> (that's a folder pattern that bypasses wiki tooling). | | Slack export, meeting transcript, chat log, call recording transcript | context-mine first → its output lands in _inbox/ → resume context-ingest triage on the result | Mine is the extraction preprocessor; ingest is the classifier/router. The processed _inbox/ capture then typically routes to /wiki promote (transcripts are informational long-form content — Rule 2). | | Loose notes, pasted text, brain dump, "save this for later" | Stay in context-ingest (use AskUserQuestion below) | This skill owns inbox/planned/active classification |

If the dispatch is unambiguous (a URL is a URL), invoke the specialist directly and tell the user one sentence about what you did. If the input is mixed (e.g. Slack export and a URL), do mine first, then handle the URL via /wiki run separately, then return to ingest for whatever's left.

Wiki zone not initialized? If the user's content routes to /wiki create from or /wiki promote but the target repo has no _wiki/ zone, the bcos-wiki SKILL.md Guard fires AskUserQuestion offering: (a) init with defaults + proceed [Recommended], (b) full interview + proceed, (c) cancel. Do not route around the wiki to docs/operations/<custom> or _collections/ — that creates a parallel storage path that breaks Rule 2's substrate guarantee.

context-routing (/context) is retrieval, not ingest — never dispatch there from here.

The Ingest Process

Step 1: Receive and Triage

Accept input in any form:

• A file path (markdown, PDF, text)
• A URL (Claude reads the page, YouTube videos, articles)
• Pasted text in the conversation
• A description of what changed ("we decided to pivot to enterprise")

Note what the source is and where it came from. This becomes the source citation.

**Special case — session captures (docs/_inbox/sessions/*.md):** These are auto-generated by the session save hooks. They already have frontmatter (type: session-capture) and are pre-structured into Decisions, Discoveries, Follow-ups, and Files Changed. When processing these:

• Skip the triage question — they're already classified
• Extract actionable items and route to owning data points
• Check .claude/registries/entities.json for entity disambiguation
• Delete the session file after successful integration (or leave it for prune_sessions.py)

For all other inputs, use the AskUserQuestion tool:

• Question: "What do you want to do with this?"
• Options: Save for later (dump to _inbox/) / It's an idea (park in _planned/) / Integrate it (classify and route to active docs) / Add to collection (bulk similar files) / Not sure (I'll read it and recommend)

| User says... | Action | Where it goes | |-------------|--------|--------------| | "Just save this for later" / "Dump it" / "I'll deal with it later" | Save as-is to docs/_inbox/ with a descriptive filename. No processing needed. Done. | docs/_inbox/meeting-2026-04-06.md | | "This is an idea" / "Might do this someday" / "Park it" | Extract the core concept, create a clean doc in docs/_planned/. Frontmatter recommended but linking optional. Done. | docs/_planned/enterprise-tier.md | | "Integrate this" / "Update our context" / "This is real now" | Proceed to Step 2 below — full classify → find owner → integrate flow. | Active data points in docs/ | | "I have a bunch of these" / bulk similar files (call transcripts, reports, invoices) | Route to a collection folder. Keep original filenames. Append entry to collection index if one exists. See docs/_bcos-framework/architecture/content-routing.md Path 5. | docs/_collections/[type]/ | | "Make this a wiki page" / "Turn this into an explainer" / "_inbox item should become wiki" | Use the wiki-promotion path. Route existing _inbox/ material to /wiki promote; route direct uploads, URLs, or pasted content to /wiki create. | docs/_wiki/pages/ or docs/_wiki/source-summary/ | | "Not sure where this goes" | Read the content, show the user a summary + your recommendation (inbox / planned / integrate / collection), let them decide. | Depends on user choice |

NEVER create folders not defined in the architecture. Valid destinations: docs/ (active), _inbox/, _planned/, _archive/, _collections/[type]/, and _wiki/ through the bcos-wiki skill. If content doesn't fit, ask the user.

For _inbox deposits: Create the file with a simple header:

# [Descriptive title]

**Source:** [URL / meeting / person]
**Date:** [today]
**Deposited by:** context-ingest (unprocessed)

---

[Raw content here]

For _planned deposits: Use the data point template but with relaxed requirements:

---
name: "[Concept Name]"
type: context
cluster: "[Best guess]"
status: draft
created: "[today]"
last-updated: "[today]"
# Optional: declare an exit trigger if the idea has a natural staleness clock
# lifecycle:
#   expires_after: 90d   # if untouched for 90d, lifecycle-sweep flags as idea-dead
---

## Concept

[Polished description of the idea]

## Why This Matters

[Why it might be worth doing]

## Open Questions

- [What needs to be figured out before this becomes active]

Step 1.5: Time-Bounded Content — Declare a Lifecycle Trigger

Whenever the captured content has a natural exit point — a proposal that will be sent, a meeting note that will fold into an SOP, a research dump that will become a wiki page, a dated snapshot t