# 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 ## A worked wrapper ```markdown --- 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.