Unified inbox processor - handles ALL content types (clippings, transcriptions, VTT files, attachments) with parallel subagents and single-table review. Routes to appropriate creator based on proposed_template.
Unified inbox processor - handles ALL content types (clippings, transcriptions, VTT files, attachments) with parallel subagents and single-table review. Routes to appropriate creator based on proposed_template.
Unified inbox processor - handles ALL content dumped into inbox with parallel subagents and single-table review.
Key design: Subagents persist proposals immediately via TaskUpdate. If session crashes at item 23 of 50, items 1-22 are saved and resumable.
Scope
Single-session workflow. Creates quick resource/meeting notes with distilled: false. Use /para-obsidian:distill-resource for progressive summarization.
Skill Architecture
This orchestrator spawns triage-worker agents, each self-contained with preloaded skills:
Note:content-processing is the canonical pipeline for note creation, Layer 1 injection, and commit — shared by triage-worker and quick-create. create-resource and create-meeting are standalone skills for non-triage workflows.
Architecture Overview
Phase 1: Initialize (coordinator)
├── Scan inbox, detect VTT files, create tasks
└── Load vault context (areas, projects)
Phase 2: Enrich + Analyze + Create (subagents)
├── Route to correct analyzer based on item type
├── Parallel for YouTube, articles, X/Twitter (batches of 10)
├── Sequential for Confluence only (single browser)
├── CREATE notes AND inject Layer 1 content (but DO NOT delete originals)
└── Enriched content stays in subagent context
Phase 2.5: Coordinator Verification (coordinator) ← AUTOMATIC
├── Runs automatically after ALL Phase 2 subagents complete, before Phase 3
├── For each proposal with created != null
├── para_fm_set: stamp summary + source + classification fields from proposal
├── para_fm_get: verify all critical fields populated
└── Override haiku's verification_status with coordinator's assessment
Phase 3: Present & Collaborate (coordinator) ← USER CHECKPOINT
├── Render table with all proposals
├── **ASK USER** - accept/edit/delete?
└── User reviews and can modify area/project/title
Phase 4: Edit (only if requested)
└── Apply edits via para_fm_set or re-create
Phase 5: Execute (coordinator) ← AFTER APPROVAL
├── Delete/archive originals (only now!)
├── Apply any remaining edits
└── Cleanup tasks + report
Key insight: Subagents create notes but originals stay until user approves. This enables collaborative review while keeping content isolated.
The orchestrator MUST NOT read content. All content reading happens in subagents. Never call para_read from the coordinator — spawn a subagent instead.
Why this is a hard rule: 50 inbox items × 10k average tokens = 500k tokens. This overflows the coordinator's context and causes timeouts. With isolation, the coordinator handles only ~500 bytes per item (proposals), keeping total context under 25k tokens.
Voice memo sync runs automatically via dynamic context injection before the skill reaches the agent. This ensures freshly recorded memos are in the inbox before Phase 1 scans it.
If the output shows failures (e.g., parakeet-mlx not installed), log a warning and continue — existing transcriptions in the inbox will still be processed.
Extract stakeholders array from config (names, roles, companies for transcription speaker matching).
1.1.1 Stakeholder Bootstrap (if missing)
If config.stakeholders is empty AND inbox contains voice memos/transcriptions, offer to add stakeholders. Stakeholders enable speaker matching in voice memo analysis — without them, all speakers appear as "Speaker 1", "Speaker 2", and project inference is disabled.
Trigger condition: Empty stakeholders + transcriptions in inbox.
Skip if: No voice memos in inbox (stakeholders only help with transcription processing).
Impact of skipping: Voice memo classification still works, but accuracy is reduced for multi-speaker scenarios and project inference is unavailable.
See stakeholder-bootstrap.md for the interactive wizard flow (bulk paste, one-at-a-time, or skip).
Task IDs are auto-generated. Store mapping: { taskId → file }.
1.6 Pre-load Template Fields
Call para_template_fields once per unique template type (usually just "resource", sometimes "meeting"). Pass results to subagents so they skip this call.
Store the results keyed by template name. Include in every subagent prompt (see subagent-prompts.md).
1.7 Present Summary
Found 50 items in inbox:
📋 By Type:
• 40 clippings
• 8 voice memos (including 2 converted VTT)
• 2 attachments
📋 By Enrichment:
• 35 parallel (YouTube, articles)
• 5 X/Twitter (parallel via X-API)
• 10 no enrichment needed
Starting subagent processing...
Phase 2: Parallel Enrich + Analyze + Create
Key insight: Each subagent handles enrichment, analysis, AND note creation. Content stays isolated in subagent context - only lightweight proposals flow back to coordinator.
CRITICAL: Subagents create notes but DO NOT delete/archive originals. Deletion happens in Phase 5 AFTER user review and approval.
2.1 Spawn Subagents
For all items (up to 10 per batch), spawn subagents in a single message for parallel execution. For inboxes >10 items, use batches of 10. Claude Code handles 7-10 parallel Task calls well for haiku subagents.
EXCEPTION: Confluence items must be sequential (single Chrome browser). Process these separately after parallel items complete.
MANDATORY batch mode flags: Instruct subagents to pass no_autocommit: true and skip_guard: true to para_create. These flags are required for parallel execution — without them, parallel subagents trigger git guard conflicts and unintended per-item commits. The coordinator bulk-commits once after all subagents complete (Phase 5).
Each subagent will: enrich content, analyze, create note (no commit), persist via TaskUpdate, and return PROPOSAL_JSON:{...}.
2.1.1 Model Selection by Item Type
Override the agent's default model based on content complexity:
Transcriptions have ambiguous speakers, unclear meeting boundaries, and nuanced categorization (is this a standup or a 1on1?). Sonnet's reasoning handles this ambiguity better.
vtt (converted)
sonnet
Same as transcription — multi-speaker meetings need stronger judgment
attachment
haiku (default)
Document structure is usually clear (invoices, contracts have obvious patterns)
// Pass model override in Task call:Task({
subagent_type: "para-obsidian:triage-worker",
model: itemType === "transcription" ? "sonnet" : undefined, // undefined = use agent default (haiku)description: "Process: ...",
prompt: `...`
})
2.2 Handle Confluence Separately
Confluence requires Chrome DevTools (single browser instance). Process sequentially AFTER parallel items:
// After all parallel subagents complete, process Confluence items one at a timefor (const confluenceItem of confluenceItems) {
Task({
subagent_type: "triage-worker",
description: "Process: Confluence Page",
prompt: `... same prompt with sourceType: "confluence" ...`
})
// Wait for completion before next
}
Note: X/Twitter items are now processed in the parallel batch (Section 2.1) using stateless X-API MCP tools.
Proposal collection happens in Phase 3. Subagents return PROPOSAL_JSON:{...} in response text.
2.3 Error Handling
Subagents may fail during enrichment (timeouts, 404s, rate limits) or return invalid proposals.
Key behaviors:
Failed subagents leave tasks as pending (no TaskUpdate called)
Invalid proposals get enrichmentFailed: true in metadata
Phase 3 table flags failed items with status column
User can Retry (R), Delete (D), or Skip (S) failed items
Rationale: Haiku triage-workers generate correct values in PROPOSAL_JSON but drop fields ~50% of the time when constructing para_create args. Haiku also falsely reports verification_status: "verified" when fields are empty. The coordinator has authoritative values from PROPOSAL_JSON and stamps them unconditionally — idempotent (if haiku got it right, overwriting with the same value does no harm).
This replaces trust in haiku's verification_status. Workers now set verification_status: "pending_coordinator" and skip post-creation verification.
Key insight: This is the collaborative checkpoint. Notes are already created, but originals still exist. User reviews proposals and can edit before we clean up.
Collect proposals from subagent response text (normal flow) or TaskGet loop (resume flow). Render table with all proposals. Ask user to Accept/Edit/Delete/Quit. Never skip the collaborative checkpoint.
See execution-phases.md for proposal collection code, table format, and checkpoint details.
Phase 4: Edit (If Requested)
Quick inline edits for area, project, title, or type. Show current values, prompt for changes, update task metadata.
