Extending a skill

Your rules do not replace ours. They are added at named places inside a built-in, so you keep receiving updates to the skill and we never overwrite your conventions. That is the whole idea; everything below is mechanism.

What a wrapper is

A wrapper adds instructions that your agent interprets. Stage and gate names belong in pipeline configuration. Put requirements that must hold across every client in executable checks at the operation they govern; the workflow design guide explains that boundary.

An ordinary skill folder with one extra frontmatter field:

---
name: team-build
description: Our extra rules on top of rd-build, for the payments repo.
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.

## review-bar

- A child may not move to in review until a screenshot of every browse check is
  attached to its issue.

Save it at .radial/skills/team-build/SKILL.md to share it with the repo, or at ~/.config/radial/skills/team-build/SKILL.md to keep it to yourself.

Everything above the first ## heading is the preamble: a standing instruction for the whole run. Each ## <hook> section is applied at the matching point in the built-in.

Build it in four steps

1. 1
   Step 1.

   Scaffold it

   bash

   Copy

   radial skills extend rd-build --name team-build

   You get the folder, the frontmatter, and one ## heading per extension point, in the order they fire. Nobody has to memorise marker names.

2. 2
   Step 2.

   Fill in the sections you want, delete the rest

   An empty section is noise in the agent's context. Two filled sections beat eleven empty ones.

3. 3
   Step 3.

   Make it invocable, if you want it by name

   bash

   Copy

   radial skills install --project

   That copies the repo's wrappers into .claude/skills and .agents/skills alongside the pack, so /team-build works directly. Skip this and the wrapper still applies: rd-build looks for it at the start of every run.

4. 4
   Step 4.

   Check it fires

   Run the built-in and read the first few lines of the agent's output. A wrapper that applied says so. If it did not, the symptom table below names why.

Why extension points are named, not numbered

A hook is a place in the procedure with a name and a job: before-child is "before each child starts", review-bar is "the bar a child must clear to move to in review". Because you attach to the name, we can rewrite the paragraph underneath it and your rule still lands in the right place. A line number, or a copy of the whole skill with your edits in it, would break the first time we improved the sentence above yours.

Names ending in -bar are quality bars, and they are unique across the whole pack: there is exactly one review-bar, so a rule you write for it means the same thing in every repo you carry it to.

What a wrapper can and cannot do

When a section tries something it may not, the built-in follows its own procedure and says so in its output. You find out in the run, not in a diff.

Why isn't mine firing?

Where wrappers apply

The project scope (.radial/skills/) belongs in git. It is how a team's conventions travel with the repo and get reviewed like anything else. User scope (~/.config/radial/skills/) is for habits that are yours rather than the team's.

A repo with no wrappers runs the built-ins exactly as published, which is the right default and where everyone should start. Write a wrapper when you catch yourself telling your agent the same thing twice.