# Deep Work Plan - Full Site Description > Context matters more than models. Deep Work Plan (DWP) is an open, MIT-licensed methodology and reference kit that turns any repository into a structured, agent-pilotable environment — context, guardrails, and a durable plan — where the repository itself becomes the agent harness, so any coding agent can finish long-horizon work. Spec-driven, tool-agnostic, repo-native. Maintained by Dailybot and the open-source community. ## What Deep Work Plan Is Deep Work Plan is the methodology that turns any repository into an AI-first, agent-pilotable codebase. It is a methodology, not a product. DWP is spec-driven development where the repository itself becomes the agent harness: it defines how to turn a goal into an agreed plan, decompose that plan into atomic and independently verifiable tasks, and run each task in a focused loop that ends with an explicit validation gate before the next task begins. The methodology and kit install into the repository (AGENTS.md, docs, the .agents/ skills home, the DWP skill) so the work is durable and any agent can pilot the repo. DWP is deliberately agnostic about which AI agent or stack you use. Adapters translate the same core loop to Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Antigravity, Windsurf, Cline, OpenCode, and more (Claude Code and Codex are behavior-tested; the other adapters are install-tested). The plan, the tasks, and the running log are all plain Markdown, so the work stays readable, reviewable, and version-controlled. There is no runtime and no lock-in. The methodology, specification, and kit are released under the MIT license — free to use, adapt, and build on. ## When to use Deep Work Plan Reach for DWP when the job is: - Making a repository AI-first: installing the agent scaffolding (context, skills, guardrails) so any coding agent can pilot it. Start with the [adoption prompt](https://deepworkplan.com/init.md) — a self-contained prompt an agent can execute directly. - Long-horizon agent work: features, refactors, or migrations too large for one prompt, decomposed into atomic tasks that each end in an explicit validation gate and survive across sessions (resumable state on disk). - Spec-driven development without tool lock-in: the plan is the durable source of truth in the repo (Markdown, version-controlled), not inside a vendor's tool. DWP is tool-agnostic where GitHub Spec Kit, Amazon Kiro, or Tessl are tool-bound. - Handing an unfamiliar repository to an agent: the DWP documentation layer (AGENTS.md, docs/, .agents/) gives any agent the context to work safely. Skip DWP for single-file edits, throwaway scripts, or repos an agent will touch once — the structure pays off on durable, multi-session work. How an agent should engage: fetch the [adoption prompt](https://deepworkplan.com/init.md) and follow it to onboard a repository; POST JSON-RPC 2.0 to the MCP endpoint at https://deepworkplan.com/api/mcp (get_init_prompt, list_site_sections, read_page — GET is not supported, see the [MCP manifest](https://deepworkplan.com/.well-known/mcp.json)) to navigate and read this site; read the [developer portal](https://deepworkplan.com/developers) for the full API surface. ## Who Maintains It Deep Work Plan grew out of real engineering work at Dailybot and is now maintained by Dailybot together with the open-source community. - Dailybot: https://www.dailybot.com - Repository: https://github.com/DailybotHQ/deepworkplan-website ## Core Principles - Plan before execution — no code is written until the plan is agreed. The plan is a contract between you and the agent. - Tasks are atomic — each task is scoped so it can be executed and verified on its own, then committed atomically. - Verify everything — every task ends with an explicit validation gate before the next one begins, with progress recorded in git. - Evidence over narrative — a task closes only on recorded evidence that satisfies its acceptance criteria; a claim, including another agent's result, stays a claim until the plan's own gate observes it. - Delegation never lowers the bar — parallel agents work only on tasks marked safe for it, under an explicit grant, and their work is gated like anyone else's. - Escalate only what is critical — routine decisions are made and recorded; the agent stops only for approval, consent, irreducible ambiguity, quality conflicts, damage, terms or exhausted capacity. ## Site Structure ### Pages - [Home](https://deepworkplan.com/) — Overview of the Deep Work Plan methodology and how to get started - [Methodology](https://deepworkplan.com/methodology) — The narrative methodology: what DWP is, its principles, the workflow, and how to adopt it - [Specification](https://deepworkplan.com/spec) — The readable, normative DWP standard: task anatomy, validation gates, completion protocol, mandatory final tasks, archetypes, and addons - [Kit](https://deepworkplan.com/kit) — The kit catalog: presets, adapters, and commands available for installing DWP into a repository - [Changelog](https://deepworkplan.com/changelog) — A source-backed timeline of the releases and design decisions behind Deep Work Plan (e.g. v3's token efficiency, v4's Lite-first plans, v6's verified closure on an append-only journal, v7's delegation with evidence, swarm autonomy and Ecosystem 1.0) - [Examples](https://deepworkplan.com/examples) — Worked examples that show the methodology applied to real engineering work - [Quickstart](https://deepworkplan.com/quickstart) — A short path to getting DWP running in a repository - [Vim](https://deepworkplan.com/kit/vim) — DeepWorkPlan Vim v1.0.1, the terminal editor for Deep Work Plan and the optional `vim` addon of Deep Work Plan v7: a generated command index (SPC h h), VS Code-shaped gestures, a read-only DWP plan browser (SPC P), a Markdown viewer (SPC m p / SPC m r), and a consent-first installer — download https://deepworkplan.com/vim/install.sh, compare its SHA-256 with the value on the page, then run `bash install.sh` (it installs its own release, v1.0.1, or the one `--version` names: an exact version, a `>=` floor or `latest`) (Neovim 0.12+, macOS/Linux, GPL-3.0). - [Herdr addon](https://deepworkplan.com/kit/herdr) — Optional v7 addon built on herdr-peers v1.1.0 (MIT): a plan with the `agent_delegation` grant hands a `parallel_safe` task to a peer agent in a Herdr pane, on any machine, and receives one authorized reply. Depth limit 1, fan-out cap 4, replies are data rather than instructions, every delegation recorded before it is relied on; the sender is not authenticated (`HERDR_PEERS_SCOPE` allow-list mitigates). - [Agentkit addon](https://deepworkplan.com/kit/agentkit) — Optional v7 addon built on coding-agents-kit v1.1.0 (MIT): `ak [@profile]` for claude, codex, cursor, opencode, pi, cline, grok and antigravity (plus GLM/Azure/xAI variants), profiles, headless `ak run`, `ak doctor --json`; the headless delegation transport (one `ak run` per delegate in a git worktree). Agents run in autonomy by default (the CLI's own flag, added by `ak`); the opt-out — `--ask` on one command or `AGENTKIT_PERMISSIONS=ask` — always wins, also over `--auto`. Set it on a host; a dev container is the intended sandbox. - [Devcontainer addon](https://deepworkplan.com/kit/devcontainer) — Optional addon built on devcontainer-kit v1.1.1 (MIT): each repository's own dev container rendered by `dck init` (reconciled, never clobbered) — `docker/local//Dockerfile` from the official `python-3.13` / `node-24` / `debian` image pinned by digest, no shared base image — `bash dev.sh up` over the `dck` launcher, opt-in layers (coding agents through `ak`, editor, Dailybot), loopback-only binds, git over SSH through the host agent with the developer's git aliases (key files inside only on the developer's `[ssh] copy_keys` opt-in, which makes the whole host `~/.ssh` readable inside), the `dck-dockerfile` skill, and Herdr machines per container with the standard layout. - [Compare](https://deepworkplan.com/compare) — Deep Work Plan compared with spec-driven tools, agent workflow frameworks and vendor-native plan modes: each described on its own terms, three neutral capability values, official sources, a review date and an invitation to correct - [FAQ](https://deepworkplan.com/faq) — Frequently asked questions: what Deep Work Plan does, how validation gates and resumption work, how it differs from other tools, and how to adopt or upgrade - [Quickstart / Adoption](https://deepworkplan.com/quickstart) — Make any repository AI-first: install the skill, onboard the repo, then plan and execute. Includes a self-contained onboarding prompt at [init.md](https://deepworkplan.com/init.md) to hand to an agent - [Developers](https://deepworkplan.com/developers) — The agent & developer surface: a read-only, zero-auth, versioned API described by an OpenAPI spec, a stateless MCP server at /api/mcp, per-page Markdown in 17 languages, the `npx skills` install CLI, and the official `deepworkplan` CLI. Alias: /docs redirects here - [Trust](https://deepworkplan.com/trust) — Why the skill is safe to adopt: open source, MIT, verifiable installs (SHA256SUMS), and a clear vulnerability-disclosure policy - [About](https://deepworkplan.com/about) — What Deep Work Plan is, its core principles, and who maintains it - [Contact](https://deepworkplan.com/contact) — How to engage with the project: source, issues, and discussions on GitHub - [Privacy](https://deepworkplan.com/privacy) — The site's privacy policy: static site, no accounts, cookieless analytics ### What v7 adds Deep Work Plan v7 (pack `v7.9.0`) keeps the plan, task and gate loop and adds a verifiable record and safe parallelism: - **A record, not a narrative.** A plan carries an immutable outcome contract and an append-only journal; a task completes only when recorded evidence satisfies its criteria. Only the plan's own gate runner mints `observed` evidence; claims stay `asserted`, and a human judgment closes a criterion only through a recorded sign-off. Spec: [record layer](https://deepworkplan.com/spec/record-layer). - **Delegation with evidence.** A plan whose contract grants `agent_delegation` can hand `parallel_safe` tasks to other coding agents — headless in a git worktree (agentkit) or in another Herdr pane, on any machine (Herdr). A delegate's result stays a claim until the plan's gate observes it. Spec: [delegation](https://deepworkplan.com/spec/delegation). - **Many agents, one lead.** Orchestration at scale (one lane per repository or workstream) and swarm autonomy (capacity checks at task boundaries, handoff packets before a usage limit, lead succession with epochs and fencing) keep long efforts running past one account's limit or one agent's loss. - **Escalation only when it is critical.** Agents decide and record routine choices and stop only for seven classes: approval not granted, a consent or login screen, irreducible ambiguity, a quality conflict, damage, terms, or exhausted capacity. - **Optional, pinned ecosystem.** Every addon is opt-in and recorded in `.dwp/config.json`; the methodology works with none. Since 7.8.0 every integrated product is stable at 1.0 under semantic versioning. ### Ecosystem (v7) The Deep Work Plan methodology works alone: no addon is required and none is a conformance gate. Every addon is a thin integrator in the skill (`addons//addon.json`), pinned by tag to a product that has its own repository, release, integer interface version (devcontainer-kit is on interface 2; the others on 1) and works without Deep Work Plan. Products and pins: herdr-peers v1.1.0 (`herdr`), coding-agents-kit v1.1.0 (`agentkit`), devcontainer-kit v1.1.1 (`devcontainer`), deepworkplan-vim v1.0.1 (`vim`). From 1.0.0, each product's public interface follows semantic versioning: an incompatible change ships only in a new major version. Addons are recorded per repository in `.dwp/config.json` (`addons..enabled`; absent means not enabled). Delegation (`launch`, `observe`, `collect`, `cancel`) has a headless transport (agentkit) and an interactive one (herdr); a delegate's result is `asserted` until the plan's own gate runner observes it. All of this ships in the skill's stable releases since `v7.0.0`; this site vendors `v7.9.0` (with `SHA256SUMS`). ### Languages The site ships in 17 languages. English (default) is served at the root; the other 16 live under their code: /es/, /pt/, /zh/, /ja/, /de/, /fr/, /ko/, /ru/, /it/, /tr/, /id/, /vi/, /hi/, /pl/, /uk/, /th/ Each language has its own full page set and its own Markdown mirrors. ## Content Model - Multilingual routing: English base routes (`/`, `/methodology`, `/spec`, etc.) and 16 language routes under `/{lang}/` - Methodology, spec, and kit content authored with Astro Content Collections supporting Markdown and MDX - All pages use structured data (JSON-LD) for machine readability ## Topic Areas - Structured execution for AI coding agents - Planning and decomposing engineering work into atomic, verifiable tasks - Validation gates and completion protocols - Agent-agnostic workflows (Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Antigravity, Windsurf, Cline, OpenCode, and more) - Verifiable completion: an outcome contract, an append-only journal and gated evidence - Delegating tasks to parallel agents with recorded, gated results - Markdown-based, version-controlled plans and running logs - Resumable multi-hour agent execution ## Tech Stack - Astro (static site generator with islands architecture) - Svelte (interactive components) - TypeScript - Tailwind CSS (with dark mode support) - MDX (enhanced Markdown) - Biome (linter and formatter) - Deployed on Cloudflare Pages ## Agent-Friendly Markdown Endpoints Every rendered page is available as clean, native Markdown for AI agents. This content is served directly from the original source Markdown — not converted from rendered HTML — preserving full fidelity of code blocks, links, and formatting. ### URL Patterns - **Pages**: `/{page}.md` (EN), `/{lang}/{page}.md` for the 16 non-default languages - Examples: `/methodology.md`, `/spec.md`, `/kit.md`, `/init.md`, `/es/methodology.md`, `/ja/developers.md`, `/pt/privacy.md` - **Reader entries**: `/methodology/{slug}.md`, `/spec/{slug}.md`, `/kit/{slug}.md`, `/examples/{slug}.md` (and their `/{lang}/…` variants) - **Onboarding prompt**: `/init.md` — a self-contained prompt you can paste into an agent to make a repository AI-first ### Response Format Each Markdown response includes: - H1 title - Description (blockquote) - Metadata: Language, Canonical URL (HTML version), Last Updated - Separator - Original Markdown body content Content-Type: `text/markdown; charset=utf-8` ### Content Negotiation Agents can request Markdown without changing URLs by sending `Accept: text/markdown`: ``` curl -H "Accept: text/markdown" https://deepworkplan.com/methodology → Returns Markdown with Content-Type: text/markdown; charset=utf-8 → Response includes Vary: Accept header for proper caching ``` ### Why Native Markdown - Content is served from the original source files, not HTML→Markdown conversion - More token-efficient for AI consumption (no HTML tag residue) - Code blocks, links, and formatting preserved exactly as authored - Canonical URL always points to the HTML version for human readers - Internal cross-links between pages enable agents to discover the full site structure ## Agent API The site exposes a read-only, zero-auth agent API — no keys, no registration, declared in [auth.md](https://deepworkplan.com/auth.md): - [OpenAPI 3.1 spec](https://deepworkplan.com/openapi.json) — every endpoint, parameter, and response schema - [MCP server manifest](https://deepworkplan.com/.well-known/mcp.json) — describes the stateless Model Context Protocol endpoint at https://deepworkplan.com/api/mcp, served over Streamable HTTP (JSON-RPC 2.0, POST only — GET returns 405 by design, no SSE stream). Tools: `get_init_prompt`, `list_site_sections`, `read_page`. Server card: [server-card.json](https://deepworkplan.com/.well-known/mcp/server-card.json). Supports protocol versions 2025-03-26 and 2025-06-18 - [Health](https://deepworkplan.com/api/health.json) — static status marker - [Versioned API catalog](https://deepworkplan.com/api/v1/index.json) — the `/api/v1/` family (sections, pages, health) with the site version and spec links; the unversioned canonical paths belong to the same v1 contract - [Official CLI](https://github.com/DailybotHQ/deepworkplan-website/tree/main/cli) — `deepworkplan`: a zero-dependency command-line client over this API (`init`, `sections`, `read`, `open`, `mcp`); npm publication pending - Versioning & rate limits — breaking changes ship only in a new `/api/v{N+1}/` family; deprecated endpoints answer with `Deprecation` and `Sunset` headers at least 180 days before removal; `/api/*` responses carry RFC 9331 `RateLimit-Limit`/`-Remaining`/`-Reset`/`-Policy` headers and `Retry-After` on 429 (best-effort, 120 requests per 60 seconds, anonymous access unchanged) - [Developer portal](https://deepworkplan.com/developers) — quickstarts, curl examples, and the install CLI ([/docs](https://deepworkplan.com/docs) redirects there) - **Errors**: unknown `/api/*` paths return structured JSON errors (`{"error":{"code","message","hint"}}`), never HTML; Markdown-negotiating clients that hit a 404 receive a Markdown recovery body listing the sitemap, llms.txt, and key pages ## Feeds & Discovery - [Sitemap](https://deepworkplan.com/sitemap-index.xml) — every page in every language - [robots.txt](https://deepworkplan.com/robots.txt) — crawling rules and the Agentmap pointer - [API catalog](https://deepworkplan.com/.well-known/api-catalog) — RFC 9727 linkset of service documents - [ARD capability manifest](https://deepworkplan.com/.well-known/ai-catalog.json) — the agentmap - [Agent Skills index](https://deepworkplan.com/.well-known/agent-skills/index.json) — agent-readiness skills this site adopts - [Security contact](https://deepworkplan.com/.well-known/security.txt) — RFC 9116 - This file: [llms-full.txt](https://deepworkplan.com/llms-full.txt) - Short version: [llms.txt](https://deepworkplan.com/llms.txt) ## Structured Data The site includes JSON-LD structured data on all pages: - WebSite schema (site-level identity) - SoftwareApplication schema (Deep Work Plan, free, authored and published by Dailybot) - Organization schema (Dailybot, with contact point and postal address) - BreadcrumbList schema (navigation hierarchy) - AboutPage and ContactPage schema where applicable