skill-author
The authoring gate for new skills. Routed to when the user invokes /new-skill "<gap>". Five gated phases — gap evidence, scope, authoring, self-review against the v2 house style, routing integration. A new skill is not written until an existing one is proven not to cover the gap,
Install
npx skills add https://github.com/arbiterForge/codeArbiter/tree/main/plugins/ca/skills/skill-author
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install arbiterforge-codearbiter@llmmart
git clone https://github.com/arbiterForge/codeArbiter.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole arbiterforge/codearbiter collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
skill-author
Author a new skill, the right way. Routed to when the user invokes /new-skill "<gap>".
Pre-flight
Read these, or STOP and surface the gap — never author on assumption:
- The
<gap>argument. Absent → STOP and ask: "Describe the gap this skill would fill. What situation does no existing skill cover today?" ${CLAUDE_PLUGIN_ROOT}/skills/INDEX.md— the surface scan of every existing skill. This is the gap-overlap check in Phase 1 and the integration target in Phase 5. Never bulk-read the skill bodies.${CLAUDE_PLUGIN_ROOT}/skills/commit-gate/SKILL.mdand${CLAUDE_PLUGIN_ROOT}/skills/tdd/SKILL.md— the canonical v2 format the authored skill must mirror. Read them before Phase 3.${CLAUDE_PROJECT_DIR}/.codearbiter/CONTEXT.md— project context, only if the gap is project-specific. A generic skill needs no project state.
Phase 1 — Gap evidence · gate: BLOCK
A new skill is permanent surface area. It is not written until the gap is proven real and proven uncovered.
Restate the gap in one sentence. Then scan INDEX.md for overlap: if an existing skill's "Owns" column already covers this, STOP and name it — "The <name> skill already owns this; review it before requesting a new one."
If no skill covers it, demand evidence — one of:
- A — three specific cases where the gap blocked work: what was attempted, what happened with no skill, what it cost.
- B — one high-impact case with traceable evidence: a blocked PR, an introduced defect, a compliance finding, a repeated failure pattern.
Hypothetical cases do not count. Fewer than three (Option A) or no traceable evidence (Option B) → STOP and decline: "Insufficient evidence of a real, recurring gap. A skill adds permanent maintenance cost. Return with evidence and I'll author it."
Gate: the gap is restated, proven uncovered against INDEX.md, and backed by Option-A or Option-B evidence. Speculation does not pass.
Phase 2 — Scope · gate: BLOCK
Settle scope with the user before any prose is written. Ask, and wait for an explicit answer:
- Routed or dispatched? A skill is routed to (gated phases, lives at
${CLAUDE_PLUGIN_ROOT}/skills/<name>/SKILL.md). An agent is dispatched by a skill (a reviewer/author, lives at${CLAUDE_PLUGIN_ROOT}/agents/<name>.md). If the gap is really a reviewer, this is the wrong skill — redirect to agent authoring. - Command-invoked or internal? Does a user type
/<name>to reach it, or does another skill route to it mid-workflow? A command needs a routing-table entry; an internal skill needs a named parent that routes to it. - Single responsibility. State the one thing the skill owns in a sentence. If it needs "and" to describe its job, it is two skills — split it or pick one.
Confirm back: "I will write a [command-invoked / internal] skill at ${CLAUDE_PLUGIN_ROOT}/skills/<name>/SKILL.md, owning
Gate: explicit user agreement on routed-vs-dispatched, command-vs-internal, and a one-sentence single responsibility. Assumed answers do not pass.
Phase 3 — Authoring · gate: BLOCK
Write SKILL.md to the v2 house style — mirror commit-gate and tdd exactly. Start from ${CLAUDE_PLUGIN_ROOT}/skills/skill-author/references/skill-template.md. Required shape:
- Frontmatter —
name:anddescription:only. Description is terse: what routes to it, the phase count, the gate. No cut doc refs, no trigger disclaimer. # <name>H1, then a one-line intro naming what routes to it (/<command>or the parent skill).## Pre-flight— the docs to read or STOP on. Project state cites${CLAUDE_PROJECT_DIR}/.codearbiter/<doc>; other skills cite${CLAUDE_PLUGIN_ROOT}/skills/<name>; agents cite${CLAUDE_PLUGIN_ROOT}/agents/<name>.md. Never guess a command — read it or STOP.## Phase N — <title> · gate: BLOCK|STOP— sequential, each ending in a one-lineGate:. A phase with output that could be wrong has a gate; only a purely declarative phase may omit one.## Hard rules—MUST NOTlines, one per rule, no duplication.
Authoring rules:
- Imperative, terse, no hedging. No "should", no "if it looks wrong". A gate is a concrete, checkable condition.
- Surviving project docs only:
CONTEXT.md,tech-stack.md,coding-standards.md,specs/,plans/,security-controls.md,decisions/,overrides.log. Do not reference cut docs or cut skills. - Terminology lock: a skill is routed to; an agent is dispatched. Never "trigger", "fires", or "runs".
- An out-of-scope finding gets one line with an inline
[NEEDS-TRIAGE]marker.
Phase 4 — Self-review · gate: BLOCK
Re-read the authored skill against the v2 quality bar. Each line below is a checkable defect, not a vibe:
- Single responsibility — the skill owns one thing. If a phase belongs to a different job, it is the wrong skill; cut it.
- Concrete gates — every non-declarative phase ends in a
Gate:line stating a checkable condition. "Looks good" / "seems right" is not a gate; rewrite it. - House-style prose — terse, imperative, matches
commit-gate/tdd. Strip hedging and filler. - No duplicated rules — a rule stated in a phase is not restated in Hard rules, and Hard rules carry no duplicates. State each rule once.
- Format conformance — frontmatter is
name+description, plusdisable-model-invocation: trueONLY on a chain-internal skill (never user-typed, reached solely via routing-table path loads — see ADR-0028); H1 matchesname; phases are numbered with· gate:; paths use${CLAUDE_PLUGIN_ROOT}/${CLAUDE_PROJECT_DIR}correctly; no cut docs/skills, no legacy${FRAMEWORK_ROOT}/${PROJECT_ROOT}/.agents/paths. - Frontmatter scalar quoting — any frontmatter scalar that starts with
[or{, or contains": "or" | ", MUST be JSON-quoted (the_yaml_safe_scalarpredicate the surface generator applies to codex/pi wrappers; the claude surface ships frontmatter verbatim, so the author quotes it at the source). - No trigger language — "routed to" / "dispatched" only, and no
## Triggerdisclaimer block. - Evidence lenses (issue #612) — each checked where the skill's shape triggers it, skipped where it does not:
- A gate an agent is tempted to skip carries a rationalization guard AT the decision point — the known excuses paired with rebuttals. The best rebuttal carries its own instrument: a check the agent can run that falsifies the excuse either way. A tempting gate with no guard is a defect.
- An acceptance or verification step names what is READ, never what is claimed — "the subagent reports green" is a defect; "the runner's output shows green" is not.
- A user-facing ask leads with a recommendation AND its strongest counter-consideration.
- A rule a tested helper could enforce is mechanized rather than accreted as prose — the helper enforces, the prose explains.
- A rule whose literal reading has an exploitable edge names what it protects.
- Behavior-changing gate revisions are validated, not assumed — an A/B pass (fixed scenarios, rubrics written before any output exists, both versions run under identical conditions) scaled to the change's blast radius, with results recorded in the PR (issue #612's method).
Compile the findings, fix each, and re-read once. Present the corrected skill and the findings list to the user.
Gate: zero open self-review defects, and the user has seen the corrected skill. An unaddressed defect blocks Phase 5.
Phase 5 — Routing integration · gate: BLOCK
A skill no one routes to is dead code. Wire it in.
- Add a row to
${CLAUDE_PLUGIN_ROOT}/skills/INDEX.md: skill name (linked), "Routed to by", and "Owns" (the one-sentence responsibility from Phase 2). - Add the skill to the routing table — the invocation cue (the
/<command>or condition), the primary route, any dispatched agents, the hard gate. For a command-invoked skill, also register the/<command>in the command reference. - For an internal skill, update the named parent so it routes to the new skill explicitly.
Verify no broken references: every path the skill cites resolves. INDEX.md row parity and routing-table dangling-route freedom are no longer a hand-check here — .github/scripts/check_routing_index_parity.py enforces both mechanically in CI (issue #592); a missing row, an orphan row, or a route to a name that does not exist fails the build.
Hand off to commit-gate — never git commit directly. The skill change ships only through the commit gate.
Gate: INDEX.md and the routing table updated, no broken references, and the change handed to commit-gate. CI's routing-parity check is the authority on row/route correctness, not a self-report.
Hard rules
- MUST NOT author a skill before the gap is proven uncovered against
INDEX.mdand backed by Option-A or Option-B evidence. - MUST NOT begin authoring without explicit user agreement on scope (routed-vs-dispatched, command-vs-internal, single responsibility).
- MUST NOT emit a skill whose phases lack concrete
Gate:lines, or whose Hard rules duplicate phase rules. - MUST NOT use trigger language ("trigger", "fires", "runs") or a
## Triggerdisclaimer — a skill is routed to, an agent dispatched. - MUST NOT reference a cut doc, cut skill, or a legacy
.agents//${FRAMEWORK_ROOT}/${PROJECT_ROOT}path in an authored skill. - MUST NOT ship a skill without an
INDEX.mdrow and a routing entry. - MUST NOT commit the new skill directly — hand off to
commit-gate.
Files (codearbiter)
-
references
-
skill-template.md 2.4 KB
--- name: <skill-name> description: <One terse sentence: what routes to this skill, the phase count, and the hard gate. No doc refs, no trigger disclaimer. JSON-quote the whole scalar if it starts with `[`/`{` or contains `": "` or `" | "`. Example: "The only path to X. Routed to when the user invokes /foo. Three gated phases — A, B, C. Nothing ships until every gate clears."> --- <!-- Chain-internal skill (never user-typed, reached only via routing-table path loads)? Add `disable-model-invocation: true` as a third frontmatter line — ADR-0028. --> # <skill-name> <One-line intro naming what routes to it: `/<command>` (user-invoked) or the parent skill (internal).> ## Pre-flight Read these, or STOP and surface the gap — never guess a command: - `${CLAUDE_PROJECT_DIR}/.codearbiter/<doc>.md` — <what it provides>. Stop if missing; do not guess. - `${CLAUDE_PLUGIN_ROOT}/skills/<other-skill>/SKILL.md` — <only if a sibling skill must clear first>. - `${CLAUDE_PLUGIN_ROOT}/agents/<agent>.md` — <only if this skill dispatches an agent>. ## Phase 1 — <title> · gate: BLOCK <Imperative description of what this phase does. Terse, no hedging.> Gate: <a concrete, checkable exit condition>. A partial result does not pass. ## Phase 2 — <title> · gate: BLOCK <...> Gate: <...>. ## Phase N — <title> · gate: BLOCK <Final phase. If the skill ends by persisting, hand off to `commit-gate` — never `git commit` directly.> Gate: <...>. ## Hard rules - MUST NOT <invariant, stated once — not duplicated from a phase>. - MUST NOT <invariant>. - MUST NOT guess a command — read the cited `.codearbiter/` doc or STOP. <!-- House-style reminders (delete before shipping): - Frontmatter is `name:` + `description:` only. - H1 matches `name`. One-line intro names what routes to it. - Each non-declarative phase ends in a one-line `Gate:`. - Paths: project state -> `${CLAUDE_PROJECT_DIR}/.codearbiter/<doc>`; skills -> `${CLAUDE_PLUGIN_ROOT}/skills/<name>`; agents -> `${CLAUDE_PLUGIN_ROOT}/agents/<name>.md`. - Surviving project docs only: CONTEXT.md, tech-stack.md, coding-standards.md, specs/, plans/, security-controls.md, decisions/, overrides.log. - Terminology lock: a skill is *routed to*; an agent is *dispatched*. Never "trigger", "fires", "runs". No `## Trigger` block. - Out-of-scope finding -> one line with inline `[NEEDS-TRIAGE]`. - Terse, imperative. No "should", no "if it looks wrong". -->
-
-
SKILL.md 10 KB
--- name: skill-author description: The authoring gate for new skills. Routed to when the user invokes /new-skill "<gap>". Five gated phases — gap evidence, scope, authoring, self-review against the v2 house style, routing integration. A new skill is not written until an existing one is proven not to cover the gap, and not shipped until it carries gated phases, hard rules, and a routing entry. Every authored skill matches the v2 format (frontmatter name+description, # name, Pre-flight, Phase N · gate, Hard rules). --- # skill-author Author a new skill, the right way. Routed to when the user invokes `/new-skill "<gap>"`. ## Pre-flight Read these, or STOP and surface the gap — never author on assumption: - The `<gap>` argument. Absent → STOP and ask: "Describe the gap this skill would fill. What situation does no existing skill cover today?" - `${CLAUDE_PLUGIN_ROOT}/skills/INDEX.md` — the surface scan of every existing skill. This is the gap-overlap check in Phase 1 and the integration target in Phase 5. Never bulk-read the skill bodies. - `${CLAUDE_PLUGIN_ROOT}/skills/commit-gate/SKILL.md` and `${CLAUDE_PLUGIN_ROOT}/skills/tdd/SKILL.md` — the canonical v2 format the authored skill must mirror. Read them before Phase 3. - `${CLAUDE_PROJECT_DIR}/.codearbiter/CONTEXT.md` — project context, only if the gap is project-specific. A generic skill needs no project state. ## Phase 1 — Gap evidence · gate: BLOCK A new skill is permanent surface area. It is not written until the gap is proven real and proven uncovered. Restate the gap in one sentence. Then scan `INDEX.md` for overlap: if an existing skill's "Owns" column already covers this, STOP and name it — "The `<name>` skill already owns this; review it before requesting a new one." If no skill covers it, demand evidence — one of: - **A** — three specific cases where the gap blocked work: what was attempted, what happened with no skill, what it cost. - **B** — one high-impact case with traceable evidence: a blocked PR, an introduced defect, a compliance finding, a repeated failure pattern. Hypothetical cases do not count. Fewer than three (Option A) or no traceable evidence (Option B) → STOP and decline: "Insufficient evidence of a real, recurring gap. A skill adds permanent maintenance cost. Return with evidence and I'll author it." Gate: the gap is restated, proven uncovered against `INDEX.md`, and backed by Option-A or Option-B evidence. Speculation does not pass. ## Phase 2 — Scope · gate: BLOCK Settle scope with the user before any prose is written. Ask, and wait for an explicit answer: - **Routed or dispatched?** A *skill* is routed to (gated phases, lives at `${CLAUDE_PLUGIN_ROOT}/skills/<name>/SKILL.md`). An *agent* is dispatched by a skill (a reviewer/author, lives at `${CLAUDE_PLUGIN_ROOT}/agents/<name>.md`). If the gap is really a reviewer, this is the wrong skill — redirect to agent authoring. - **Command-invoked or internal?** Does a user type `/<name>` to reach it, or does another skill route to it mid-workflow? A command needs a routing-table entry; an internal skill needs a named parent that routes to it. - **Single responsibility.** State the one thing the skill owns in a sentence. If it needs "and" to describe its job, it is two skills — split it or pick one. Confirm back: "I will write a [command-invoked / internal] skill at `${CLAUDE_PLUGIN_ROOT}/skills/<name>/SKILL.md`, owning <one responsibility>. [A `/<name>` command will be added to the routing table. / The `<parent>` skill will route to it.]" Gate: explicit user agreement on routed-vs-dispatched, command-vs-internal, and a one-sentence single responsibility. Assumed answers do not pass. ## Phase 3 — Authoring · gate: BLOCK Write `SKILL.md` to the v2 house style — mirror `commit-gate` and `tdd` exactly. Start from `${CLAUDE_PLUGIN_ROOT}/skills/skill-author/references/skill-template.md`. Required shape: - **Frontmatter** — `name:` and `description:` only. Description is terse: what routes to it, the phase count, the gate. No cut doc refs, no trigger disclaimer. - **`# <name>`** H1, then a one-line intro naming what routes to it (`/<command>` or the parent skill). - **`## Pre-flight`** — the docs to read or STOP on. Project state cites `${CLAUDE_PROJECT_DIR}/.codearbiter/<doc>`; other skills cite `${CLAUDE_PLUGIN_ROOT}/skills/<name>`; agents cite `${CLAUDE_PLUGIN_ROOT}/agents/<name>.md`. Never guess a command — read it or STOP. - **`## Phase N — <title> · gate: BLOCK|STOP`** — sequential, each ending in a one-line `Gate:`. A phase with output that could be wrong has a gate; only a purely declarative phase may omit one. - **`## Hard rules`** — `MUST NOT` lines, one per rule, no duplication. Authoring rules: - Imperative, terse, no hedging. No "should", no "if it looks wrong". A gate is a concrete, checkable condition. - Surviving project docs only: `CONTEXT.md`, `tech-stack.md`, `coding-standards.md`, `specs/`, `plans/`, `security-controls.md`, `decisions/`, `overrides.log`. Do not reference cut docs or cut skills. - Terminology lock: a skill is *routed to*; an agent is *dispatched*. Never "trigger", "fires", or "runs". - An out-of-scope finding gets one line with an inline `[NEEDS-TRIAGE]` marker. ## Phase 4 — Self-review · gate: BLOCK Re-read the authored skill against the v2 quality bar. Each line below is a checkable defect, not a vibe: - **Single responsibility** — the skill owns one thing. If a phase belongs to a different job, it is the wrong skill; cut it. - **Concrete gates** — every non-declarative phase ends in a `Gate:` line stating a checkable condition. "Looks good" / "seems right" is not a gate; rewrite it. - **House-style prose** — terse, imperative, matches `commit-gate`/`tdd`. Strip hedging and filler. - **No duplicated rules** — a rule stated in a phase is not restated in Hard rules, and Hard rules carry no duplicates. State each rule once. - **Format conformance** — frontmatter is `name`+`description`, plus `disable-model-invocation: true` ONLY on a chain-internal skill (never user-typed, reached solely via routing-table path loads — see ADR-0028); H1 matches `name`; phases are numbered with `· gate:`; paths use `${CLAUDE_PLUGIN_ROOT}` / `${CLAUDE_PROJECT_DIR}` correctly; no cut docs/skills, no legacy `${FRAMEWORK_ROOT}`/`${PROJECT_ROOT}`/`.agents/` paths. - **Frontmatter scalar quoting** — any frontmatter scalar that starts with `[` or `{`, or contains `": "` or `" | "`, MUST be JSON-quoted (the `_yaml_safe_scalar` predicate the surface generator applies to codex/pi wrappers; the claude surface ships frontmatter verbatim, so the author quotes it at the source). - **No trigger language** — "routed to" / "dispatched" only, and no `## Trigger` disclaimer block. - **Evidence lenses** (issue #612) — each checked where the skill's shape triggers it, skipped where it does not: - A gate an agent is tempted to skip carries a rationalization guard AT the decision point — the known excuses paired with rebuttals. The best rebuttal carries its own instrument: a check the agent can run that falsifies the excuse either way. A tempting gate with no guard is a defect. - An acceptance or verification step names what is READ, never what is claimed — "the subagent reports green" is a defect; "the runner's output shows green" is not. - A user-facing ask leads with a recommendation AND its strongest counter-consideration. - A rule a tested helper could enforce is mechanized rather than accreted as prose — the helper enforces, the prose explains. - A rule whose literal reading has an exploitable edge names what it protects. - **Behavior-changing gate revisions are validated, not assumed** — an A/B pass (fixed scenarios, rubrics written before any output exists, both versions run under identical conditions) scaled to the change's blast radius, with results recorded in the PR (issue #612's method). Compile the findings, fix each, and re-read once. Present the corrected skill and the findings list to the user. Gate: zero open self-review defects, and the user has seen the corrected skill. An unaddressed defect blocks Phase 5. ## Phase 5 — Routing integration · gate: BLOCK A skill no one routes to is dead code. Wire it in. - Add a row to `${CLAUDE_PLUGIN_ROOT}/skills/INDEX.md`: skill name (linked), "Routed to by", and "Owns" (the one-sentence responsibility from Phase 2). - Add the skill to the routing table — the invocation cue (the `/<command>` or condition), the primary route, any dispatched agents, the hard gate. For a command-invoked skill, also register the `/<command>` in the command reference. - For an internal skill, update the named parent so it routes to the new skill explicitly. Verify no broken references: every path the skill cites resolves. `INDEX.md` row parity and routing-table dangling-route freedom are no longer a hand-check here — `.github/scripts/check_routing_index_parity.py` enforces both mechanically in CI (issue #592); a missing row, an orphan row, or a route to a name that does not exist fails the build. Hand off to `commit-gate` — never `git commit` directly. The skill change ships only through the commit gate. Gate: `INDEX.md` and the routing table updated, no broken references, and the change handed to `commit-gate`. CI's routing-parity check is the authority on row/route correctness, not a self-report. ## Hard rules - MUST NOT author a skill before the gap is proven uncovered against `INDEX.md` and backed by Option-A or Option-B evidence. - MUST NOT begin authoring without explicit user agreement on scope (routed-vs-dispatched, command-vs-internal, single responsibility). - MUST NOT emit a skill whose phases lack concrete `Gate:` lines, or whose Hard rules duplicate phase rules. - MUST NOT use trigger language ("trigger", "fires", "runs") or a `## Trigger` disclaimer — a skill is routed to, an agent dispatched. - MUST NOT reference a cut doc, cut skill, or a legacy `.agents/` / `${FRAMEWORK_ROOT}` / `${PROJECT_ROOT}` path in an authored skill. - MUST NOT ship a skill without an `INDEX.md` row and a routing entry. - MUST NOT commit the new skill directly — hand off to `commit-gate`.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.