Files
Keysat 9e5c42c25f Add capture/triage inbox loop; dogfood AGENTS.md/ROADMAP; document git-tracking standard
Introduce the cross-project capture->triage->roadmap loop: /capture appends an
idea or bug to INBOX.md from any repo (new-project ideas included), /triage drains
a project's items into its AGENTS.md or ROADMAP.md. Give the standards repo its own
AGENTS.md (+ CLAUDE.md symlink) and ROADMAP.md so it follows its own standard, and
add a 'What git tracks' section to portability.md plus the canonical .gitignore
block answering what is committed vs gitignored around .claude and symlinks.
2026-06-14 10:36:36 -05:00

3.5 KiB

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.
    • priorityP0P3. 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.