Process Inbox

Process inbox

Drains the inbox folder of a notes tree: the tree's ONLY capture point. The agent does all filing; nothing processed is left behind.

Adapt before use.

VAULT=~/vault          # the notes tree
INBOX=$VAULT/00-inbox  # the single capture point

Read the notes tree's own CLAUDE.md contract first if it isn't already in context: filing conventions, link style, which folders are immutable, activity-log format.

Operating mode

• Attended run (the user is present, casual ask): inventory, then present ONE batch review gate, per item destination plus a one-line why, and proceed on the go. Never per-item yes/no loops.
• Autonomous run ("process everything", scheduled, or they are away): execute end-to-end and report at the end. File conservatively where ambiguous and say so in the report. This is the normal mode, because captures are usually self-describing about where they belong.

Procedure

1. Inventory. ls -la the inbox. Expect a mix: share-sheet captures, voice captures (may have cleaned titles and structure if a formatting mode ran, or be raw transcripts), images, PDFs, and folders that belong to other workflows. Leave anything that isn't a capture, including README.md.

2. Read everything before filing anything. Text via python3 or cat; images and PDFs via the Read tool. Group bundles: files captured within the same minute (a shared link plus N screenshots) are ONE item. Two identical link captures are a double-tap duplicate, so keep one. Check whether a capture relates to a note a PRIOR session already wrote (grep the likely project); often the note exists and the capture is its missing source material.

3. Classify each item. In practice captures fall into these bins, roughly in order of frequency:

   • Confirmed corrections or updates. Captures saying "correction confirmed", "replacement text for X", "update Y to say Z". These are PRE-APPROVED edits: apply them directly to the owning page, marking the correction inline per that page's existing conventions. Then chase the correction across the tree with grep, because other pages may carry the same stale fact, and any open-question flags it resolves should be closed rather than left dangling.
   • Action items and standing requests. Route to the task manager (step 5). A standing process convention ("from now on, tag X") additionally gets encoded where future sessions will see it: the owning project's index.md or master doc, not just a task.
   • Source material. Statements, receipts, listing screenshots, reference images. File into the owning project's sources/ folder, or the established folder if one exists, keeping its naming. Link from the citing page, and update any tracking table the arrival satisfies.
   • New content. Reflections, dictated stories, research notes. File to the owning project. Raw dictations keep their text verbatim, because transcripts are source-fidelity; add frontmatter and a one-line intro. Add an index bullet.
   • Domain captures with their own skill. If another skill owns a capture type (a nutrition label, a receipt), hand it over rather than filing it as generic source material.
   • Reference and link captures. Resolve what the link IS, usually from the accompanying screenshots, then file where the content belongs. Never file a bare URL as its own note if its substance is already captured elsewhere.
   • Fragments and discards. Stale, duplicate, empty or already-actioned items get deleted. Genuinely diary-ish fragments go to the daily folder only if the user wrote them as journal; agents never author daily entries.

4. Apply and file. Surgical edits to existing pages; new files only where the content is genuinely new. Follow the tree's conventions: link syntax, kebab-case names, YYYY-MM-DD prefixes for dated artefacts, binaries next to citing pages, every touched folder's index.md updated. Never edit filed sources, the daily folder, or generated data namespaces.

5. Action items to the task manager. Route by ownership: the user's court, or the agent's to action next time. Keep the returned task id if you mirror tasks into markdown. Priorities and due dates need concrete values; vague phrases tend to fail silently. Note in the report anything that failed to push.

6. Drain. Delete every processed original from the inbox. The single-copy rule matters: inbox links are guaranteed to rot, so nothing may cite an inbox path. Anything NOT processed stays put and is called out in the report with why.

7. Log and report. Append one line to the tree's activity log with counts and the load-bearing outcomes. Then report: items by bin, pages touched, tasks created, discards, and anything needing the user's eye (deliberate exceptions, ambiguous filings, flags raised).

Gotchas learned in the field

• Voice sessions produce serial corrections to one document. Apply them as one coherent editing pass on the master doc, not six disconnected edits, then add the session's review-tracking markers if the project uses them.
• A correction capture may resolve another project's open question. Grep for the flag before assuming the capture only touches its own subject; sometimes the capture IS the confirmation another page was waiting for.
• Long dictation streams correct themselves as they go. One file with many --- blocks, later blocks overriding earlier ones: apply the FINAL state, but record deliberate exceptions as flagged knowing choices rather than silently dropping them.
• Sensitive content keeps its project's established handling. Never soften or editorialise the user's attributed interpretations; mark them as their read, distinct from confirmed fact.
• A screenshot of an agent error is usually evidence for an existing investigation note. File it next to that note rather than creating a new one.