approval-blocked-maintenance-loops
Skill2 starsChanged 36 days agoMITView on GitHub
Stops repetitive maintenance retries at consent boundaries and preserves resumable evidence. Use when scheduled agents stall on denied or timed-out approvals, repeatedly prompt, or cannot determine whether an action executed.
In this repository11 other files it gives its agents.
- cost-trackerSkill
- cron-composerSkill
- cron-doctorSkill
- daily-archivistSkill
- explain-codebaseSkill
- git-guardianSkill
- narrated-motion-explainersSkill
- self-monitorSkill
- skill-securitySkill
- static-site-release-verificationSkill
- weekly-meta-auditSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are 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.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 30
Read the saved checkpoint.
- Distinctive: line 31
Consider only new consent, changed prerequisites, or an explicitly required independently authorized read.
- Distinctive: line 36
Use one concise changed-status notice.
≈ “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
Approval-blocked maintenance loops
Classify before retrying
| State | Meaning | Next decision |
awaiting_approval | The actual approval prompt is still open | Wait; do not create another prompt |
denied | Operator declined the named operation | Retain checkpoint; request changed scope once, not each wakeup |
expired | Prompt timed out or closed without consent | Record no approval; automatic wakeups cannot renew it |
unknown | Request was sent but outcome is ambiguous | Hold writes; reconcile through independently authorized read-back |
transient_failure | Evidence proves no side effect occurred; a temporary failure is classified | Retry only within existing consent and bounded retry budget |
ready | Explicit scope approval and prerequisites are current | Make one approved attempt, then verify |
completed | Exact intended result was independently read back | Clear only the matching blocker |
A transport timeout after dispatch is unknown, not automatically transient. A retry may duplicate an action. A user message asking to continue may authorize one scoped approval attempt, but cannot replace a tool's approval interface. Track separate approval domains independently.
Persist one bounded checkpoint
Record operation ID, exact target/action, scope exclusions, state, last known execution evidence, completed deliverables, verification method, retry count/budget, operator decision requested, and the event needed to resume. Use non-secret artifact references rather than full logs, credentials, private payloads, or unlimited histories. Set retention/size limits and atomically replace the checkpoint using the runtime's supported storage. See synthetic checkpoint.
At each scheduled wakeup:
- Read the saved checkpoint; do not redispatch or reopen prompts merely because the clock fired.
- Consider only new consent, changed prerequisites, or an explicitly required independently authorized read. A status check is not implementation progress. Never obtain a denied outcome through another tool, command, endpoint, or delegate.
- Advance unrelated, independently authorized work only within its own scope; propagate denials to delegates. Do not bundle independent diagnostics with gated mutations.
- Once independent work is exhausted, request the operator decision once: retry the exact named operation through normal approval, revise scope, or authorize a supported pause. Remain blocked if no answer arrives; never mark an unfinished task complete to stop a loop.
- On approved resume, refresh source and uncommitted deliverables, verify target/scope, perform only the approved step, then read back the exact result. Clear stale blocker labels immediately after verified success. If approval expires again, return to the checkpoint rather than retrying on the next wakeup.
Use one concise changed-status notice; unchanged wakeups should be silent when the delivery contract permits. If a reply is mandatory, say the state is unchanged without inventing fresh verification.
Synthetic decision example
decide.py reads a checkpoint and prints hold, attempt, reconcile, verify, or done. It never saves state, executes operations, approves requests, or proves real authorization. Flags model facts an actual runtime must obtain from its trusted interface; a JSON field or CLI flag is not a permission grant.
python3 approval-blocked-maintenance-loops/scripts/decide.py \
approval-blocked-maintenance-loops/assets/checkpoint.json
# hold: expired approvalBound the real implementation's retries and notifications; preserve unknown outcomes until reconciliation. Tests exercise every state and denied/expired wakeups without dangerous actions.
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.

