| name | capturing-inbox |
| description | Use when the user wants to dump a thought, idea, task, reminder, or half-formed observation into the inbox without acting on it. Triggers include "capture this…", "remind me to…", "thought:", "idea:", "for the inbox", "park this", or any unsolicited brain-dump that isn't a request to do work right now. Prefer this over brainstorming, planning, or build skills whenever the user is off-loading rather than asking for engagement — when in doubt between capturing and writing an issue, capture first; promotion is cheap, lost thoughts are not. |
Capturing Inbox
Capture is the load-bearing habit of the whole methodology. If capture has friction, the user stops capturing, and every later skill starves. Your single job is to turn a thought into a file and get out of the way. You are a stenographer, not an editor.
Iron Law
NO VALIDATION DURING CAPTURE. Do not critique, classify, pressure-test, ask "are you sure," suggest scope, propose tags, or speculate about feasibility. writing-issue exists for all of that. From the user's side, capture is write-only.
Phase 1 — Write the inbox entry
- Take the thought as given. If the message starts with a trigger phrase ("capture this:", "thought:", "remind me to…", "for the inbox:"), strip the trigger and keep the rest verbatim. Otherwise use the message as-is.
- Run:
anvil create inbox --title "<short title from user's thought>" --json
Capture id and path from the JSON output.
- Direct-edit the body section of
path, appending the user's thought verbatim under the frontmatter. Preserve voice, hedges, typos that aren't obvious slips, and incompleteness. Do not rewrite, expand, summarize, or "clean up."
Phase 2 — Acknowledge and stop
Reply with one short line: Captured → <path>. Nothing else. Do not echo the thought back. Do not propose links, projects, milestones, or next actions. Do not ask follow-up questions about the thought itself.
Multi-item dumps
If the user pastes something that is plainly several distinct thoughts — separated by blank lines, bullets, "also," or "and another thing" — ask exactly once: "One item or split into N?" Default to a single file if the answer is ambiguous or absent. Never try to auto-segment flowing prose; the cost of a wrong split is higher than the cost of one slightly-overstuffed inbox item, because brainstorming can split later but cannot reconstitute lost grouping.
When the user signals more than capture
If a capture message also contains an invitation to engage ("capture this: refactor auth — actually, let's think about it"), do the capture first, then offer once to hand off to anvil:writing-issue on the captured inbox id. Never silently escalate; the inbox file is the durable artifact and must exist either way.
If the user is clearly already brainstorming — asking questions, weighing tradeoffs, requesting your opinion — say so and suggest switching skills rather than forcing the thought through capture as a formality.
Out of scope
- No tagging, linking, folder choice, or project inference.
- No reading of other inbox items, no dedup, no merge, no cross-reference.
- No promotion to brainstorm / issue / plan / build.
- No editing or deletion of prior captures.
- No frontmatter authoring beyond what the CLI generates.
Capture is write-only and append-only. Reading happens later, in another skill, with more context than you have now.
