Capturing work

/rota-capture records bugs, features, and tasks into the backlog with auto-classification and auto-assigned IDs. Where they land depends on issues.source: on the default file, in .rota/BACKLOG.md; on github or gitlab, as GitHub or GitLab issues. See Issue backend. Paste a raw description, structured notes, or a mixed list.

The examples below show the file backend. On the issue backend the same classification becomes labels (type:bug, p1, size:Major), and the ID is the issue number (#42).

/rota-capture

/rota-capture "the sidebar flickers on hover"

That single line logs a bug entry:

- **[B03] [P2] Sidebar flickers on hover.** ...

On the file backend each item gets a zero-padded, auto-incrementing ID ([B##] for bugs, [F##] for features, [T##] for tasks). The skill asks a few quick questions for context, then assigns:

• Bugs: priority [P0], [P1], or [P2]
• Features: size [Major], [Minor], or [Cosmetic]
• Tasks: no tag

Mixed input: bugs, features, and tasks in one message

Describe everything at once and /rota-capture splits it into entries routed to the right section.

Telling /rota-capture “the sidebar flickers on hover, also we should add keyboard shortcuts, and update the linter config” produces:

## Bugs
- **[B03] [P2] Sidebar flickers on hover.** ...

## Features
- **[F04] [Minor] Keyboard shortcuts for top actions.** ...

## Tasks
- **[T06] Update linter config for new rules.** ...

Items captured in the same batch can reference each other via Related: links.

Underneath, rota item create refuses an empty title or a placeholder (x, tbd, todo, title, untitled, any case) with exit 2. To file many items in one call, pass --batch-file <json|-> with a JSON array of records; it cannot be combined with the other item flags. rota checks every title, kind and field first, then files the records in order and returns one id per record under items. A batch title needs at least three words. If a record fails part way, the error names it and lists the ids already filed.

Item templates

/rota-capture reads the per-kind template from the binary before drafting a body. You can print the same Markdown skeleton yourself:

rota item template --kind features --tag Major
rota item template --kind bugs
rota item template --kind tasks

Comments in the skeleton mark sections as required, recommended or optional. Every feature, including Cosmetic, requires Acceptance and Out of scope; Major features also recommend Touches. Bugs recommend Repro, Expected and Actual, which can also be stated in the description. Tasks have no required sections. Pointers is recommended when you name file paths.

rota item create warns about missing required or recommended sections and still captures the item. Each warning names the new item and asks you to add the section, with a command to print its template. A fresh round assignment refuses a feature missing either required heading and names what to add; an assignment brief can supply them too. rota item ready reports the same required sections. Presence is enough: an empty heading counts, and Out of scope may say “nothing noted”. Old items need no migration or body rewrite; add the missing headings when preparing them for work.

Detail files for large input

When an item’s input is too large for a TODO entry (crash dumps, specs, logs, long checklists), /rota-capture creates a detail file and links to it from the main entry (on the issue backend the text goes into the issue body instead):

- **[B07] [P0] App crashes on launch after iOS 18.2 update.** EXC_BAD_ACCESS in CoreData stack during migration. Detail: `.rota/bugs/B07.md` Related: [F12]

Detail files land in type-specific subdirectories:

A detail file also holds template sections passed through --body-file, even for a short feature. Simple bugs and tasks can keep their information in the description when no separate body is needed.

Related items

Any item can carry a Related: suffix linking it to other items:

- **[B05] [P1] Timer badge stale after pause.** Description... Related: [F03]

Links are optional. /rota-work (no argument) infers the reverse link automatically, so you don’t need to add it to both sides. When linked items form clusters, /rota-work (no argument) suggests tackling them together (see picking work).

/rota-capture scans the open items for connections (on the file backend also ARCHIVE.md), so a new bug can link back to a completed feature.

Milestone-spec audit

When you capture from a milestone spec (the text references an M<NN> tag or a milestones/M<NN>.md path), /rota-capture runs a ship-evidence audit before writing anything. Old specs drift behind code: acceptance criteria written months ago often ship under different IDs, and capturing them again creates duplicate work.

The audit runs rota item shipped against every parsed title and groups matches into three confidence tiers: [STRONG] (commit subject + title overlap), [MEDIUM] (subject hint only), [PATH] (file path hint). For each flagged title you get three options:

• Skip (recommended). Drop the title from this capture run.
• Capture anyway. You’ve reviewed the matches and confirmed the item is genuinely distinct (prior commit was an incomplete first pass, etc.).
• Stop the whole capture. Abort and reconcile the milestone spec via /rota-vision or by hand before retrying.

Ordinary brain-dump captures (no M<NN> reference) skip the audit entirely.

Harness and model

If the text names a harness (“do this one with codex”) or a model, /rota-capture records it so rota round assign picks it up. On the issue backend it adds the label harness:claude or harness:codex and, for a model, model:<id>. On the file backend it ends the entry with Harness: codex Model: <id>. An item with neither runs on the slot’s default.

Dependencies

rota item create --depends-on <refs> writes a ## Depends on section naming the items that must close first. When one item clearly needs another, /rota-capture creates the prerequisite first and passes its new ID. Items that are only related use Related:. See the helper reference.

Triaging an issue someone else filed

/rota-capture --triage <N>[,<N>...] is the first read of a tracker issue you did not write. It reads the whole thread, searches for duplicates and already-shipped work, queries DECISIONS.md for a prior decision and, for a bug, tries the reporter’s steps against the current tree. It creates no item. For each issue it asks you once, then acts: close with the reason, comment and label needs-info, or mark it ready (no label change). Commenting, labelling and closing always ask, whatever autonomy.level says. rota round candidates lists a needs-info issue as not ready, so rounds skip it until you remove the label.

What /rota-capture is not

/rota-capture only records. It classifies and files; it does not act, validate the item, or deduplicate against existing entries. It prints the new IDs and stops, and never starts work. To implement an item, run /rota-work on its ID. To remove a captured item that turned out to be a duplicate or wrong-premise, use /rota-capture --remove.