Pattern I'm using to keep Claude Code productive on overnight unattended runs

Been running Claude Code on multi-hour autonomous sessions for a few months and kept hitting the same wall: the longer it runs, the worse the work gets. Not a context-window problem (1M handles that fine), but a feedback-loop problem. Iteration N+10 makes the same mistakes it made at iteration N, because nothing updates between iterations except the code.

Built a small framework around three pieces that, between them, solved it for me. Together this framework as enabled me to consistently run very low-drift, stable, efficient (accepting some necessary overhead from reviewer -> superviser -> manager agents), long-running, productive, autonomous software development jobs. Essentially, the only apparent limiting factors are your ability to keep the SPEC ahead of the agents (experimenting with writing a new skill to handle this also) and the ever-looming Anthropic rate-limits (the framework gracefully handles usage limits and resumes after reset).

Chain runner. bin/skill-chain.py --chain dev-cycle-with-review-looped --loop 10 runs a fixed sequence of skills for N iterations. Each iteration: a dev skill picks the next item from docs/TODO.md, ships it (code + tests + docs in one commit), then a review skill critiques what landed and queues follow-ups in TODO. Standard agent loop with the loop body made explicit.

Supervisor at session end. After the loop finishes, a separate skill reads the run's transcripts, evaluates each skill against its stated job, and proposes rewrites to the skill prose itself. With auto-promote on, those rewrites land. Next session's iteration 1 reads the updated SKILL.md. Auto-promote off writes them as SKILL.patch.md sidecars for human review instead.

A single handoff contract. Every skill reads docs/SPEC.md (canonical plan) and docs/TODO.md (In flight / Just shipped / Next up) at the start, updates them in the same commit as the code change. No side channels, no second TODO format, no per-skill plan docs. The framework dogfoods this contract on its own development.

The thing that surprised me after running this for a while: the supervisor is nice, but the contract does most of the work. A single SPEC + TODO pattern dogfooded across every skill kills the drift problem on its own. Most of the "self-improvement" is the supervisor enforcing that contract more strictly over time.

Other pieces in the repo worth knowing about:

• Proprietary / transferable split. Skills under skills/framework/ are transferable (anyone can use them); each project keeps its proprietary counterpart in .claude/skills/ with project-specific identity and credentials baked in. A sanitization skill checks promotions across that boundary so secrets don't leak into shareable skills. Basically you use the transferable skills as templates to create project-specific skills, then can generalize/sanitize them back up to improve transferable skills.
• Schema validation. bin/validate-frontmatter.py against schema/skill-set.schema.json and schema/skill-chain.schema.json. Catches malformed skills before a chain run blows up at iteration 7.
• Optional Telegram steering. At session start, every iteration boundary, every rate-limit pause/resume, and session end, you get a short status message. You can queue commands back via /cmd that the next iteration drains. Worker is chain-bound (only runs while a session is live), so you don't get inbound noise between runs.
• Overnight chain. Loops until failure, budget cap, or Ctrl-C, with a randomized 5min-2h inter-iter delay so commit cadence stays human-shaped across many hours of unattended work.

Repo: https://github.com/toadlyBroodle/skill-set

README has the quickstart; bin/skill-chain.py --help for the runner directly.