Install any skill in seconds. Free to start, no credit card required.
Get Started Free →cyrillemat/temper-skills
Give an agent skill's decision logic a test suite and a deterministic implementation — a labeled validation dataset plus versionable Python — by driving the installed temper-skills CLI (never reimplementing the logic in prose). Use in agents without a native subagent primitive (Cursor, Hermes, generic tools) when the user wants to test, eval, audit, temper, freeze, or harden the routing/decision logic of a prompt, skill.md, or playbook ("test my skill", "what is this skill deciding?"), including
Passed 8 of 14 test cases with the skill, and 4 of 14 without it.
and 13 more in the full report
9 fixed4 passed either way7 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
When exporting the distilled skill, what unit test file is generated alongside the decision tree script to verify current tree behavior?
| Checked | Without skill | With skill |
|---|---|---|
| The exporter generates a behavior lock test script named test_<module>.py. | Missed | Passed |
| The generated behavior lock test passes against current tree outputs. | Missed | Passed |
The instructions your model reads when the skill loads.
Turn the decision logic living in a prompt/skill.md into a deterministic Python
decision tree — readable, diffable in a PR, zero LLM calls at inference. You (the
orchestrator) act as the proposer; persona subagents are the adversarial
reviewers. Everything runs on the user's Claude Code subscription via the Task tool.
"Adversarial" here means decision robustness — challenging business logic — not security scanning. The loop measures internal consistency, not correctness against the world; real correctness still comes from the user's ratified examples.
You make the decisions; the loop is the point. The schema and the tree co-evolve — you start from a naive schema + a naive tree and let the loop grow and prune both. There are exactly two human touchpoints, and no others:
quick). The only mid-run block.There is no up-front schema gate. Seed a naive schema yourself and start the loop; the
schema_critic grows it, the outcome_critic flags a too-coarse outcome set, and the
overengineering_critic + the earn-a-branch guard prune what doesn't earn its place. The schema
is a loop output, reviewed at the end (it's the caller's integration contract), not a
pre-commitment.
For everything else, decide and record — do not ask. Specifically, never raise an
AskUserQuestion / multiple-choice modal to have the user choose feature breadth, whether to
keep/drop a branch or feature, how to resolve a gray zone, or any "which design do you prefer"
question. Those are the loop's job: the critics grow/prune, and you resolve gray zones with the
safest defensible default and record them (see Gray zones). If you catch yourself about to
open a question modal for anything other than the per-round gate: stop, make the defensible call,
record it, and keep going.
skill.md / prompt (the logic to migrate), path given by the user.
If the path is a directory (a skill library), do not start the loop: audit eachtest cases passed, vs 4 / 14 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.