Resonance skill author
Skill manusco/resonance/.agents/skills/ops/skill-author/resonance-skill-author
Authors, audits, and hardens Resonance skills with the Forge compiler. Use when building a new skill, converting a workflow into a procedure skill, writing or fixing a skill description or frontmatter, shrinking a bloated SKILL.md, adding evals, or running the skill validator. Covers all three archetypes (knowledge, procedure, orchestration) and emits per-tool, per-model output.From its SKILL.md
npx -y skills add manusco/resonance --skill resonance-skill-authorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
5.8 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it
/resonance-ops-skill-author: forge a skill to the gold standard
Role: the meta-skill. It builds the other skills. Input: a capability gap, a task the agent does poorly or re-explains every time. Output: a skill template in
.forge/skills/<name>/, compiled toSKILL.md, with >= 3 evals, passing the validator. Definition of Done:python .forge/validate_skill.py <out>is clean,>= 3eval cases exist, and the skill closes a gap proven by a baseline run.
You do not write prose and hope. You build the way you would build software: prove the gap, write the minimum, validate, eval, commit atomically. A skill that ships unmeasured is a liability, not an asset.
Prerequisites (fail fast)
- You can name the gap in one sentence and give a concrete example task. If you cannot, stop and ask the user for one.
- You know the archetype (see step 2). If the request is "make X better," first decide whether X is knowledge, procedure, or orchestration.
Algorithm
Copy this checklist and tick items as you go.
- Prove the gap (eval-first). Run the target task without a skill. Record where the model fails or what you keep re-explaining. This is the baseline. No gap, no skill. → verify: you have a written baseline failure.
- Choose the archetype. → verify: one of:
- knowledge: a domain expert applied inline (copywriter, architect). Auto-loaded.
- procedure: a gated, multi-step job with a Definition of Done (build, ship). Invoked as
/name; mark manual-only if it has side effects. - orchestration: a procedure that drives other skills/subagents (audit swarm, review pipeline). See skill_spec.md for the contract each one must satisfy.
- Write the golden evals first. Create
>= 3cases inevals/(query+expected_behaviorrubric). Cover the happy path, an edge case, and a failure the skill must prevent. See eval_protocol.md. → verify: 3 files inevals/. - Write the minimum skill. Start from the matching template in
.forge/templates/. Add only what the model does not already know (see degrees_of_freedom.md). Nail thedescriptionfirst, it is what makes the skill trigger (see description_patterns.md). Push fragile, deterministic steps intoscripts/, not prose (see script_authoring.md). → verify: body is lean, references one level deep. - Compile.
python .forge/forge.py build <name>(add--host allto emit every tool,--model <m>to target a model). The Forge injects shared sections (voice, decisions, completion) so you never hand-copy them. → verify: output written. - Validate (the gate).
python .forge/validate_skill.py <output-path>. Fix every ERROR and every warning you can before continuing. This is your Definition of Done check. → verify: validator clean. - Eval. Run the skill against the golden cases (with vs. without). It must beat the baseline from step 1. → verify: measured improvement.
- Commit atomically (the Iron Contract). Only after validate + eval pass, write the skill into place and tell the user what landed. If anything failed, discard and report; there is no "almost shipped" state.
- Iterate (Claude A / Claude B). Author with this instance; test with a fresh one on real tasks. Bring its failures back as edits to the template, never to the generated output. Regenerate.
Recovery
- Validator reports ERRORs you cannot resolve → the skill is not done. Report the specific check and stop; do not ship a failing skill.
- Eval does not beat baseline → the skill adds tokens without value. Cut it back or kill it.
- Asked to edit a generated
SKILL.mddirectly → refuse. Edit the template in.forge/skills/<name>/and recompile. Generated files carry a "do not edit" banner. - Tried to fix a failing skill 3 times without success → stop, show the eval output, escalate.
What good looks like
- The
descriptionsays what it does AND when to fire, in third person, under 1024 chars. - The body is an overview that points to references; it is not a wall of text.
- A procedure skill states Input, Output, Definition of Done, Recovery.
- Fragile steps are scripts with real error handling, not hopeful prose.
- Three evals exist and pass. The validator is clean.
Out of scope
- Writing application code (delegate to resonance-backend / resonance-frontend).
- Writing marketing copy (delegate to resonance-copywriter).
- Inventing a new file format. The output is a SKILL.md; the Forge owns how it is generated.
Operating Standard
Apply the Resonance operating standard from AGENTS.md (always loaded): the builder Voice and its banned-word list (no AI slop, no em dashes), Recommendation-First decisions (models recommend, the user decides), the Completion protocol (end with DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT, backed by evidence, escalate after 3 failed tries), and the Ratchet (record durable learnings in the project memory, .resonance/02_memory.md, which loads at session start).
Model note (Claude): Strong native reasoning. Do not narrate "let me think step by step" or pad with chain-of-thought; think, then act. Prefer the dedicated file and search tools over shell. State assumptions briefly, then proceed.
What ships with it: 9 files
13.4 KB alongside SKILL.md
evals/
references/
- degrees_of_freedom.md1.6 KB
- description_patterns.md1.8 KB
- eval_protocol.md2.0 KB
- script_authoring.md1.7 KB
- skill_spec.md3.2 KB
Gives 0 of the 12 instructions most ship operate skills give in ~1.3k tokens
Counted across 1,077 of the 1,713 authors here whose files we hold, read 2026-09-06
- Create GitHub releasein 44 of 1077, across 43 files
- Run the test suitein 30 of 1077, across 25 files
- Create and push git tagin 27 of 1077, across 26 files
- Push commits and tagsin 27 of 1077
- Create annotated tagin 25 of 1077, across 22 files
- Ensure working tree is cleanin 24 of 1077
- Check for product marketing context firstin 23 of 1077, across 6 files
- Commit version bump changesin 22 of 1077, across 21 files
- Update CHANGELOG.mdin 21 of 1077, across 20 files
- Structure launch marketing across three channel typesin 20 of 1077, across 5 files
- Commit and tag the releasein 20 of 1077, across 18 files
- Update the CHANGELOG for new releasesin 19 of 1077
Said here and by no other author read
- Prove the gap before writing a skill.
- Write the golden evals first.
- Compile the skill.
- Validate the skill output.
- Run the skill against golden cases.
- Commit atomically after passing checks.
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.