Agent skills

rd-plan

Turn an idea into one parent and two to four children with acceptance criteria, written to a file so you can argue with it before it becomes a tree.

rd-plan turns "we should probably do X" into a reviewable plan: one parent, a small number of children that each merge on their own, and acceptance criteria written as things you can observe. It writes one markdown file and creates nothing in Radial, which is the point: a plan is cheap to argue with and a filed tree is not.

Turn an idea into a plan for Radial, the keyboard-first issue tracker: one parent issue plus two to four children, each with a goal, a file list and acceptance criteria anyone can check.

When to use it

Before any change big enough that you would otherwise open five tabs and start guessing. Not for a one-line fix: radial create and move on.

What it asks you

Only what it cannot read out of the repo, and all at once. It opens the code the idea touches before decomposing anything, so its questions are about decisions rather than facts: which of two approaches you want, whether an existing surface should change, what is deliberately out of scope. A plan that names no real file is a guess, and it will tell you which files it read.

What it writes

One file, .radial/plans/<slug>.md, holding the parent body and every child body in full. Nothing else. In chat you get a breakdown table, the out-of-scope list, and any open decision written as a default and an alternative.

The reads it does first are what keep it honest: radial workspace show --json for the real status, label and priority names, and radial search per candidate title so it does not file a second tree for work that already exists.

The shape it produces

P   Parent: the goal, the scope, the decisions
├── C1  merges alone
├── C2  merges alone            blocked-by C1
├── C3  merges alone            blocked-by C1
└── C4  merges alone            blocked-by C2, C3

One child is one merge. If a child cannot merge on its own without breaking the default branch, it is not a child, and it gets folded into its neighbour.

Extension points

Hook	What a section here adds
`extra-questions`	Questions this team always wants answered: rollout, data migration, who owns the on-call
`extra-sections`	More required body sections: a security note, a metrics plan, a rollback paragraph
`extra-checks`	Repo-specific checks on the finished plan: naming rules, a forbidden directory, a required label
`plan-bar`	Raise the bar before the plan is shown: more acceptance criteria, a second opinion, a maximum child count
`after-plan`	What to do with a finished plan: post it, open a design doc, tag a reviewer

A worked wrapper

markdown

---
name: payments-plan
description: Payments team rules on top of rd-plan, the questions we always forget and the bar we hold.
extends: rd-plan
---

Read rd-plan first, then apply the sections below at their hooks.

## extra-questions

- Does this touch money movement? If yes, ask which ledger accounts change and
  whether a reversal path exists.
- Ask which regulator-facing report this shows up in, or state that none does.

## extra-sections

- Every child body gets a `**Rollback:**` section naming the exact revert path.

## extra-checks

- No child may name a file under `src/ledger/` without also naming a test file.

## plan-bar

- Every child needs at least three acceptance criteria, one of which is an
  observable failure case.

## after-plan

- Post the breakdown table to #payments-eng before filing anything.

What it never does

It never creates, updates or closes an issue. It never writes an acceptance criterion that asserts an implementation detail, because a test bound to the mechanism you chose becomes the bug's bodyguard after the rewrite. It never puts the full bodies in chat, and it never invents a status, label or priority name. It reads them from your workspace.