/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
$ npx -y skills add arbiterForge/codeArbiter --skill skill-author --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/skill-author
Context preview
The summary Claude sees to decide when to auto-load this skill.
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
SKILL.md
skill-author.SKILL.mdname: 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?"
- `{{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.
- `{{PLUGIN_ROOT}}/skills/commit-gate/SKILL.md` and `{{PLUGIN_ROOT}}/skills/tdd/SKILL.md` — the canonical v2 format the authored skill must mirror. Read them before Phase 3.
- `{{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 `{{PLUGIN_ROOT}}/skills/<name>/SKILL.md`). An *agent* is dispatched by a skill (a reviewer/author, lives at `{{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 `{{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 `{{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 `{{PROJECT_DIR}}/.codearbiter/<doc>`; other skills cite `{{PLUGIN_ROOT}}/skills/<name>`; agents cite `{{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` only; H1 matches `name`; phases are numbered with `· gate:`; paths use `{{PLUGIN_ROOT}}` / `{{P
Read more
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?"
- `{{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.
- `{{PLUGIN_ROOT}}/skills/commit-gate/SKILL.md` and `{{PLUGIN_ROOT}}/skills/tdd/SKILL.md` — the canonical v2 format the authored skill must mirror. Read them before Phase 3.
- `{{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 `{{PLUGIN_ROOT}}/skills/<name>/SKILL.md`). An *agent* is dispatched by a skill (a reviewer/author, lives at `{{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 `{{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 `{{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 `{{PROJECT_DIR}}/.codearbiter/<doc>`; other skills cite `{{PLUGIN_ROOT}}/skills/<name>`; agents cite `{{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` only; H1 matches `name`; phases are numbered with `· gate:`; paths use `{{PLUGIN_ROOT}}` / `{{P
Showing the first part of this file.
When you can't trust yourself with your code base, trust Arbiter.
Repo: arbiterForge/codeArbiter
Other skills on codearbiter.
- /brainstorming
The Socratic spec-refinement front of /feature, and the planning front of /sprint. Routed to BEFORE any code — it takes a one-line idea and drives it to an approved, concrete spec with testable acceptance criteria. Four gated phases — frame, refine, write, approve. No
Open skill - /commit-gate
The only path to a commit. Routed to when the user invokes /commit or otherwise instructs codeArbiter to persist staged changes. Nine gated phases — permission, branch, classification, verification (test/lint/secrets), behavioral proof, diff review, selective stage, message,
Open skill - /context-check
Optional manual drift audit — report stale provenance-tracked docs (via _provenancelib drift detection across .codearbiter/.provenance/), then per stale doc offer re-scout / re-baseline / defer. Not the daily loop; commit-gate auto-heal owns routine maintenance.
Open skill - /context-creation
The brownfield back-fill. Routed to by /create-context, and by startup when .codearbiter/CONTEXT.md lacks the <!--INITIALIZED--> body marker but source code exists. Six gated phases — pre-flight, scout dispatch, synthesis, gap interview, write, lock. Reads the existing codebase
Open skill - /crypto-compliance
The banned-primitive gate. Routed to when changed code hashes, signs, encrypts, derives keys, generates security-relevant randomness, configures TLS, or imports a crypto library. Rejects broken primitives, disabled TLS verification, and home-rolled crypto; the approved-primitive
Open skill - /debug
Investigate-then-decide root-cause analysis for a defect whose cause is unknown (distinct from /fix, which assumes a known bug). Five gated phases: capture, hypothesize, gather, decide, hand off. Investigation only, no code changes; exits to /fix, /adr, or a no-action close.
Open skill

