skills/claude-code-audit-workspace/iteration-1/eval-3-specific-leverage-framing/with_skill/outputs/drafts/skills/overnight-autonomy/SKILL.md
--- name: overnight-autonomy description: Codify the user's standard overnight-autonomy contract so it doesn't have to be retyped every session. Triggers on phrases that signal "I'm leaving Claude running while I sleep": "i'm going to sleep", "i'm headed to bed", "i have to go back to sleep", "drive this forward overnight", "go full autonomy", "keep going until morning", "autonomously follow through", or any combination including "claude" + "sleep/bed/morning". Establishes the overnight contract
npx skillsauth add petekp/claude-skills skills/claude-code-audit-workspace/iteration-1/eval-3-specific-leverage-framing/with_skill/outputs/drafts/skills/overnight-autonomyInstall 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.
User's prompt signals they are handing the session off to Claude while they sleep. Accepted forms (not exhaustive — match intent):
Do NOT fire on the word "autonomous" alone — that appears in non-sleep contexts (e.g., "run this autonomously" for a 20-min task).
When this skill fires, before doing any of the user's requested work, you adopt the following contract for the rest of the session. Announce it to the user in one paragraph (not a list) so they can scroll up and confirm. Then start work.
Create a full TaskList before touching any file. Every distinct unit of work the user mentioned, plus any sub-tasks you can foresee, gets a task. TaskCreate before TaskUpdate before Edit. The TaskList is the plan; the plan survives the session.
On any error — build break, test failure, type error, lint violation, runtime crash — do not patch the symptom. Enumerate 2+ hypotheses for root cause (the CLAUDE.md doctrine), pick the most likely, verify, then fix. Log the hypothesis chain to the morning log so the user can review.
If a commit fails post-hoc (tests go red, lint fails, etc.), amending the commit to fix is allowed and expected — but only for the work that was just introduced in that commit. Never amend past work that was already green.
Unless the user set an explicit Codex budget, you may dispatch at most 3 Codex calls across the overnight session (adversarial review counts as 1 call; re-dispatches for fold-ins count separately). Log every Codex dispatch to the morning log with input prompt and verdict.
Write a running log to <project-root>/.claude/overnight-logs/<YYYY-MM-DD>-session.md. One section per phase. Each section: goal, actions taken (bullet list with commit SHAs), errors encountered + root-cause analysis, decisions made + rationale, open questions for the user. Update it at every phase boundary and at session end. This is the artifact the user reviews in the morning.
Stop the session if:
Do NOT stop for: merge conflicts, flaky tests (retry 3x), transient network errors, or any ambiguity resolvable by reading more code.
The user is asleep. Asking them a question is equivalent to stopping. If you find yourself wanting to ask, instead: log the question to the morning log under "Open questions", pick the most defensible option, annotate the choice with "chose X because Y; revisit if Z", and continue.
If overnight-guard hook detects a resumed overnight run (on SessionStart:resume), the contract is re-applied automatically — no user action needed. The morning log is appended to; a new section is opened.
"Overnight contract in effect: full TaskList before any edit, root-cause hypotheses before any fix, amend-commit loop for in-flight work only, max 3 Codex calls, morning log at .claude/overnight-logs/2026-04-23-session.md updated at every phase boundary. If I hit a genuine blocker I'll stop and log it; otherwise I'll keep going until the TaskList is clean or dawn, whichever first. Starting now."
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