# 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

```text
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-table skill="rd-plan">
</hook-table>

## 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.