nuncaeslupus/claude-arsenal

**A Claude Code marketplace for people who want the agent to work like an engineer.**
Specs before code. Failing tests before implementations. Acceptance gates with
numbers behind them. A task queue that several agents can work in parallel
without stepping on each other. And a meta-skill that holds every skill in your
repo — including its own — to a rubric drawn from published research.
---
Why this exists
Most agent setups fail the same four ways. This is what each of them is answered
with.
| The failure | The answer here |
|---|---|
| The agent writes code before anyone agreed what the problem was | **Spec-driven**: explore-idea → specify → design → execution → review → ship, each with its own output document |
| "Done" means the agent said so | **Gates with numbers**: a task's acceptance gate is a fenced block a script runs, against a committed measurement |
| Tests get written after the code, to fit it | **RED → GREEN → RECORD**: the check that proves the gate fails must fail first, for the expected reason |
| Skills that sound useful but never load | **A rubric and a validator**: 146 checkable rows, a mechanical pass, and a hook that blocks unguarded edits |
---
The four things you actually get
1. skill-workshop — a skill author that has read the literature
Writing a skill is easy. Writing one that *fires when it should*, doesn't
collide with its siblings, and doesn't quietly cost every session tokens it
never earns back — that's the hard part, and it has a research answer.
skill-workshop distills a 4,658-line research
archive — Anthropic's official skill
documentation, the anthropics/skills shipping repository, and academic sources
— into two rubrics it walks on every edit:
- **121 structural rows** (skill-rules.md) — frontmatter, naming, workspace topology, script CLI conventions, reference chunking.
- **25 content-quality rows** (content-quality-rules.md) — prose shape, trigger quality, example currency, and procedural shape.
That last one is grounded in measurement, not taste. Across ~8,100 agent trial
records, *procedural anchoring* — stable action sequences, setup steps,
verification routines — carried the large majority of cases where a skill
changed the outcome, while explicit knowledge injection carried a small minority
(Jiang et al., *Demystifying Agent
Skills*). So the rubric requires that every
step names how to confirm it worked. "Run the tests" fails the check; "run make
test; it exits 0" passes it.
Three things enforce it, in increasing order of teeth:
…and a **PreToolUse hook** that blocks an edit inside any skills/ folder unless
skill-workshop is loaded first. It keys on what a Bash command *writes*, not
what it mentions, so sed -i, tee, a heredoc and a python3 -c one-liner are
all covered — the routes a session naturally reaches for.
Rules that predict failures nobody has observed don't get to stay. Every row
traces to something that actually went wrong.
2. Spec-driven development, with documents you can hand to a human
explore-idea talks a vague idea into an agreed direction and a numbered
decisions log, one question at a time, and hands that log to specify. From
there each stage owns one artifact and one validator. specify produces the
problem analysis and options; design produces contracts, the task split, the
risk register, and the sequencing.
Both of them **publish an annotatable reader** before they report done — a
self-contained HTML page with a note field per section, notes auto-saving in the
browser and an Export button that writes them back out as Markdown. Re-run it
with those notes in hand and they land back in the document. A spec nobody read
is a spec nobody agreed to.
3. Test-first execution, and gates that hold a number
execution works each task through three motions:
- **RED** — write the check that proves the gate, and confirm it fails *for the expected reason*. A bug fix starts as a regression test; a metric gate starts as a measurement that misses the threshold.