# Capture — append an idea or bug to the cross-project inbox

The user has a thought about some project — a feature, an idea, a bug they just hit — and
wants it logged *now*, without acting on it and without stopping to decide where it
belongs. Your whole job is to record it durably and get out of the way. Capture is
deliberately dumb and uniform: no routing, no triage, no discussion of the merits. Routing
happens later, via `/triage`, inside the relevant project.

The inbox is a single file: `~/Projects/standards/INBOX.md`. You append to it regardless of
which repo the user invoked you from.

## Procedure

1. **Parse the note** from the user's input (`$ARGUMENTS`). Extract or infer four fields —
   keep it fast, ask only when a field is genuinely missing and can't be inferred:
   - **project** — the target repo. If the user named one, use it. If not, infer from the
     current working directory's folder name. If you truly can't tell, use `?` (triage will
     sort it) rather than interrogating the user. If the idea is for a **brand-new repo that
     doesn't exist yet** ("new project/app/idea for…"), use `new` — or `new:working-name` if
     they gave a name — and set type `project`. These wait for the new-repo bootstrap flow
     and are never triaged into an existing repo.
   - **type** — one of `bug | feature | idea | skill | agent | project | chore` (`project`
     = a potential new repo, used with a `new`/`new:name` project tag). Infer from wording
     ("found a bug" → bug, "we should add" → feature, "what if" → idea). Default `idea`.
   - **priority** — `P0`…`P3`. Use a priority only if the user signals one ("urgent",
     "P1", "minor"). Default `P2`.
   - **note** — the user's text, lightly cleaned up to stand on its own later. Preserve
     their meaning; don't editorialize or expand.
2. **Append one line** to the `## Items` section of `~/Projects/standards/INBOX.md`, in the
   exact format the file documents:
   `- [ ] (project) [type][Pn] note — optional context, YYYY-MM-DD`
   Use today's date. Don't reformat or reorder existing lines.
3. **Make it durable.** Commit and push *only the inbox line* so the note survives and is
   visible from any session or machine — this is the point of the tool, so do it without
   asking:
   - `git -C ~/Projects/standards add INBOX.md`
   - `git -C ~/Projects/standards commit -m "Capture: <short summary>" -- INBOX.md`
     (the `-- INBOX.md` pathspec commits only the inbox, even if other changes happen to be
     staged in the standards repo — never sweep unrelated work into a capture commit).
   - `git -C ~/Projects/standards push` (only if a remote is configured; if the push fails,
     report it but don't treat the capture as lost — it's committed locally).
   Do not touch or commit anything in the repo the user invoked you from.
4. **Confirm in one line** — echo back the exact line you wrote and where, e.g.
   `Logged to inbox: (relay) [bug][P1] … — triage it next time you're in relay with /triage.`
   Nothing more; the user is mid-thought on something else.

## Rules

- One invocation = one item, unless the user clearly lists several; then append one line
  each.
- Never act on the captured item, open files in the target repo, or start discussing the
  fix. Capture only.
- No secrets in the note — if the user's text contains a key/token/password, replace it
  with a placeholder and say you did.
- If you cannot write to `~/Projects/standards/INBOX.md` (missing, unwritable), stop and
  report precisely that — do not silently drop the note or stash it somewhere else.