Agent skills
rd-build
Work a filed tree child by child (in progress, build, gate, browse checks, notes, in review), resuming from live statuses.
rd-build executes a filed plan and leaves a trail on the issues: a status
change when work starts, an implementation-notes comment when it finishes, and
a move to in review. It reads the live statuses first, so running it again
continues an interrupted build instead of rebuilding what already shipped.
Work a filed tree in Radial, the keyboard-first issue tracker, child by child in dependency order: move each child to in progress, build it, check every acceptance line, run the repo's gate, drive the browse checks, post implementation notes as a comment, and move it to in review.
When to use it
The tree is filed and you are ready to write code. Not when there is no tree
yet, and not when you only want the gate run: that is /rd-verify on its own.
What it asks you
Nothing, once it starts. It is the one skill in the pack that runs long and
autonomously, so the questions happen before it: rd-plan argued about the
shape and rd-issues filed it. During the run it reports rather than asks, and
it stops rather than guessing when a child turns out to be infeasible.
What it writes
On each child: a status change to in progress, an assignee if the field was empty, the agent label, then an implementation-notes comment and a status change to in review. On the parent: the same kind of notes and a move to in review at the end. In the repo: the code, plus whatever the plan named. It finishes with a delivery table: one row per issue with a determination it made by re-reading the acceptance lines, not by trusting that code exists.
Where a child actually gets stuck
Two rules do most of the work, and both exist because of the same failure: a child that looks finished and is not.
Name the surface, or it does not exist. The service, the types and the tests land, and nothing renders. Before a child may move, the skill answers in writing, for every surface its UX and browse checks mention: which file renders this, and which route reaches it? An exported constant is not a surface.
A child reaches in review when its own browse checks are observed, not at the end. Run in a sweep at the end, every child is already marked done and nothing can fail. So the checks run as part of finishing that child, against the running app, and a passing unit test is never evidence for one. A child whose checks cannot be driven yet stays in progress with the reason stated.
Extension points
| Hook | What a section here adds |
|---|---|
before-child | Preconditions before each child starts: a clean tree, a rebase, a required reviewer |
extra-checks | Extra per-child verification after the acceptance lines: a security scan, a bundle-size check, a migration dry run |
review-bar | Raise the bar before a child moves to in review: screenshots, a second opinion, a specific test tier |
after-child | Per-child follow-ups once it reaches in review: push, post to chat, update a board |
after-tree | Whole-tree work after the last child: a changelog entry, a demo recording, a summary to a stakeholder |
A worked wrapper
---
name: team-build
description: Our build rules on top of rd-build. Clean trees, screenshots, and a push per child.
extends: rd-build
---
Read rd-build first, then apply the sections below at their hooks.
## before-child
- Refuse to start a child on a dirty working tree; print `commit or stash first`.
- Rebase onto `origin/dev` and say what moved.
## extra-checks
- Run `pnpm bundle:check` and quote its summary line.
## review-bar
- A child may not move to in review until a screenshot of every browse check is
attached to the issue.
## after-child
- Push the branch after each child, so the work is never only on this machine.
## after-tree
- Draft the changelog entry with rd-changelog and paste it into the parent.What it never does
It never closes an issue or moves one to done; in review is where a build ends. It never marks a child done from code alone. It never rebuilds a child that is already complete, and it never drags an issue backward through the workflow, with one exception: a child sitting in review whose promised surface is provably missing, which goes back to in progress and gets finished.