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.

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)

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