agentleFS
yiyaw-labyiyaw-lab/agent-armor/until/SKILL.md

until

Skill1 starsChanged 5 months agoMITView on GitHub

Goal-pursuit engine — attempt, verify, adjust until a pinned objective is verifiably done. Negative-control verification, a hypothesis ledger that forbids re-testing refuted ideas, git checkpoints, and a forced escalation ladder (switch layers → fresh-context subagent → attack the goal itself). Survives session death via a state file. (For time-based recurrence, use the built-in /loop instead.)

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 2 are distinctive, and 0 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.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Negative control: run the check BEFORE doing any work: If it already passes, the goal is mis-pinned — stop and re-pin.

    line 10
  2. Distinctive:

    NEVER weaken the check mid-run.

    line 11

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

You are in goal-pursuit mode. You do not end your turn until the objective is VERIFIED accomplished or a stop condition fires. "Should work now" is not a stopping state.

Step 0 — Pin the goal, then prove the check can fail

  • Restate the objective as a binary, observable check: a command's exit code, a file's state, a passing test, a visible behavior. If $ARGUMENTS contains -- <verify>, that IS the check. max=N caps iterations (default 10).
  • Negative control: run the check BEFORE doing any work. If it already passes, the goal is mis-pinned — stop and re-pin. A check that can't fail can't verify anything.
  • NEVER weaken the check mid-run. The check pinned here is the check you finish on.
  • Create the state file .claude/until/<goal-slug>.md in the project: the pinned check, the brief (what's known, what's ruled out), and the ledger below. Update it EVERY iteration — this is what makes the pursuit survive compaction, crashes, and session ends. /until resume = read the newest state file and continue from its ledger, not from scratch.

The hypothesis ledger

Maintain in the state file: | iter | hypothesis | layer | action | check result | status: REFUTED / CONFIRMED / UNTESTED |

  • One hypothesis per iteration, falsifiable, named BEFORE acting.
  • A REFUTED hypothesis is dead. Re-testing it is forbidden — variants count as re-tests unless you can say what evidence distinguishes them.
  • Tag each hypothesis with its layer: code | config | environment | dependency | data | assumption. You'll need this for escalation.

Each iteration

  1. Checkpoint — before any risky change: a WIP commit, or git stash push ONLY in a tree where every piece of dirt is your own — never in a tree carrying a peer's/foreign dirt (a stash there silently swallows their in-progress work; the S38 parallel-build near-miss). A failed fix must be rolled back, not layered under the next fix. Compounding half-fixes is how loops corrupt the workspace.
  2. Act — smallest change that tests the hypothesis.
  3. Verify — run the pinned check for real; capture output. A pass must be reproduced once (re-run, clean state if cheap) before you trust it — flaky passes are how loops end in false victory.
  4. Record — update the ledger + state file. Failed experiment? Roll back to checkpoint before iterating.

The escalation ladder — strategy shifts are forced, not optional

  • 3 consecutive REFUTED in the same layer → that layer is probably innocent. Next hypothesis MUST come from a different layer.
  • 5 consecutive REFUTED → your context is now part of the problem: you're anchored on dead hypotheses. Write a clean brief (symptom, check, ledger summary, what's ruled out — NOT your theories) and spawn a fresh-context subagent on it. Its naivety is the asset; do not contaminate the brief with your favorite suspect.
  • 7 consecutive REFUTED → attack the goal itself: spawn an adversarial subagent to argue the check is testing the wrong thing, the bug is upstream of where you're looking, or the objective hides a false assumption. If it lands, re-pin WITH THE USER (this is the one allowed check change — explicit, never silent).
  • Cap reached → write the handoff: state file finalized, brief sharpened, "what I'd try next" listed. A future /until resume — yours or another agent's — starts from iteration N, not zero.

Stop conditions — never declare false success

  • ✅ Check passes, reproduced → report what worked + verifying output.
  • 🛑 Thrashing: no new falsifiable hypothesis exists in any layer.
  • 🛑 Cap (default 10).
  • 🛑 User-blocked: needs credentials, a decision, money, or hardware only the user has — name it precisely.
  • 🛑 Diminishing returns on a subjective/scored check — when the verifier is a graded judge/panel, not a binary pass, its score is ASYMPTOTIC: it plateaus and the all-high bar may never cleanly fire. Track the score delta per iteration; when it flattens (~2 iterations of marginal gain), STOP and surface the plateau + best result + any anchor-conflict as a fork for the user. Cap the expensive judge cadence to every 2-3 iterations, not every one. (Banked from a /until loop that ran ~10 panels / ~3.7M tokens against an asymptotic bar.)

Final report

✅ or 🛑 · the verified evidence (real output, not paraphrase) · iterations used · the ledger · state-file path. On 🛑: the exact resume command.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.