fixed-interrupt
Skill3 starsChanged 18 days agoApache-2.0View on GitHub
Two chasers alternate in tenures of k accepted experiments, scored by a trusted evaluator command the orchestrator runs; at the end a blind reviewer (identities and scores hidden) picks the winner. For tasks with a measurable score. Run with /baton:fixed-interrupt "<task>" --eval "<cmd>".
In this repository17 other files it gives its agents.
- author-flowSkill
- cleanup-flame-chaseSkill
- cleanup-ralphSkill
- continue-loopSkill
- flame-chaseSkill
- flowsSkill
- gen-ideaSkill
- gen-planSkill
- goalSkill
- parallel-chase-prSkill
- parallel-chaseSkill
- protocolSkill
- ralph-loopSkill
- recursive-lean-proverSkill
- rlarSkill
- rlcrSkill
- stateful-ralphSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 25
If --eval is missing, ask the user for it and stop.
- Distinctive: line 56
Commit and evaluate in one call, with a neutral commit message (the blind reviewer reads commit messages, so no role in it):
- Very specific: line 65
When accepted_in_tenure reaches k, hand the tenure to the other chaser and reset the count.
- Distinctive: line 69
When the budget ends (turns, or minutes minus the reserve):
- Very specific: line 84
Create the branch baton/<run-id>-winner at the winner's commit, and write review.json and result.json in the run directory.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
fixed-interrupt
Arguments: $ARGUMENTS
Load the run protocol first (Skill tool → baton:protocol; if that fails, Read ${CLAUDE_PLUGIN_ROOT}/skills/protocol/SKILL.md) and follow it. This file only adds what is specific to fixed-interrupt.
Idea
Alternate on a fixed schedule instead of every turn: one chaser holds the tree for k accepted experiments, then the other takes over. Only the trusted evaluator decides what counts as an accepted experiment, and the final choice comes from a blind review by the side that didn't write the latest accepted candidate.
Flags
--eval "<cmd>"(required): run from the repository root, exit code 0, and print the score as a number on the last line of stdout. A run that exits non-zero or prints no number is rejected.--goal max|min: whether a higher or a lower score is better. Defaultmax.--k N: accepted experiments per tenure, default 5.--review-reserve M: with--minutes, stop starting turns when fewer than M minutes are left, so the review has time. Default 15.
If --eval is missing, ask the user for it and stop.
Roles
| Role | subagent_type | Model | Stance | Session |
| chaser-a | baton:chaser-a | chaser A model | chaser A stance | fresh every turn |
| chaser-b | baton:chaser-b | chaser B model | chaser B stance | fresh every turn |
| blind reviewer | baton:reviewer | the model of the chaser opposite the author of the latest accepted candidate | none | fresh, once |
chaser-a holds the first tenure. Pass the evaluator as the eval: line of start and {"goal": ..., "k": ...} as its options: line (protocol); together they are the run's contract. Keep in state.extra: holder, accepted_in_tenure, candidates (list of {label, commit, author, score}) and best; write it only when a candidate is accepted or the tenure changes.
Turn prompt
BATON fixed-interrupt · turn <n>/<max> · role <holder> · run <run-id>
TASK:
<task, verbatim>
STANCE (<stance name>):
<stance paragraph>
CONTRACT: the trusted evaluator is `<eval>` (goal: <max|min>). You may run it while you work, but only the orchestrator's run after your turn counts.
STATUS: accepted this tenure <a>/<k> · best so far <score or "none"> · last submission: <accepted with <score> | rejected: <one-line reason> | none>
You start fresh; the workspace is the only handoff. Make one experiment: one coherent change you expect to improve the score. Leave it in the workspace and report.After each turn
- Commit and evaluate in one call, with a neutral commit message (the blind reviewer reads commit messages, so no role in it):
Skip thesh "${CLAUDE_PLUGIN_ROOT}/scripts/baton.sh" turn <run_dir> t<n> <holder> <status> -m "baton(fixed-interrupt): t<n>" <<'EOF' <summary> EOF sh "${CLAUDE_PLUGIN_ROOT}/scripts/baton.sh" eval <run_dir> t<n> --beat <best or none> --goal <goal>evalline when the turn wasempty: an empty turn is not a submission. evalprinted a score: the submission is accepted. Add candidateC<i>with this commit, its author and score, updatebestwhen it beats it, and add one toaccepted_in_tenure.rejected (...): the reason and the two log lines it printed arelast_resultfor the next prompt.- When
accepted_in_tenurereaches k, hand the tenure to the other chaser and reset the count.
Blind review
When the budget ends (turns, or minutes minus the reserve):
- With fewer than two accepted candidates, the winner is the only candidate, or there is none.
- Otherwise spawn the blind reviewer once, with this prompt:
The reviewer may only nominate an existing candidate.BATON fixed-interrupt · blind review · role reviewer · run <run-id> TASK: <task, verbatim> CANDIDATES: <labels in shuffled order, each with its commit sha> Inspect each with `git show --stat <sha>` and `git diff <base> <sha>`. Don't run the evaluator and don't look for scores; judge which candidate best does the TASK. Add the line "nominate: <one label from the list>" or "nominate: none".none, a missing line, or an unknown label keeps the standing candidate (the best score). There is no retry. - Create the branch
baton/<run-id>-winnerat the winner's commit, and writereview.jsonandresult.jsonin the run directory.
Final report additions
A table of the candidates with commit, author and score, the nominee, the winner, and the winner branch.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

