# rd-issues

> File a plan as a real tree (parent, children, blocked-by edges) and read every issue back to prove the fields landed.

`rd-issues` takes `.radial/plans/<slug>.md` and turns it into issues: the
parent, each child with its body and parent link, the dependency edges between
them, and then a verification pass that reads every issue back. A create that
returned 200 is not proof the field landed, and the read-back is what makes the
tree true rather than probable.

> File a plan as a real tree in Radial, the keyboard-first issue tracker: one
> parent, its children, the blocked-by edges between them, and a read-back that
> proves every field landed.

## When to use it

Right after `rd-plan`, once the plan has been argued with. Not for editing
issues that are already filed: `radial update` is faster and does not need a
skill.

## What it asks you

Which mode, if you have not said. The default files everything into the
backlog, unassigned, with no agent label: the plan exists, nobody is on it yet.
`--start` means you are building this now, so children land in progress,
assigned to you, carrying the label of the agent doing the work. It also stops
and asks if a search turns up an issue that already covers this. Two trees for
one change is the mess `/rd-cleanup` exists to undo.

## What it writes

The parent, then each child with `--parent`, then one `radial link <child>
blocked-by <other>` per edge, then status, assignee and label when `--start` is
on. If a prototype is sitting in `.radial/prototypes/` it attaches it and puts
the Preview URL in the parent body. Then it reads every issue back with
`radial show --json` and fixes anything that did not land.

## The two rules it carries

Calls run one at a time. Filing a tree is a burst of writes, and parallel
`radial` calls race the token refresh: the failure looks like a random 401
halfway through a half-created tree.

Labels are added with `--add-label`, never `-l`. Plain `-l` replaces the whole
set, which is how a type label disappears the moment an agent adds its own
attribution label.

Also, `-d` is inline text. Passing a file path to `-d` stores the literal path as
the description, so every body goes in through `--description-file`.

## Extension points

<hook-table skill="rd-issues">
</hook-table>

## A worked wrapper

```markdown
---
name: platform-issues
description: Platform team filing rules on top of rd-issues.
extends: rd-issues
---

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

## extra-fields

- Every issue gets `--project Platform` and the current cycle.
- Every parent gets an estimate; ask if the plan does not imply one.

## file-bar

- A tree with any `[ui]` tag may not be considered filed until a prototype is
  attached to the parent and its Preview URL is in the body.

## after-file

- Post the parent URL to #platform with the child count and the first child to
  be picked up.
```

## What it never does

It never files a tree without reading every issue back. It never uses `-l` to
add a label, and never replaces a label set it did not author. It never creates
a second parent for a plan that already has one, and it never moves an issue to
done. Closing work is a human decision.