---
name: radin-record
description: |
  Log feedback, bugs, follow-ups, or ideas raised mid-session as structured
  BACKLOG.md entries, so they survive past the conversation. Use for
  /radin-record, "log this to BACKLOG.md", "add as follow-up/bug/idea",
  "record what we just found", "note this for later", "add findings to
  backlog". Triggers even on vague asks ("add the findings") — scan the
  whole session, not just the literal text.
---
# Record to Backlog

Turn feedback, bugs, follow-ups, or ideas raised during a live session into
structured entries in `BACKLOG.md`, so they survive past the conversation
that surfaced them. This is the capture step for everything that isn't a
code-review finding — things a human said, not things a diff revealed.
`radin-review` logs code-review findings instead. `radin-plan` and
`radin-execute` consume the backlog afterward.

## Step 1: Resolve project namespace, locate BACKLOG_FILE

Radin never writes backlog/state files into the target repo. Run the shared
namespace-resolution script — the single source of truth for this logic,
shared by every radin agent/skill — and read `REPO_ROOT`, `NAMESPACE_DIR`, and
`BACKLOG_FILE` from its output:

```bash
bash "$HOME/.claude/radin-lib/radin-namespace.sh"
```

This creates `$NAMESPACE_DIR/state`, `$NAMESPACE_DIR/plans`, and
`$NAMESPACE_DIR/reviews`, and best-effort upserts `registry.json` (a skipped
upsert never blocks `$BACKLOG_FILE` from being written correctly). Use the
printed `REPO_ROOT` / `NAMESPACE_DIR` / `BACKLOG_FILE` values for the rest of
this session.

## Step 2: Decide what to log

The user's instruction after `/radin-record` decides scope:

- **Specific** (names a particular thing — "add the auth timeout bug",
  "log the caching idea we discussed"): log exactly that item. Don't go
  digging for other candidates the user didn't point at.
- **Generic** ("add the findings", "log what we discussed", bare
  `/radin-record` with no argument): scan the whole session so far for
  anything a reasonable person would call a bug, follow-up, idea, or piece
  of feedback. Include things the user stated outright, and things that
  were clearly surfaced as a "we should probably..." aside mid-task, even
  if nobody stopped to write them down. Each distinct item becomes its own
  entry.

Either way, stay faithful to what was actually said. This is a capture tool,
not a brainstorming one — don't invent items the conversation didn't raise,
and don't editorialize on top of what the user said.

## Step 3: Classify each item

`BACKLOG_FILE` is organized into top-level semver-style category sections —
`## feat`, `## fix`, `## chore`, `## refactor` — same vocabulary as a
conventional-commit type. Classify each item into exactly one:

- **feat** — a new capability or behavior is being asked for (an idea, a
  "what if we...", a feature request).
- **fix** — something is broken or behaving incorrectly.
- **chore** — maintenance-shaped: a follow-up/TODO that isn't a new feature
  or a bug (docs, tooling, cleanup, "we should probably go back and...").
- **refactor** — feedback that an existing approach/structure should change
  without changing behavior (e.g. "I don't love how this got structured").

When an item could plausibly fit two categories, pick the closer one and
move on — don't stall on classification; a slightly-off category costs
nothing since `radin-execute`/`radin-plan` read the description
regardless of category.

## Step 4: Append entries to BACKLOG.md

Create `$BACKLOG_FILE` with a `# Backlog` heading first if it doesn't exist
yet. For each classified item, find (or create) its category section — in
canonical order feat → fix → chore → refactor relative to whichever
sections already exist — then append an entry under it in this exact shape:

```
### <short title>
<as exhaustive a description as the situation warrants: what was being
discussed/worked on when this came up, the item itself close to how the
user stated or clearly implied it, and why it matters if that's not
already obvious. radin-execute/radin-plan will act on this entry with
no other session context, so don't compress it down to one line.>
```

Always append — don't scan `BACKLOG_FILE` for near-duplicates or try to merge
with an existing entry; let `radin-execute`/`radin-plan` or a human
dedupe later, since a false-positive merge silently drops something the
user cared about, which is worse than an occasional repeated entry.

## Step 5: Report back

Tell the user:

- How many entries were logged, with their titles and categories.
- Path to `$BACKLOG_FILE`.
- If nothing in scope (Step 2) actually rose to the level of a loggable
  item, say so plainly — don't pad the file with a vague entry just to prove
  the skill ran.