action-watchdog
Skill76 starsChanged 11 days agoMITView on GitHub
Independently fact-check the autonomous actions the system took (issue closes, labels, capture marks, etc.) against live ground truth, and alarm on any mismatch. Run on a schedule. This is what makes Band-A public actions safe.
In this repository13 other files it gives its agents.
- coding-principlesSkill
- contributor-trustSkill
- issue-autocloseSkill
- issue-captureSkill
- issue-close-proposalSkill
- issue-triageSkill
- label-syncSkill
- pr-deep-reviewSkill
- project-system-setupSkill
- pr-triageSkill
- release-announceSkill
- release-pipelineSkill
- triage-scoreboardSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
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
- Distinctive: line 75
Every autonomous public action in the system has a corresponding check here.
≈ “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
action-watchdog
When to load: auditing autonomous actions for correctness. Runs the watchdog pattern. Band A, deterministic, read-only. Build and enable this before promoting any public-write action to Band A.
Steps
- Read the action ledgers — the append-only records each action the system executes writes: what it closed, labeled or marked on its own, and the announcement posts a human keyed. The ledger is the list of what to check, never the evidence of correctness.
- Re-verify each action against LIVE ground truth, independently:
- Autonomous closes (
issue-autoclose): is the issue still closed? Is the cited PR actually merged and does it still link the issue? Does the cited release tag actually contain the merge commit? Was it reopened with a complaint? → any mismatch = 🔴. - Autonomous labels (
label-sync): for each ledger'd label, does it still match its source signal, is it within the declaredlabels:allowlist, and was it add-only — i.e. did the job avoid removing, reassigning, or overriding a human-applied label? → a mislabel, an out-of-allowlist label, or an overridden human label = 🟡 (a human's label always wins). - Announcements (
release-announce): does each ledger'd announcement correspond to a real release tag with merged content? Was each release posted to the fixed channel exactly once, countingbotandhandentries? Does eachbotpost match the changelog entry it claims to render? Ahandentry is a post a human wrote and recorded: check its release and its once-only, not its text. → a duplicate, or an announcement of an absent/unshipped release, or bot text that adds claims beyond the changelog = 🔴; a drifted last-announced marker = 🟡. - Autonomous capture marks (
issue-capture): for each ledger'd mark, does exactly one durable staged record and terminalcapturedevent exist for the same adapter + source item + target-repository key, and does the source carry exactly the configured marker? Did every vulnerability-diverted item receive no public mark? → a mark without a staged record, a missing/duplicate mark, or any public mark on a diverted item = 🔴; a stale nonterminal capture intent with no public action yet = 🟡. - Host closes (no ledger: the host acts on its own, and nothing in the system records it):
for each repository whose
host_closes_on_mergeisfalse, read what closed each issue closed since that repository's window opened. Keep each repository's window start in the watchdog's own private state. A repository with no recorded start (the first run, a repository added or switched fromtrue, or a lost record) opens its window now and reports that once as 🟡, since closes before then went unchecked: a no-model script can't tell those cases apart, so it treats them alike. While a repository is declaredtrue, drop its start, so switching it back opens a new window. On GitHub, read theClosedEvent'scloser. On GitLab, read the issue's resource state events (aclosedevent with asource_merge_request_idor asource_commit), and the project'sautoclose_referenced_issuessetting, which its API reports. On any other host (Gitea, Forgejo, or a self-managed instance), this check can't tell from the name which API the host speaks, so it reads nothing there: report once per window, as 🟡, that host closes can't be observed there. → an issue the host closed from a merge or a commit, or a GitLab setting that's on = 🟡: a human checks the repository's setting and decides about the issue. - (Add a check here for every new autonomous action — same change that adds the action.)
- Autonomous closes (
- Classify severities. 🔴 = correctness failure (an action was wrong — act now). 🟡 = drift (stale, reconcile soon).
- Report only on findings. Silent when all-clear. Route 🔴 to a human immediately; 🟡 to the reconcile queue. (Exception: a dedicated fleet-liveness heartbeat always reports, so its silence is the alarm.)
- Never fix anything. The watchdog verifies and surfaces; a human (or a separate, itself-watched action) fixes. An auto-fixing watchdog is just another unverified actor.
Pitfalls
- Independence is the whole point — re-derive correctness from live state, don't trust the action's own success report.
- Deterministic, no LLM where possible — it's comparing recorded actions to live data; no model means no injection surface and no nondeterminism.
- Don't let it page on every run — alarm fatigue defeats it. Silent-on-all-clear.
Verification
- Deliberately record a wrong action (in a test ledger) and confirm the watchdog flags it 🔴.
- On a repository declared
host_closes_on_merge: false, merge a PR that closes a test issue with the host's closing on, and confirm the watchdog flags it 🟡. - On a clean state, the watchdog is silent.
- Every autonomous public action in the system has a corresponding check here.
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.

