The official DeepWorkPlan agent skill pack, maintained by Dailybot.
DeepWorkPlan turns any repository into a structured environment — context, guardrails and a durable plan — where any coding agent executes with precision and finishes short- and long-horizon work. It is for developers and teams who hand real work to coding agents (Claude Code, Codex, Cursor, Gemini CLI, Copilot, OpenClaw and others) and need that work to survive context resets, agent changes and long runs.
DeepWorkPlan is spec-driven development where the repository itself becomes the harness.
The pack does three things:
- Onboards any repository, completely.
/deepworkplan-onboardwrites an adaptedAGENTS.md,docs/, per-module docs and.agents/and installs the required local review — the pack and that review go into every repository. It then detects every addon, upgrades the ones you use and offers the ones that fit, whether the repository has none, an older release or a hand-written docker setup; nothing is added just to complete the set. When you want a container, it ends in the full working stack: dev container, editor, agents on your own accounts and a Herdr workspace. - Runs Deep Work Plans. A compact executable Lite plan for bounded
work, or a per-task Full plan for longer work: atomic tasks, acceptance
criteria, validation gates and resumable state under a gitignored
.dwp/. - Orchestrates many agents. A lead agent runs one agent per repository or workstream in its own pane — on the host, in containers or on other machines — each on an account chosen by remaining quota, across vendors, coordinated through one authorized ask and reply, with one branch and one release per repository.
The methodology works alone: apart from the required local review, every addon is optional and only amplifies it. The current major line is v7 (DWP standard 7.0.0; releases are on the Releases page). New plans use the v7 contract; existing v6 and v5 plans keep their recorded lifecycle.
What it rests on
- You steer; the agents do the hours. You decide what done means and where the lines are. The plan carries your intent, so the work does not need correcting every twenty minutes.
- The plan is what the agent returns to. Long work fills any model's context and detail falls away. Atomic tasks, validation gates and resumable state give the agent something durable to come back to, lap after lap.
- Done is a contract, not a feeling. Every task names its acceptance criteria and the checks that must pass. An agent does not get to decide it finished — it passes, or the task stays open.
- The repository is the harness. Context, tools, guardrails and state live in your repo as plain files any agent can read. No lock-in, no external brain, and it survives a context reset or a change of agent mid-flight.
- Context is the scarcest resource. Instructions load progressively by trigger, validation is selected from what each task actually touched, and skills are decided task-locally — so the plan pays for itself instead of crowding out the work.
Pin a release tag: the commands below install exactly v7.6.0 (newer tags are on
the Releases page).
npx --yes skills add https://github.com/DailybotHQ/deepworkplan-skill/tree/v7.6.0 --skill deepworkplan -yThe skills.sh CLI detects your agent and installs the pack
in the right place; -a claude-code (or another agent id) targets one agent.
Installed at project scope, it records the source and a content hash in a
workspace-root skills-lock.json — commit it so your team restores the same
revision. Pin with the tree-URL form above: the CLI ignores the ref of the
OWNER/REPO@ref shorthand and installs the default branch.
openclaw skills install deepworkplangit clone --branch v7.6.0 https://github.com/DailybotHQ/deepworkplan-skill.git ~/deepworkplan-skill
cd ~/deepworkplan-skill
curl -fsSL https://github.com/DailybotHQ/deepworkplan-skill/releases/download/v7.6.0/SHA256SUMS -o SHA256SUMS
./scripts/verify-integrity.sh SHA256SUMS # non-zero exit: a shipped file does not match
./setup.sh # auto-detect installed agents
./setup.sh --host claude # or target one agent explicitlysetup.sh links the deepworkplan router plus each sub-skill
(deepworkplan-create, -execute, -refine, -resume, -status,
-onboard, -verify, -author, -upgrade) into the agent's skills
directory. Default paths per agent are in
docs/INSTALLATION.md.
- Update: re-run the pinned install with the new tag, or ask the agent to
/deepworkplan-upgrade— it checks for a newer release read-only and downloads only with your explicit acceptance;.dwp/is never migrated. OpenClaw:openclaw skills update deepworkplan. - Uninstall: remove the skill directory and the
deepworkplan-*links the installer created (openclaw skills remove deepworkplanon OpenClaw).
- Install the pack (pinned, above) where your agent can see it.
- Onboard the repository:
/deepworkplan-onboard(Claude Code) or#deepworkplan-onboardin any other agent. It writes an adaptedAGENTS.md,docs/,.agents/(including the short/dwp-*commands used below), installs the required local review and offers the addons. Ask it to set up the addons that fit — it detects every addon, upgrades the ones you use and offers the rest only where they fit; run it again on an older onboarding (upgrade) to bring the addons you use to the pack's pins. - Plan real work:
/dwp-create <what you want done>writes a Deep Work Plan under the gitignored.dwp/plans/. - Execute it:
/dwp-execute <plan>works task by task, validates each one against its gates and commits;/dwp-resumepicks up after an interruption;/dwp-statusand/dwp-verifyreport.
/dwp-create accepts mode tokens at either edge of the request: trust (or
auto) skips the guided review, lite and full override the recommended
format — for example /dwp-create trust fix the broken link or
/dwp-create redesign the auth flow full trust.
The pack and the required local review go into every repository; every other addon only where it fits. Onboarding starts from one read-only plan of the repository:
python3 <pack>/shared/addon_sync.py plan --repo .addon scope installed pin action
------------------ ------------ ---------- ---------- ----------
agentkit machine v0.4.0 v1.0.1 upgrade
ai-diff-reviewer repo v3.1.0 v3.3.14 upgrade
dailybot repo - v3.23.20 install
dependency-upgrade repo yes (in pack) record
design-system repo - (in pack) evaluate
offer only when an interface surface is detected
devcontainer machine+repo - v1.0.1 reconcile
a docker setup without dck markers: dck init --dry-run shows each replace as a diff; …
herdr machine v1.0.0 v1.0.0 available
on this machine (v1.0.0, pin v1.0.0); not enabled for this repository
vim machine - v1.0.0 install
pending: agentkit, ai-diff-reviewer, dependency-upgrade, devcontainer
offers: dailybot, herdr, vim (only where they fit; a decline writes nothing)
evaluate: design-system (run its detection before reporting done)
(Illustrative output; the pins are the ones the installed pack carries.)
For each addon the planner reads its detection, the vendored skill and
skills-lock.json, the .dwp/config.json registry and the dev-container
layout, and names one action: install, upgrade to the pin,
record, current, newer (never downgraded), reconcile (a
hand-written dev container, changed only through a shown diff and your
consent), available (a tool on your machine this repository never
enabled), declined (never re-offered) and a few more. pending is what
the repository uses or requires and is not yet at the pin; offers is what
fits but was never chosen here — made once, and a decline writes nothing. The
agent runs each accepted addon's own flow in a fixed order, records the
result, and re-plans until pending: nothing. A second pass over a finished
repository changes nothing. Machine-level installs (ak, dck,
herdr-peers, the editor) are shown as exact, tag-pinned, checksum-verified
commands and run only on your acceptance.
With the dev container, onboarding ends in the full stack: dck init with the
agents layer and only the CLIs you choose, the editor and Dailybot layers when
those addons are on, a Herdr machine with the App · Editor · Development ·
Agents layout, then bash dev.sh up and a verification checklist
(dck doctor, ak doctor inside, herdr workspace list, ssh -T,
gh auth status). Your own accounts can reach the container only through your
host profile ([agents] host_profiles), never the repository.
Procedure: onboard/all-addons.md.
For work across several repositories or long parallel workstreams, a lead agent runs lanes — one agent per repository, each in its own Herdr pane:
| Concern | How |
|---|---|
| Accounts and vendors | ak usage --json once per batch; ak pick <kind> --count N assigns the accounts with the most room; Claude, Codex and others mix by plan choice |
| Launch | ak <kind> @<profile> --trust-cwd "<lane brief>" in a pane on the lane's checkout; in containers, the host's accounts through host profiles |
| Coordination | the lead assigns work through herdr-peers asks and replies (plan ready, PR open, blocked, handoff, done — each with a capacity line; GO with the release tags); lanes may ask each other for information, never assign work |
| Staying alive | each agent checks its own capacity at task boundaries (swarm.py capacity, coding-agents-kit v0.6.1); at critical it writes a handoff packet and a successor resumes the plan; the lead hands over its leadership the same way, or the first reachable deputy takes over (herdr-peers v0.3.0); only critical items (C1–C7) go to you |
| Branches and releases | one lane per repository on its base checkout: one branch, one PR, one release; worktrees only when two writers share a repository |
| Unattended operation | under your standing authorization, lanes launch with no per-launch approval: folders are pre-trusted with --trust-cwd, Claude's bypass-permissions acknowledgement is a one-time step you take per profile, and any other prompt a lane meets is recorded and escalated to you — the one keystroke an agent may send is folder trust on a pane it launched when --trust-cwd is unavailable |
| Verification and record | each repository's own gate decides; every delegation, intervention and account is recorded in the plan |
Guides: guide/orchestration-at-scale.md and guide/swarm.md.
| Skill | What it does |
|---|---|
| deepworkplan-onboard | Make any repo AI-first: an adapted AGENTS.md, docs/, per-module docs, .agents/ and the .claude → .agents / .cursor → .agents symlinks; installs the required local review; offers the optional addons where they fit and, on request or on a harness upgrade, upgrades the ones the repository uses. A targeted, idempotent harness upgrade for repositories onboarded earlier. |
| deepworkplan-create | Create a Deep Work Plan: every request starts as an executable Lite plan, promoted to Full only when the work's risk and horizon call for it. |
| deepworkplan-execute | Execute a plan task by task, run each task's gates, and log progress; delegate parallel_safe tasks when the plan grants it. |
| deepworkplan-refine | Change a plan's scope or tasks, or promote a Lite plan to Full task files. |
| deepworkplan-resume | Resume an interrupted plan from its recorded state. |
| deepworkplan-status | Report a plan's progress, what is left and its blockers, without executing. |
| deepworkplan-verify | Check the repository and its plans against the standard — read-only, exits 0/1 — so "done" is auditable rather than asserted. |
| deepworkplan-author | Author or update skills, agents and commands in the repo's .agents/, keeping the catalog in sync (/skill-create, /agent-create). |
| deepworkplan-upgrade | Check for a newer pack release (read-only) and upgrade only with explicit consent. |
A root deepworkplan router describes every capability and routes by intent.
The AI Diff Reviewer local review goes into every repository; the others are
optional and installed only where they fit. Each is recorded in the
.dwp/config.json registry and documented on its kit page:
| Addon | What it adds | Kit page |
|---|---|---|
| AI Diff Reviewer | the required local review in every Final Review; an optional CI Action | /kit/ai-diff-reviewer |
| agentkit | headless delegates, accounts and quota through coding-agents-kit (ak) |
/kit/agentkit |
| Herdr | interactive delegates and lanes in Herdr panes through herdr-peers; by default, a plan settles its consequential decisions through a small debate among agents (decisions.debate off turns it off) |
/kit/herdr |
| devcontainer | a reproducible dev container through devcontainer-kit (dck) |
/kit/devcontainer |
| DeepWorkPlan Vim | the terminal editor for plans | /kit/vim |
| Dailybot | progress reports at the plan lifecycle events | /kit/dailybot |
| dependency upgrade | safe, batched, revertible dependency upgrades (/lib-upgrade) |
/kit/dependency-upgrade |
| design system | a DESIGN.md reasoned from the repository's real design source |
/kit/design-system |
- deepworkplan.com — the methodology, the kit pages and the published schemas
skills/deepworkplan/spec/— the normative standard (7.0.0)skills/deepworkplan/guide/GUIDE.md— the methodology guide, including orchestration at scaledocs/— installation, design, compatibility, testing- CHANGELOG.md · Open Agent Skills standard · skills.sh
All Deep Work Plan output lives in a gitignored .dwp/ directory at the repo
root:
.dwp/plans/PLAN_001_<slug>/,PLAN_002_<slug>/, ... — new plans in a flat, creation-ordered folder list (README + state + progress log, plus task files when the plan is Full). Existing unnumbered folders keep their names.
There is no draft directory: create materializes an executable Lite plan
directly, and that plan is the reviewable artifact. .dwp/drafts/ and the
refined-draft commands were removed in DWP 2.4.0.
.dwp/ is resolved by skills/deepworkplan/shared/context.sh and overridable
via the DWP_DIR environment variable. It is meant to be gitignored — plan
artifacts are working state, not committed source. For orchestrator hubs, child
plans use the same numbering within each managed repository.
Each repository assigns IDs starting at 001; the counter is kept in
.dwp/plans/.next-plan-id, so deleting a plan does not reuse its number.
latest selects the highest numbered plan. You can also select a plan by its
full folder name, ID, or unique slug. Existing folders such as
PLAN_improve_docs/ are not renamed and remain usable. The current pack
creates v7 plans (v6 on explicit request) with 2–5-word slugs. The retained v5 creation flow uses
2–4 words to fit its frozen schemas.
DWP can record how each executed plan went, so skill versions can be compared
on recorded evidence instead of impressions. It is off unless you turn it on.
In <repo>/.dwp/config.json (this repository only):
{ "benchmark": { "enabled": true } }Or in ~/.dwp/config.json (every repository you run plans in):
{ "benchmark": { "enabled": true } }The repository file wins over the global one, and anything malformed is
disabled with a warning — the feature fails closed. When enabled, the v6
execute flow emits two artifacts into the finished plan's analysis_results/
at completion: benchmark.json, a machine-readable record, and DWP_REPORT.md,
a human summary rendered from it. Both cover execution timing (calendar
spans — overall and per task — never active runtime), plan shape and
complexity counts, friction events (retries, adaptations, refusals), gate
outcomes with evidence classes, context accounting, and diff statistics —
plus tokens and spend only when the host actually metered them.
A nested flag adds the learnings half:
{ "benchmark": { "enabled": true, "learnings": true } }DWP_REPORT.md then also carries the friction explained — each friction
event's recorded reason, copied verbatim from the journal — and a curated
learnings table the completing agent authors once (category, anchor, finding,
proposal). Reruns regenerate the derived half and preserve the curated
entries byte-for-byte. The report is a rendering of the JSON records, never a
second source, and it is distinct from the on-request Executive Report.
Three honesty rules hold by construction: nothing is imputed (unmetered quantities are null, never estimated), the emission is best-effort (a failure warns and never blocks plan completion), and nothing leaves your repositories — the record names only the repository basename and branch. The v5 line is frozen: v5 plans are listed by the aggregator as not collected and are never measured.
To combine records across plans and repositories:
python3 skills/deepworkplan/shared/benchmark.py aggregate \
--roots ~/code/repo-a ~/code/repo-b --csv monthly.csv --out monthly.mdThe aggregate report groups by skill version and repository, adds a learnings
digest (curated entries grouped by version and category, most-flagged
sections, plans with at least one spec-gap, median per-task span, metered
coverage) plus one CSV row per plan with flattened learnings columns, and
carries a standing note: workloads differ across plans, repositories and
versions, so aggregates are evidence for discussion, not a causal comparison.
The specification is skills/deepworkplan/spec/BENCHMARK.md
(record schemas: benchmark-record
and learnings-record).
DeepWorkPlan turns any repository into an AI-first, agent-pilotable codebase. These projects ship together; every addon is optional.
| Repository | Role | Purpose |
|---|---|---|
| deepworkplan-skill (this repository) | Pack | The methodology, specification and kit as an installable agent skill |
| coding-agents-kit | Addon: agentkit | One command for every coding agent: accounts, quota, ak pick, headless runs |
| devcontainer-kit | Addon: devcontainer | A reproducible dev container per repository, wired to Herdr and the host's accounts |
| herdr-peers | Addon: Herdr | Ask an agent in another Herdr pane, on any machine, and get one authorized reply |
| deepworkplan-vim | Addon: DeepWorkPlan Vim | The terminal editor for plans: plan browser, lanes view, Markdown viewer |
| ai-diff-reviewer | Required local review | Reviews a change set locally and in CI; every Final Review runs it |
| agent-skill | Addon: Dailybot | The Dailybot agent skill: progress reports, check-ins, chat and more |
| deepworkplan.com (source) | Site and hub | The methodology, specification, kit catalog and /init.md; coordinates the ecosystem |
Report vulnerabilities privately — see SECURITY.md (GitHub
private vulnerability reporting or security@dailybot.com). In short: the core
methodology makes no network calls and emits no telemetry; its only external
processes are git and, for addons, their declared read-only detect commands;
every install the pack names is tag-pinned or package-managed, and nothing is
piped into a shell;
secrets are referred to by name, never printed or stored. Coding agents launched
through ak run in autonomy by default, and your opt-out
(AGENTKIT_PERMISSIONS=ask) always wins. The full model, with a self-audit you
can run, is skills/deepworkplan/TRUST.md. CI
runs a public-hygiene check on every change.
This README is for users. If you want to work on the skill itself, start with
CONTRIBUTING.md — the human-facing guide to local setup, the
auto-release flow, and the PR workflow. The canonical, terser rule list for AI
agents is AGENTS.md (and CLAUDE.md is a symlink to it): it covers
the ship boundary (only skills/deepworkplan/ ships), the SKILL.md frontmatter
contract, the automatic-versioning rule, the commit format, and the pre-commit
checklist. Deeper background lives under docs/ — DESIGN.md
(the why behind the layout), INSTALLATION.md,
OPENCLAW.md, and SUB_SKILL_GUIDE.md.
MIT. Contributions are accepted under the same license; see CONTRIBUTING.md and the Code of Conduct.
🔌 Powered by Dailybot
Dailybot is an AI-powered async communication platform that keeps people and agents visible — without adding more meetings or tools. It lives where your team already works (Slack, Teams, Google Chat, Discord, VS Code, and the CLI) and turns scattered signals into clear progress: async check-ins and standups, AI summaries that detect blockers and read team sentiment, workflow automation and approvals, team analytics, and recognition. As AI agents join the workflow, Dailybot surfaces their status and activity right alongside your team's — so long-running agents never go dark. Learn more.
Part of the DeepWorkPlan ecosystem — works on its own.