Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →blackbelttechnology/reverse-spec-from-code
Reverse-generate OpenSpec capability specs (openspec/specs/<cap>/spec.md) from code that lacks them, or reconcile an existing stale spec with `--refresh`, using parallel subagents. Fans out one blind generator per capability, audits each spec against the code for hallucinations, and promotes only on user confirm.
Passed 11 of 17 test cases with the skill, and 5 of 17 without it.
and 11 more in the full report
9 fixed6 passed either way7 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 9 test cases the skill fixed. Same model, same prompt, with and without the skill.
To save cost during spec auditing for packages/cart, we plan to assign the auditor subagent role to a lightweight model tier like @compact. What model tier should be assigned to the auditor subagent?
| Checked | Without skill | With skill |
|---|---|---|
| Assigns model @research to the auditor subagent | Missed | Passed |
The instructions your model reads when the skill loads.
Turn spec-less code into OpenSpec capability specs so kb_search has high-signal,
consistently-formatted behavioral documents to index. Tuned via a blind
generate→judge loop against 6 real specs: requirement coverage 97%, scenario
coverage 91% (see docs/research/reverse-spec-from-code.md for the tuning record
Scratch MUST live OUTSIDE
openspec/(kb indexesopenspec/). Use the gitignored repo-root dir.reverse-spec-scratch/— otherwise every draft polluteskb_searchwith duplicate spec chunks. Promotion MOVES the file intoopenspec/specs/(the only kb-indexed copy).
packages/ has behavior but no openspec/specs/<cap>/spec.md.kb_search (it indexes openspec/ markdown) with behavioral specs.--refresh).Skip for a single trivial file, or when the capability already has an accurate spec.
A capability's contract is not confined to one file. The single biggest
quality driver is making each generator FOLLOW the behavioral contract across
file boundaries: every emitted message/event, registry write, spawned/killed
process, config read, or DOM attribute is a contract with another component and
must be spec'd too. In tuning this moved requirement coverage from 40% to 95% on
the cross-cutting capability. The generator prompt (prompts/generator.md)
enforces this in STEP 1 — do not weaken it.
"Match an existing spec" is a PROXY, not the goal. Real specs drift from code. The goal is a spec that accurately describes current code and is searchable. Target: high requirement coverage + zero code-ungrounded hallucination. Code-current divergence from a stale spec is a win, not a miss.
test cases passed, vs 5 / 17 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.