jared
/
cc-os
1
0
Fork 0
Code Issues 18 Pull Requests Packages Projects Releases Wiki Activity
cc-os/plugins/os-backlog/skills/capture/SKILL.md

2.3 KiB
Raw Blame History

description
Capture work discovered mid-session as an issue on the current repo's configured tracker — creates it with a priority label when known and no state labels. Use unprompted WHEN a concrete follow-up task, bug, or piece of deferred work surfaces mid-session that will not be done in this session. Invoked by `/os-backlog:capture`.

Capture a piece of work as an issue on the current repo's configured tracker, cheaply, without interrupting the current task.

Rules (non-negotiable)

  • Capture never applies state labels, and never applies next. next is human-curated (ADR-0042) — the AI never adds or removes it, under any instruction short of an explicit direct user request naming the specific issue.
  • Apply a priority label (P0–P3) only when it's actually known from context; otherwise leave priority unset — don't guess one to fill the field.
  • Never a TODO comment in code, never only a mention in chat — always a real issue.

Procedure

All commands use the plugin CLI at ${CLAUDE_PLUGIN_ROOT}/bin/os-backlog.

  1. Create the issue on the cwd repo's configured tracker: 
    ${CLAUDE_PLUGIN_ROOT}/bin/os-backlog issue-create --title "<short imperative title>" \
  --body "<context: what surfaced, why it's deferred, repo/file paths>" \
  [--priority P0|P1|P2|P3]
    This creates the issue via tea (forgejo), gh (github), or a NNN-<slug>.md frontmatter file (repo:) — whichever the project's tracker key names. issue-create is structurally incapable of applying state labels; there is no flag for one, by design.
  2. Confirm to the user in one line: tracker, title, priority if set. Then return to the interrupted task.

No tracker configured

If issue-create fails because the project has no tracker key in .cc-os/config, suggest /os-backlog:route once — do not nag or retry — and otherwise degrade gracefully: tell the user what could not be captured and let them decide where it should go for now.

Failure behavior

Fail soft. If the CLI or the underlying tracker (tea/gh) is unavailable, it prints one clear error and exits nonzero — report that error to the user verbatim and offer to note the task elsewhere. Never retry destructively, never leave partial state unmentioned.