/radin-record

name: radin-record
description: |
  Use for /radin-record or any ask to save something for later, even a vague
  one ("add the findings"): scan the whole session. Logs bugs, follow-ups,
  ideas or feedback raised this session as backlog entries that outlive the
  conversation.
<!-- host:claude -->
argument-hint: "[what to log]"
<!-- /host -->

Record to Backlog

Step 1: Decide what to log

The instruction sets the scope:

• **Specific**: "add the auth timeout bug", "fix this issue", "work on adding that feature"
• **Generic**: "add the findings", "record everything", "we should probably": scan the whole

session for anything a reasonable person calls a bug, follow-up, idea, or feedback. Each distinct item becomes an entry, or joins one by the size rule below.

Log the entry worded close to how it was raised.

One raised thing can be several sequential pieces of work ("add rate limiting on top of new auth middleware" needs the middleware first). Log each piece as its own entry, sized as a **vertical slice**:

• It cuts a narrow but complete path through every layer it touches.
• Landed, it is demoable or verifiable on its own.
• It fits one fresh context window.
• It is worth a leaf. A leaf pays the same planning, checks and review whatever

its diff size, so a piece one function or one small diff covers joins the piece that touches the same module.

• A **prefactor**, the restructuring that makes the real change easy, is its

own entry, which every entry needing it depends on, when it is a slice on its own. A small prefactor opens the entry that needs it.

**The test:** would two leaves read the same files, and could one commit carry both? Yes: one entry. A piece that changes behavior another piece creates is part of that piece's entry, never a dependent entry.

One mechanical change whose blast radius fans across the codebase is the exception, so log it as one entry per batch the change breaks, plus a final entry that puts the tree back green depending on every batch.

An item too fuzzy to phrase as a sharp question is a **stub** ("figure out caching at some point"): log one stub over the whole area, its body saying what is unspecified and what is known, rather than pre-slicing it. Step 2 sharpens it later. A question you *can* state precisely is an ordinary entry, blocked or not.

An external ticket as context (optional)

A ticket key, Jira or GitHub issue URL: fetch it through its MCP, and treat the ticket as extension to the user's prompt. No MCP or API access: log from the ask alone, and continue.

Step 2: Chart each item's open decisions

Settle judgment calls here, while the user is present.

Apply `RADIN_LIB/radin-open-decisions.md` to each item. Look up every Fact first, in the repo, its docs or the API, and keep each answer for Step 5's body. Then settle the item's remaining Decisions now, before the next item and before Step 5's list. Keep every settled answer for Step 5's body. An item with no Decision asks nothing, and so does a stub, one deliberately deferred whole.

**Why:** `radin-batch` cannot ask mid-run, so every question left in an entry stalls that run. The user is present now and the batch is not.

**The test:** can one question per Decision settle it, with no scope left to define? Yes: the clear-prompt channel below. No: the grilling channel.

Pick the channel for the remaining Decisions. Take the first match:

• **The prompt is vague, the task is complex, or the answers are open-ended or depend on

each other, or there are more than 4 Decisions:** invoke `@@skill:grilling@@` on them. <!-- host:claude -->

• **The prompt is clear and up to 4 Decisions each have discrete options:** one

`AskUserQuestion` call. Put your recommendation first, marked "(Recommended)". <!-- /host --> <!-- host:agents -->

• **The prompt is clear and up to 4 Decisions each have discrete options:** one ask per

`RADIN_LIB/radin-ask-rule.md`. <!-- /host -->

• **No Decision remains after the Fact lookups:** ask nothing.

**The test:** does Step 5's list show a question for the user to answer? Then it belongs here. Step 5 asks only whether the split, the dependencies and the plan verdicts are right.

A Decision stays open only when the user says "later" or does not answer, or when no user is present to ask (a sub-agent runs this skill). Then record it as one body line, `**Open decision:** <question>, <options>, <your recommendation>`, so `radin-batch` asks it before execution instead of guessing.

Step 3: Note any skill invoked for this item

If the request that raised the item explicitly invoked a skill (e.g. `/radin-record /frontend-design make the accent color...`, or a skill ran earlier and the item continues that work), record it as a standing instruction, even if it looks redundant or wrong-fit to you: without the line a cold start re-implements from bare text and never invokes the skill the user chose.

`/radin-record /other-skill <...>` means "record an instruction to run `/other-skill` later", and never run `/other-skill` now. Treat `/other-skill <...>` as the text to log: go to Step 1 with it as the item, log with `--skill other-skill`, and stop.

Step 4: Classify each item and note dependencies

Run `RADIN_CLI backlog show` and read the open entries before you classify. It prints every entry with its epic. Find the entries each item shares a file, function or behavior with, and the entries it builds on. An item that passes Step 1's test against an **open** entry, one whose `RADIN_CLI backlog meta` prints no `plan` line, joins that entry: Step 5 appends it there. Against any other entry the item stays its own entry, ordered or related as below.

Does landing this item require another item in the batch (or an existing backlog task from that read) to land first, by sharing a file/function/behavior or by an explicit build-on? Note the other entry's exact title for Step 5's `set-deps`, and say why it comes first in the dependent entry's description. The