agentleFS
EtanHeyEtanHey/golems/.claude/skills/verify-lead-wait/SKILL.md

verify-lead-wait

Skill0 starsChanged 18 days agoApache-2.0View on GitHub

Verify PR ownership and eventual action when changing pr-loop's waiting policy, settle/handoff rules, or scripts/pr-sentinel. Rerun LeadWait and check its mapping to the source.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Every unheld red or green PR must eventually be fixed, merged, or visibly held.

    line 8
  2. Very specific:

    Read every result with pstack /statechart, including passes.

    line 30
  3. Distinctive:

    Keep the master sync separate until the candidate merges.

    line 41
  4. Distinctive:

    Before judging a changed source, diff these covered sections against the sync commit.

    line 51

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

Verify lead waiting

Every unheld red or green PR must eventually be fixed, merged, or visibly held. Otherwise a finished PR can remain unattended indefinitely. TLC checks event orderings in a finite model; the sentinel regressions check real Python behavior with fake external tools.

Run from the repository root

Install Bun, Python 3, Java 11+ and a tlc executable using tla2tools 1.7.4 (reports TLC2 2.19). Then run one command:

python3 .claude/skills/verify-lead-wait/verify.py

It runs the asserting source probe, sentinel tests and all six configs with one worker, retaining logs under docs.local/verify-lead-wait/. Exit 0 means the nonhistorical configs pass; exit 1 is the known SentinelOnly finding; exit 2 is any other violation, a source/probe regression or an unexpected checker result. Missing dependencies fail, never skip. Today, WakeIgnored and SettleWithoutHandoff must still demonstrate their historical violations. SentinelOnly must pass: after an ignored first nudge, an unchanged actionable PR is escalated to trusted orc. See results and reproduction.

Read every result with pstack /statechart, including passes. It draws the reachable states and explains counterexamples. Keep that skill's current commands and tooling in its own instructions. The committed chart records the present paths. Liveness counterexamples repeat forever; a finite prefix alone is not the bug.

Coverage and synchronization

Source sync commit: 13903d0573c78b708e5100d86771733f447ee4ab (master). That master revision lacked live-owner escalation. Candidate source sync commit: c284c10dbe72a3965df58a12e385e030313f4416 restores the second transition in source and model. Keep the master sync separate until the candidate merges.

Model surfaceSource coverage
EndTurnCheck, Act, SilentIgnoreskills/golem-powers/pr-loop/references/review-loop.md, Waiting policy: "Watching is not waiting", ordered end-turn cases; /pr-loop SKILL.md, draft-first inner loop
Handoff, SettleSame Waiting policy, "Ownership outlives the thread"; skills/golem-powers/pr-loop/references/dispatch-and-handoffs.md, handoff responsibilities
Hold, UnholdSame Waiting policy, "Held is visible, never silent"; sentinel classify only approximates this (it also skips ordinary drafts)
Sentinel, Nudgescripts/pr-sentinel/pr-sentinel: lead nudges once per head/class and escalates unchanged red/green/conflict after 2 h, scan escalates orphans; scripts/pr-sentinel/README.md, lead check and orc sweep
Source probesscripts/tests/pr-sentinel.test.mjs; docs/tla/lead-wait/reproduce.py replays the ignored-live-owner case

Before judging a changed source, diff these covered sections against the sync commit. Trace each changed transition, guard and fairness assumption to the source. A plain TLC pass cannot detect a source edit by itself. Move the sync commit forward only after checking that the model still describes that exact revision; record changes on top of master separately until they merge. Use /maintain-formal-verification-skill when bringing an old coverage record up to date.

Interpret and repair

Replay a counterexample against the real source in its action order. Use fake GitHub and T3 boundaries: do not send real messages for verification. A matching source trace is a real finding; report it without weakening Noticed. An impossible step, wrong atomic boundary, or unsupported fairness premise is a modeling error: correct the mapping, retain the finding history, and rerun every config. Intended behavior changes require both the source change and corresponding model update.

Scope: one PR, one lead and trusted orc; nudges bounded to 0..2. Sentinel-on also assumes a configured escalate_thread. Missing optional config leaves nudges working but disables orc escalation; the configured-sentinel proof does not cover that mode. CI, action, unhold and nudge have weak fairness. No clock, timer deadline, network outage, delivery, scheduler liveness, review approval, or successful fix/merge is proved. Handoff is an abstract outcome, not an atomic watch-transfer implementation. Passing TypeOK only checks domains. A merged terminal state intentionally has no next action, so the rerun command disables deadlock checks.

To prove the command is sensitive to real source changes, save the sentinel file, temporarily disable orphan escalation in scan, and rerun. The source regressions must fail (exit 2). Restore the exact bytes in a finally block and rerun: only the historical counterexamples may remain and all current configs must pass. Never commit the scratch mutation.

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.