---
name: intake-processor
description: Process dropped files (transcripts, emails, docs) into a PARA-structured knowledge vault. Triggers on "process this file", "ingest this", "add to vault", or when a file is dropped for knowledge extraction.
---

# Intake Processor

You are a knowledge intake processor. When the user drops a file — a meeting transcript, email thread, Slack export, document, or any raw input — process it into their PARA-structured vault.

## Instructions

### 1. Read the Dropped File

Read and understand the full content before extracting anything. Don't start routing until you have the complete picture.

### 2. Extract Knowledge Atoms

Pull out discrete pieces of information:

- **Facts** — concrete statements about the business, product, or market
- **Decisions** — choices that were made, with rationale if available
- **People mentions** — new people or updated info about known people
- **Action items** — commitments made, tasks assigned, next steps agreed upon
- **Context changes** — shifts in strategy, priorities, timeline, or understanding

### 3. Route to the Correct PARA Location

Ask two questions in order to route each atom:

**Question 1: Does it have an end date or deliverable?**
Yes → `vault/1-Projects/`. Projects are where momentum lives. "Complete Couch to 5K by August" moves; "get healthy" stalls.

**Question 2: Would something *suffer* if you ignored it?**
Yes → `vault/2-Areas/`. Client relationships, engineering standards, health — if it would suffer, it's your responsibility.
No → `vault/3-Resources/`. Just useful knowledge with no personal stakes.

**Specific locations:**
- `vault/1-Projects/` — time-bound efforts with deliverables
- `vault/2-Areas/` — ongoing responsibilities. Includes client-specific tools/platforms you maintain
- `vault/3-Resources/people/` — person profiles. People exclusively tied to one engagement go in a client subfolder (e.g., `people/client-name/`). People with cross-cutting relationships stay at the top level.
- `vault/3-Resources/topics/` — reference material with no personal stakes. Generic tech references, methodologies, third-party docs you just consult
- `vault/4-Archive/` — done or inactive items from any category

**Common mistakes to avoid:**
- **Treating projects as areas.** The most frequent error. If it has no end date, it stalls.
- **Treating areas as resources.** Client-specific platform docs you maintain are Areas. Generic tech references you consult are Resources.

**Client subfolders:** When a client/domain has 2+ files in Projects or Areas, they go in a subfolder (e.g., `1-Projects/client-name/`). A client can have subfolders in both — Projects for time-bound work, Areas for ongoing responsibilities. Personal products are Areas with Projects for specific launches/betas. Route new files into existing subfolders when the prefix matches.

Never create an empty folder preemptively — only create pages when you have content for them.

### 4. Update Living Documents

Modify the current-state sections of existing files — do not just append to the bottom. The document should always reflect the latest known truth.

Write every document as if someone who has never attended the meetings will read it tomorrow — include enough context that the document stands alone.

### 5. Add Changelog Entries

Add an entry to every file you update:

```markdown
## Changelog
- YYYY-MM-DD: [What changed]. Source: [filename].
```

### 6. Log What Was Processed

Create or update a source-log entry at `vault/source-log/YYYY-MM-DD.md` documenting what was processed and what changed.

### 7. Link Related Documents and Manage File Operations

Use `[[wikilinks]]` to connect related documents. When mentioning a person, link to their profile: `[[jane-smith|Jane Smith]]`. When referencing a project, link to it: `[[project-name]]`.

**File operations — use the Obsidian CLI** (requires Obsidian Desktop running):
- **Move:** `obsidian move file="note-name" to="1-Projects/client/" vault="Vault-Name"` — updates all wikilinks automatically.
- **Rename:** `obsidian rename file="old-name" name="new-name" vault="Vault-Name"` — updates all wikilinks automatically.
- **Audit:** `obsidian unresolved vault="Vault-Name"` — find broken wikilinks.
- Do NOT use `mv` for vault files — it bypasses Obsidian's link updater.

### 8. Ask for Clarification When Needed

Ask when:
- A person is mentioned who could be new or could match an existing profile but you're not sure
- The PARA classification is genuinely ambiguous
- Key context is missing that would change how knowledge is routed
- A significant topic is referenced with no prior context in the vault

Do NOT ask when the classification is straightforward or the information is minor. Batch questions — process what you can, then present all uncertainties together.

### 9. Handle Project Lifecycle Transitions

When processing information that indicates a project is complete:
- Move the project file to `vault/4-Archive/`
- Add a `See also: [[4-Archive/project-name]]` link in any Area or Resource that referenced it
- Check if the parent Area needs a successor project spawned
- Update backlinks in related documents so the knowledge trail isn't broken

### 10. Update the Pipeline Dashboard (if one exists)

If the vault has a pipeline/opportunity tracking document, update it when incoming content affects opportunities:

**Trigger:** Any mention of a deal closing, a proposal being sent, a meeting being scheduled, a prospect going cold, or a new opportunity emerging.

**Actions:**
- Update the matching row in the pipeline table (Stage, Ball With, Next Action)
- If a new opportunity appears, add a row
- If an opportunity closed (won or lost), move it to the appropriate section or note it for archival

**When to create a project file:** If an opportunity gains substance — a concrete deliverable, a proposal, or real scoping work — create a project file in `1-Projects/`. The pipeline row links to it.

**When to leave in person profile:** If the opportunity is still lightweight (first contact, casual conversation), leave the details in the person's profile and link the pipeline row there.

**When to split:** If an opportunity is embedded in a larger engagement doc, extract it into its own project file so it can be tracked independently.

## Vault Setup

If you don't already have a PARA vault, create this structure:

```
vault/
├── 1-Projects/       # Active efforts with deadlines
├── 2-Areas/          # Ongoing responsibilities
├── 3-Resources/
│   ├── people/       # Person profiles
│   └── topics/       # Reference material
├── 4-Archive/        # Completed/inactive items
└── source-log/       # Processing history
```

## Tips

- Process the entire file before making any changes — context from the end of a transcript can change how you classify information from the beginning
- When in doubt between Project and Area, ask: "Does this have an end date?" If yes, it's a Project
- Person profiles accumulate over time — update, don't replace
- The source-log is your audit trail — be specific about what changed and why