skills/claude-code-audit-workspace/iteration-1/eval-1-direct-audit-request/with_skill/outputs/audit/drafts/skills/autonomous-governor/SKILL.md
Install session-level guardrails when the user hands off to autonomous overnight execution. Fires when the first user prompt contains "going to bed", "headed to sleep", "full autonomy", "overnight", "continue as you were", or similar handoff-to-autonomy language. Enforces commit-per-slice, halt-on-3-consecutive-errors, max-wall-time cap, and a wake-time summary block. Exists because audited overnight sessions showed 348 Bash calls and 9 tool errors with no structural brake — the user explicitly acknowledged errors were happening and told Claude to keep going, which is exactly the moment guardrails must exist in config instead of in the user's head.
npx skillsauth add petekp/claude-code-setup autonomous-governorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
The audit found 4/25 sessions that began with "I'm going to bed, please continue autonomously." These sessions had the highest tool counts (348+ Bash calls), highest error counts (7-9 errors per session), and the most accumulated technical debt. The user is explicitly off-shift during these runs; nothing in the config sets a budget or a halt threshold, so the machine just keeps trying until morning.
This skill sets the budget.
Fire when the first user prompt contains any of these phrases (case-insensitive):
going to bedheaded to sleep / off to sleep / heading to bedfull autonomy / autonomous mode / autonomy modeovernight + continuation languagecontinue as you were + trust languagedrive this forward + break languageI'm going to sleepDo NOT fire on mid-session requests for autonomy. This is a session-opener-only skill because the governor rules need to apply to the whole session.
Announce these rules back to the user in the first response (one line each), then proceed:
Commit-per-slice. After each logically complete slice (feature, fix, or discrete refactor), commit. Never carry more than one slice of uncommitted work. This protects against a bad middle-of-night commit swallowing earlier good work.
Halt-on-3-errors. If you get three consecutive tool errors without a successful intervening action, STOP. Save a continuity record with a clear "halted by governor — N consecutive errors on X" debt marker. Do not keep retrying past 3.
Amend cap. If you must git commit --amend to fix errors, amend at most twice per slice. Third amendment means roll the slice back and reconsider — do not stack amendments all night.
Wall-time cap (default 6 hours). If the session has run longer than 6 hours of assistant wall-clock, save a continuity record and stop. The user will wake up; resume is cheap.
Wake-time summary. Before your final stop, emit a single plain-text summary block the user can read in 15 seconds:
Overnight summary:
- Shipped: <bullets of commits with shas>
- Halted: <none | what blocked and at which slice>
- Decisions needed: <bullets of things you punted on>
- Next resume: <one-line action>
User (first prompt): "claude, i'm headed to bed. please continue autonomously and drive this project forward as far as you can..."
Assistant (first response):
Governor active. Rules for this session:
- Commit after every slice; never >1 slice of uncommitted work.
- Halt on 3 consecutive tool errors; save continuity instead of retrying.
- Amend at most 2x per slice; third amendment triggers rollback.
- 6h wall-time cap.
- Wake-time summary before final stop.
Starting from current continuity record.
Then proceed with the autonomous work.
This skill is compatible with /circuit:handoff — when you halt, save a continuity record as usual. The governor adds budget; it does not replace the continuity system.
development
Draft short, plainspoken notes in the author's voice that help reviewers understand non-obvious choices, boundaries, and preserved behavior in the author's own pull request or local diff. Use when the user asks to self-review, annotate, or add reviewer context to their PR or changes. Draft locally when no PR exists, and post approved notes as one GitHub review when a PR does exist. Do not use for reviewing someone else's PR, writing code comments, explaining code generally, or drafting a PR description. Never post without explicit approval.
tools
Design and build pure-CSS (zero-JavaScript) Tailwind CSS v4 plugins of unusual depth and craft. Use when the user wants to create, architect, or refine a Tailwind utility plugin or CSS effect — e.g. "make a tailwind plugin", "build a tw-* plugin", "a CSS-only shimmer/fade/glow/grain/noise utility", "tailwind v4 @utility", "package this effect as a plugin", or wants an effect with surprising visual depth (gradients, masks, filters, SVG filter tricks, scroll-driven animation). Pairs deep CSS/SVG technique research with a bespoke tuning workbench for dialing the effect in. Inspired by tw-fade and tw-shimmer.
content-media
Create clear, polished before-and-after screenshots for a GitHub pull request. Use when a UI change needs visual proof: capture matching states, crop to the relevant UI, stitch and caption one comparison image, attach it natively to the PR, and keep the image out of the repository.
testing
--- name: latent-potential description: First-principles, team-of-experts assessment of a software project that surfaces latent potential; underexploited assets, a sharper north star, missing high-leverage capabilities, better framing and messaging. Produces a prioritized, evidence-grounded report with cheap probes, a reframe candidate, a stop-doing list, and an honest skeptic's case. Use whenever the user wants fresh eyes on a project they have built: "what am I sitting on", "what could this be