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

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.