# From an idea to a pull request

> The seven workflow skills walked end to end on one real feature, with the commands and the tree they produced.

This is one real run, not an illustration. The feature is the skills pack you
are reading about: it was planned, prototyped, filed, built, verified and
shipped with these seven skills, against team `RAD` in a live workspace. The
excerpts below are trimmed for length; nothing is invented.

## The seven steps

<steps>

<step title="Set up, once per repo">

```bash
/rd-setup
```

Leaves `.radial/config.json` with your team key, a Radial block in `CLAUDE.md`
and `AGENTS.md`, and the pack installed. Re-running it changes nothing and says
so.

</step>

<step title="Plan: argue before you file">

```bash
/rd-plan "let users install our agent skills with one command, and document it"
```

Reads the repo, searches Radial for anything that already covers it, and writes
one parent plus a handful of children to `.radial/plans/<slug>.md`. Creates
nothing. What comes back in chat is a breakdown table and the open decisions.
This run had two, about where the pack should be sourced and how extensions
should be shaped, and both changed the plan.

</step>

<step title="Prototype: reject the design cheaply">

```bash
/rd-prototype
```

One self-contained HTML file with every screen and state, attached to the
parent. A reviewer clicks a Preview URL and says no in five minutes rather than
after the build.

</step>

<step title="File: the tree becomes real">

```bash
/rd-issues --start
```

Parent, children, the `blocked-by` edges, then a read-back of every issue. This
run produced six children under one parent with eight dependency edges: two
more than `rd-plan`'s usual two-to-four, because the tree spans two
repositories and each repo's half has to merge on its own.

</step>

<step title="Build, child by child">

```bash
/rd-build
```

Per child: in progress, build from the plan, check every acceptance line, run
the gate, drive that child's browse checks against the running app, post
implementation notes, move to in review.

</step>

<step title="Verify: read the summary line">

```bash
/rd-verify
```

Called per child by `rd-build` and again before the pull request. Runs each
command once to a log and quotes what it found.

</step>

<step title="Ship: one tree, one pull request">

```bash
/rd-pr
```

Branch named from the parent, base synced, commits, and a body whose sibling
issue ids are rewritten so the merge cannot close work nobody reviewed.

</step>

</steps>

## The tree it produced

```text
$ radial show RAD-374 --team RAD
RAD-374  Radial agent skills: open-source rd-* pack with extension hooks,
         radial skills CLI, and docs
  Status     In Review
  Labels     claude, Feature
  Sub-issues 6

  RAD-375  skill format, hook convention, manifest, guards, README
  RAD-376  workflow skills: setup, plan, prototype, issues, build, verify, pr
  RAD-377  hygiene skills: triage, cleanup, changelog, retro
  RAD-378  radial skills install|update|list|remove|extend + label flags
  RAD-379  /docs surface, agent twins, install + extending pages
  RAD-380  per-skill reference, walkthrough, issue body, conventions
```

Each child carries its own body with a goal, a file list and acceptance
criteria, each has an implementation-notes comment from the build, and the
whole tree ends in review. A human merges and closes.

## What you actually type

Only two of the seven take an argument. The rest read the state they need:

| Step | The whole command |
| --- | --- |
| Plan | `/rd-plan "<the idea, in a sentence>"` |
| File | `/rd-issues` or `/rd-issues --start` |
| Everything else | the skill name on its own |

<callout kind="note">

Nothing forces you through all seven. `/rd-plan` on its own is useful, and so
is `/rd-verify`. The chain is a default, not a contract.

</callout>