Launching today
Deep Work Plan
Models matter. Context matters more. Give your agent a plan.
50 followers
Models matter. Context matters more. Give your agent a plan.
50 followers
Deep Work Plan turns any repo into a harness with the context of your best engineer — so any AI agent codes like your smartest model and can't drift from the plan. Not a chat window it forgets, a spec written into the repo: atomic tasks, acceptance criteria, validation gates, resumable state. Long runs survive context resets; any agent picks up where the last left off. Point an agent at it, walk away, come back to work you can verify. Any agent, any repo, no lock-in. Open Source, MIT.
Deep Work Plan
Mailwarm
How do you keep the plan from getting stale as humans change the codebase between runs?
Deep Work Plan
@naimz Great question, honestly the failure mode I worried about most while designing this, because it's the one most "just write a spec" approaches quietly ignore. The plan isn't a snapshot of the code, so it doesn't rot like one. DWP handles drift on three fronts.
The first is that I write tasks as behavior, not edits. An acceptance criterion in a DWP task reads like "`POST /login` rate-limits to 10 attempts per IP per minute and returns 429 with a `Retry-After` header," not "add a Redis client in `auth.ts` and wrap the handler." So if a teammate swaps the store for an in-memory cache between runs, lifts the check into a CDN rule, or just renames the file, nothing in my plan is invalidated, the criterion is still expressible against the current code.
The second is that every task carries its own validation gate, and the gate re-runs against the repo as it is right now, not the repo as it was when I wrote the plan. So if someone broke an assumption between runs, the next run fails loudly at that gate instead of drifting silently, and that failure is my cue to `refine` before continuing, not to paper over it.
The third is that I made keeping the spec in sync with the code part of the work, not a separate chore. Any DWP task that changes behavior also updates the `docs/`, `AGENTS.md`, and `.agents/` kit that describe it, re-syncing the repo's agent-facing surface is part of the task's validation gate. On top of that, every plan ends with a security-analysis pass and a skill-discovery step that proposes new reusable skills out of what was just built. It's basically the Boy Scout rule applied to the harness, every run is meant to leave the codebase a little more agent-ready than it found it, not more stale.
If you want the longer take on why I built it this way, the methodology write-up walks through it: https://deepworkplan.com/methodology/
Writing the plan into the repo rather than the context window is the right architecture. Durable state that survives model swaps and context resets is what makes long multi-step tasks actually viable. The validation gate pattern catches drift before it compounds. How are the gates implemented? Are they executable assertions the agent runs itself, or do they require human sign-off?