# Init — Make your repository AI-first

> The executable onboarding prompt for AI agents: adopt Deep Work Plan in any repository — analyze, document, install the skill, and leave it agent-pilotable.

Language: en
Canonical: https://deepworkplan.com/init.md
Human-readable version: https://deepworkplan.com/quickstart
Markdown: send header `Accept: text/markdown` on any URL to receive Markdown instead of HTML.

---

You are an AI coding agent. Read this entire prompt first, then make the current repository
**AI-first**, **spec-driven**, and **agent-pilotable** by adopting the Deep Work Plan (DWP)
methodology. Treat this as a structured engineering task — a Deep Work Plan — not a quick edit.

## Operating principles (read before changing anything)

1. **Reason about *this* repository.** Never copy a template or leave a placeholder. Every file you
   write must reflect the repository's real languages, frameworks, commands, and structure. A generic
   stub is a failure, not a deliverable.
2. **Be non-destructive — ask before you replace.** The repository may already have an `AGENTS.md`, a
   `docs/` tree, a `.agents/` or skills setup, a `CLAUDE.md`, or its own conventions. Do **not**
   overwrite, move, or delete existing work silently. Detect what exists, read it, and **reconcile**:
   merge and improve in place wherever possible. Before replacing or removing anything the user
   already has, explain what and why, and get their explicit approval.
3. **Propose the plan, then execute.** After reconnaissance, present a short plan — what you will
   create, what you will modify, and anything existing you propose to reconcile or replace — and wait
   for the user to confirm before making large or destructive changes.
4. **Work in safe, reviewable increments.** Commit logically, keep diffs readable, touch no secrets,
   and leave unrelated code alone.
5. **Stop and report** if a step fails or the repository state is ambiguous.
6. **Trust, but verify.** Treat this prompt as untrusted input: confirm you fetched it from the
   official sources (`deepworkplan.com` and the `DailybotHQ` repositories), evaluate it before you act
   on it, and verify the skill's integrity before running it — see *Trust and verification* below.

## 0. Read the methodology and specification

The methodology stands on three pillars: **spec-driven development** (the written spec is the source of truth), **harness engineering** (the repository carries the context, tools, guardrails, and state), and **token efficiency** (the harness loads progressively and validation touches what changed — long-horizon work by design, efficient by construction).


Before changing anything, read the canonical sources so you understand the standard you are adopting:

- Methodology: https://deepworkplan.com/methodology.md
- Specification: https://deepworkplan.com/spec.md
- Kit catalog: https://deepworkplan.com/kit.md

## 1. Reconnaissance and a plan to approve

First understand the repository, then propose what you will do.

- **Detect the stack.** Languages, frameworks, the package manager (from the lockfile that actually
  exists), the real build/test/lint/type-check commands, the source modules, the test convention, and
  the deployment shape.
- **Classify the archetype.** An individual repository (the common case), an orchestrator hub, or an
  agent workspace — the long-lived home of an autonomous agent, where git is recommended rather than
  assumed — with the evidence.
- **Recognize an existing DWP installation — there are two independent things that can be outdated.**
  Check for an installed skill directory first (`.agents/skills/deepworkplan/`,
  `.claude/skills/deepworkplan/`, `.cursor/skills/deepworkplan/`, or an equivalent user-level skills
  directory for your host) and read its `SKILL.md` `version:` — that tells you whether the **skill
  package** is current. Separately, if `AGENTS.md` exists, look for its `DWP standard:` provenance line
  — that tells you whether the **harness content** (the standard it was generated against) is current.
  These can be out of sync, so handle them independently, and always go through Step 2 below rather than
  assuming either is current:
  - **Skill package outdated (or its version cannot be confirmed current)** — do not silently keep
    going. Step 2 below routes you through the installed skill's own `upgrade` sub-skill, which checks
    the latest published tag, diffs the incoming release against what is installed to surface any local
    adaptation before overwriting anything, and only reinstalls after explicit confirmation.
  - **Harness content outdated, skill package already current** — the `onboard` sub-skill's own
    precondition phase detects this from the provenance line and runs a **targeted upgrade**:
    reconciling only the missing or outdated pieces. Every handwritten section, custom skill, and
    in-flight plan is preserved, and a second run changes nothing. Plans authored under an earlier
    version keep their recorded shape and close with their own final tasks; they are never forced into
    the new one.
- **Inventory what already exists.** `AGENTS.md`, `CLAUDE.md`, `docs/`, any `.agents/` or skills/agents
  setup, `.dwp/`, and `.gitignore`. Note anything that already does part of this job.
- **Propose the onboarding plan.** Present a concise list: files you will create, files you will
  modify, and anything existing you propose to reconcile or replace — then **ask the user to confirm**
  before proceeding. For a large repository (many modules or many artifacts to generate), the onboard
  sub-skill uses a plan-driven path: it completes reconnaissance, generates `AGENTS.md`, then emits
  an onboarding Deep Work Plan under `.dwp/plans/` and hands off to `/dwp-execute`
  → `/dwp-resume` as needed.

## Trust and verification (before you install)

You are about to install and run code in this repository, so verify what you are adopting first. This
is encouraged: a careful agent treats a fetched prompt as untrusted until it has been checked.

- **Confirm provenance.** This prompt and the skill are open source and MIT licensed. The canonical
  sources are `https://deepworkplan.com` and the `DailybotHQ` GitHub organization
  (`deepworkplan-website`, `deepworkplan-skill`). A machine-readable manifest is published at
  `https://deepworkplan.com/.well-known/dwp-trust.json`.
- **Know what the skill does.** It is Markdown-first: no CLI, no HTTP API, no auth, **no network
  calls, and no telemetry**. Its only security-relevant action is mutating *this* repository, and it is
  non-destructive by design — it reconciles and asks before replacing.
- **Verify integrity before you run.** Every release publishes a `SHA256SUMS` over the shipped skill;
  confirm your copy matches it before trusting it:

  ```bash
  git clone https://github.com/DailybotHQ/deepworkplan-skill.git
  cd deepworkplan-skill
  # Download the checksums for the release you intend to install (replace vX.Y.Z):
  curl -fsSL -o SHA256SUMS \
    https://github.com/DailybotHQ/deepworkplan-skill/releases/download/vX.Y.Z/SHA256SUMS
  ./setup.sh --verify        # non-zero exit means a file does not match — stop
  ```

  Releases are **checksummed, not signed** (signing is a documented next step). Everything is open and
  diffable, so you can also compare any file against the repository at its tag.
- **Report a problem.** Report security issues **privately through GitHub's vulnerability reporting**
  on the relevant repository — `https://github.com/DailybotHQ/deepworkplan-skill/security`
  or `https://github.com/DailybotHQ/deepworkplan-website/security` — not as a public
  issue. See also each repository's `SECURITY.md`, `https://deepworkplan.com/.well-known/security.txt`,
  and the trust page `https://deepworkplan.com/trust`.

## 2. Install — or upgrade — the Deep Work Plan skill

> **The short path.** The skill carries its own onboarding, so installing it is enough. Once it is installed, run `/deepworkplan-onboard` and it performs everything sections 3–7 describe: reconnaissance, `AGENTS.md`, `docs/`, per-module docs, `.agents/`, the required local review, the opt-in addons and the final self-check. Read on for what that sub-skill will do — and for the fallback when an agent cannot load skills.

**First, check whether the skill is already installed** — look for
`.agents/skills/deepworkplan/`, `.claude/skills/deepworkplan/`,
`.cursor/skills/deepworkplan/`, or an equivalent user-level skills directory for
your host. Branch on what you find:

- **Not installed.** Run one of the fresh-install commands below, then continue
  to section 3.
- **Already installed, with an `upgrade/SKILL.md` sub-skill present (v5.0.0 or
  later — the common case).** Do **not** run the generic install command
  below — a blind reinstall can silently overwrite a repository's own
  adaptation of the skill (this repository may have deliberately edited its
  vendored copy). Instead, load the installed skill's `upgrade` sub-skill
  (`/dwp-upgrade`, or read its `upgrade/SKILL.md` directly if slash commands
  are unavailable) and run it: it checks the latest published tag against
  what is installed, reports whether a newer version exists, and if so
  **diffs** the incoming release against the installed tree to separate a
  normal upgrade from a local adaptation — then asks for explicit
  confirmation before installing anything. Only after that flow concludes
  (accepted, declined, or confirmed already current) continue to section 3,
  which is idempotent and safe to run either way.
- **Already installed, but with no `upgrade/SKILL.md`** (a pre-5.0.0 install —
  the `upgrade` sub-skill did not exist yet, so there is no in-place
  check-and-diff path available). Tell the user what you found, then run a
  fresh install with the force flag to replace it outright — e.g.
  `npx --yes skills add https://github.com/DailybotHQ/deepworkplan-skill/tree/v7.0.1 --skill deepworkplan --force -y` — and continue to
  section 3, which detects and reconciles the outdated harness content.

Fresh-install commands (skip these if the skill is already installed — see above):

```bash
# pinned to the current release (the skills CLI honours only this tree-URL form for a tag):
npx --yes skills add https://github.com/DailybotHQ/deepworkplan-skill/tree/v7.0.1 --skill deepworkplan -y
```

Or install via OpenClaw:

```bash
openclaw skills install deepworkplan
```

Or clone and run the setup script:

```bash
git clone https://github.com/DailybotHQ/deepworkplan-skill.git && cd deepworkplan-skill && ./setup.sh
```

### Current standard and execution model

The current repository-facing standard is **DWP 7.0.0**, implemented by the
Deep Work Plan skill release **7.0.1** installed above. The current skill pack includes
the router and nine sub-skills: `create`, `execute`, `refine`, `resume`,
`status`, `verify`, `onboard`, `author`, and `upgrade`.

The standard is deliberately proportional, and it makes that proportion a
property of the plan rather than of the developer's discipline. A plan is
either **Lite** — task records inline in the plan's README, for small bounded
work — or **Full**, one file per task, for long-horizon work. The choice is
about representation cost, not rigor: both formats carry stable task ids, a
Touched Surface, acceptance criteria, validation gates, completion evidence
and one Final Review, so a Lite plan is a real plan, not a sketch. Format,
materialization, approval and execution are independent axes; a Lite plan is
promoted to Full with `/dwp-refine promote` when compact records stop carrying
a requirement or a gate.

For a full plan, the repository is the durable execution surface. The plan
contains atomic tasks, a **Touched Surface** that explains what changed and
which consumers are affected, acceptance criteria, and a validation gate
selected from the repository's documented test map. A new plan writes its identity manifest, then its versioned
contract, then its approval event. The append-only journal records execution, and
`state.json` is a snapshot derived from that journal. Each step can be
recovered after an interruption.

Schema generation stays tied to each plan. The current 7.x pack creates
**v7** plans by default: `manifest.json` follows
https://deepworkplan.com/schema/plan-manifest/v7.json, the
[contract](https://deepworkplan.com/schema/plan-contract/v7.json) adds an
optional `parallel_safe` task marker to the v6 contract, and every
[journal event](https://deepworkplan.com/schema/journal-event/v7.json) can also
record a `delegation`. The live projection keeps the unchanged snapshot at
https://deepworkplan.com/schema/plan-snapshot/v6.json, and the
[task context manifest](https://deepworkplan.com/schema/context-manifest/v6.json)
is shared with v6. An explicit `v6` request still materializes a v6 plan.
A plan never changes generation: v6 plans keep their v6 schemas
([manifest](https://deepworkplan.com/schema/plan-manifest/v6.json),
[contract](https://deepworkplan.com/schema/plan-contract/v6.json),
[journal event](https://deepworkplan.com/schema/journal-event/v6.json)) and
run unchanged; v5 plans keep `state.json` under
https://deepworkplan.com/schema/plan-state/v5.json; existing v1, v2 and v5 plans
are never rewritten or migrated implicitly, and moving a v5 plan to v6 requires
an explicit, previewed migration.

Optional addons are recorded per repository in the tracked addon registry
`.dwp/config.json` (https://deepworkplan.com/schema/dwp-config/v1.json): absent
means not enabled, and the methodology works with every addon disabled. A v7
plan may hand a `parallel_safe` task to another coding agent only when its
contract grants `agent_delegation` and a delegation addon (agentkit or Herdr) is
enabled and detected; a delegate's result stays a claim until the plan's own
gate runner observes it.

New plans receive monotonically increasing numeric IDs with at least three
digits, starting at `PLAN_001_...`. Current v6 and v7 plans use 2–5-word slugs.
The retained v5 flow uses 2–4 words: its allocator requires at least two
slug words, and its frozen schema permits at most four after the numeric ID.
Existing unnumbered `PLAN_<slug>/` folders remain readable and are never renamed.
When numbered plans exist, `latest` resolves to the highest numeric ID.

Every plan has one mandatory closing task: **Final Review**. It runs the
security pass over the accumulated change set, including the required local
AI Diff Reviewer review, validates the final repository state, reconciles the
skills used by the tasks, and records the evidence and limitations. The local
review skill is installed at a pinned release; the current documented command
installs `https://github.com/DailybotHQ/ai-diff-reviewer/tree/v3.3.0`. The GitHub Action is a separate,
optional CI surface and is never required for the core methodology.

A review that ran and reported nothing is not the same as a review that never
produced findings at all. The second case is an **incomplete review**: it is
recorded as such, never counted as evidence that the change set is clean, and
never a reason to close the Final Review. Together with a missing reviewer
(recorded as a finding) and an invocation that errored (warned once and
continued), that is three distinct states — and none of them means the diff was
reviewed and found clean. A body that says
`Recommendation: approve` is not evidence the check passed either. Read the
tracking marker's Highest severity / Strictness gate / Check status block
first — the runtime rewrites a model `approve` whenever the gate is failing.

Unattended execution is supported only for a plan approved in advance. It
requires the machine-readable state layer, a declared DWP standard, bounded
authority, and explicit stop conditions. If a gate fails outside the planned
repair scope, the repository diverges, or a new approval or credential is
needed, the agent records the blocker and stops. No flow weakens a validation
gate to claim completion.

## 3. Onboard the repository (reasoned and non-destructive)

Invoke the onboard sub-skill (`/deepworkplan-onboard`). Reason about the real repo and adapt everything
to it. For every artifact below, **if it already exists, reconcile it** (merge, improve, align to the
methodology) instead of overwriting — and confirm with the user before replacing anything.

1. **`AGENTS.md` + `CLAUDE.md`.** Produce an `AGENTS.md` at the root — an index, the mandatory rules
   (English-only, conventional commits, the repo's real test pattern and review gates), compact
   **working principles**, and a Quick Commands block with the repo's **real, runnable** commands.
   If an `AGENTS.md` already exists, merge into it rather than replacing it. Create the
   `CLAUDE.md → AGENTS.md` symlink (do not clobber an existing `CLAUDE.md` without asking).
   Similarly, create the `.cursor → .agents` symlink if absent.

   The working principles go **inline**, near the core rules — an agent that only reads the entry
   point must find them there, not behind a link. Ten behaviors: own the outcome, be resourceful
   before asking, decide routine matters independently, ask when judgment or authorization is
   missing, make approvals concrete, work through obstacles, respect intent and scope, apply
   proportionate rigor, communicate directly, and verify before declaring completion. Assess the
   **meaning** of any rules already present before editing: keep equivalent ones in place, add only
   what is missing, and run a second pass to confirm it produces no further diff. They are defaults
   within the current request, never new authority — they must not override host permissions, a
   narrower scope, plan gates, read-only flows, or this repository's own approval rules. Keep the
   result compact (~300 words) and the whole `AGENTS.md` inside its 150–500-line budget, moving
   detailed procedures to linked docs when it would otherwise overflow.
2. **`docs/`.** Fill the standard categories with real, repo-specific content: `PRODUCT_SPEC.md`
   (the non-technical product/why doc — required for every repo, libraries included), `ARCHITECTURE.md`,
   `STANDARDS.md`, `TESTING_GUIDE.md`, `DEVELOPMENT_COMMANDS.md`, `SECURITY.md`
   (never skipped — every repository has a security posture, even with no secrets),
   `AI_AGENT_ONBOARDING.md`, `AI_AGENT_COLLAB.md`, plus `PERFORMANCE.md` and a `docs/README.md` index.
   If docs already exist, integrate and extend them — do not duplicate.
3. **Per-module docs.** Add a `README.md` (and a `docs/` subfolder for complex modules) inside each
   major source module discovered in recon.
4. **`.agents/` + `.claude → .agents` + `.cursor → .agents`.** Create the canonical, cross-agent home: a **reasoned** catalog
   of `agents/`, stack-appropriate `skills/`, and thin `dwp-*` `commands/` that delegate to the
   installed skill — every entry justified for *this* repository, not copied from another. Add a
   `docs/` catalog (`skills_agents_catalog.md` + `COMMANDS_REFERENCE.md`) that matches what exists on
   disk, plus `settings.json`, and both the `.claude → .agents` and `.cursor → .agents` symlinks. Fold any existing skills/agents
   into the catalog.
5. **The DWP skill, adapted.** The installed skill is the engine; the repository's own kit
   (skills, agents, commands) must be **reasoned for this repo** — never a copy-paste of another
   repository's kit.
6. **`.dwp/` + `tmp/`.** Scaffold a gitignored `.dwp/` with `plans/`, plus a `tmp/`
   scratch space — both added to `.gitignore` non-destructively (append, never rewrite).
   They are not interchangeable: everything a flow produces **about a plan** — the
   analysis, the skills ledger, the security review, gate logs, audit reports — MUST
   live in that plan's own `.dwp/plans/PLAN_001_<slug>/analysis_results/`, never at the
   repository root and never in `tmp/`. `tmp/` is for work no plan will ever read
   back. When a repository's own tooling defaults a report path to the working
   directory, pass its explicit output flag into the plan folder instead of accepting
   the default.

## 4. Install the required local review, then offer the opt-in addons

After the baseline onboarding, install the **AI Diff Reviewer local review** (Phase 7a — required
since standard 2.3.0): the tag-pinned vendored skill
(`npx --yes skills add https://github.com/DailybotHQ/ai-diff-reviewer/tree/v3.3.0 --skill ai-diff-reviewer -y`) plus a
repo-tailored `.review/extension.md` via `generate-extension`, under the onboarding consent. Then
enumerate the seven optional addons (devcontainer, Dailybot, dependency upgrade, design system,
agentkit, Herdr, DeepWorkPlan Vim) and offer each as an explicit opt-in, recording every acceptance
in `.dwp/config.json`. A repository is fully conformant with **zero** optional addons — never
auto-install those.

- **Devcontainer support** — a thin integrator of [devcontainer-kit](https://github.com/DailybotHQ/devcontainer-kit) (`dck`, pinned `v0.1.4`): `dck init` renders a Dev Containers template and reconciles an existing devcontainer only after its diff is accepted; base images ship without coding agents.
- **Dailybot integration** — four lifecycle events (kickoff, significant task, blocked, completion) as best-effort progress reports for teams already using Dailybot, with optional autonomous hook enforcement (`dailybot-cli >= 3.9.0`). Installing the paired Dailybot agent skill (3.23.3) also exposes chat, check-ins, forms authoring, ask AI, Plan boards and tasks, per-repo API keys, and more — the addon wires only reporting into DWP execution. The core methodology has zero Dailybot dependency.
- **Dependency upgrade** — package-manager-agnostic, batched, validated, revertible upgrades. When
  accepted, it installs the `/lib-upgrade` command.
- **Design system** — opt-in `docs/DESIGN.md` for repos with a detected interface surface only
  (not offered for pure libraries, headless services, or infra-only repos). Three profiles stack in
  one file: visual-ui (strongly recommended when detected; installation acceptance-gated), cli-output, and conversational — the latter two
  are always asked, never auto-applied.
- **agentkit** — a machine-level install of [coding-agents-kit](https://github.com/DailybotHQ/coding-agents-kit) (`ak`, pinned `v0.1.1`) for plans that hand bounded `parallel_safe` tasks to other coding agents (headless, one `ak run` per delegate in its own worktree); autonomy flags are never added by default.
- **Herdr** — a machine-level install of [herdr-peers](https://github.com/DailybotHQ/herdr-peers) (pinned `v0.1.0`, plus Herdr's official skill) for plans that ask a peer agent in a Herdr pane, on any machine, for one authorized reply.
- **DeepWorkPlan Vim** — the terminal editor ([deepworkplan-vim](https://github.com/DailybotHQ/deepworkplan-vim), pinned `v0.4.2`), a machine-level install that never overwrites an existing Neovim configuration without explicit consent.
- **AI Diff Reviewer** — the required local review (not an opt-in): every Final Review's security
  pass runs [AI Diff Reviewer](https://github.com/DailybotHQ/ai-diff-reviewer) **v3** (skill + required
  `.review/extension.md`) over the plan's accumulated change set. A missing skill or extension is a
  recorded `local reviewer not installed` finding — never a silent skip, and never a surprise bootstrap:
  installation belongs to the onboarding consent or an explicit addon invocation; invocation errors soft-fail; **verified** `critical` findings from a completed pass still
  block completion (v3, BC-07 — unverified critical claims arrive as annotated warnings, and an
  `incomplete`/`timeout` review is not a clean pass, BC-04). **Flow B** (the CI gate with `pr-review.yml`) is offered as an explicit opt-in and
  never installed unrequested. No Deep Work Plan flow requires a commercial service, CI provider, or secret.

## 5. Evolve the kit (author sub-skill)

Use the `author` sub-skill to grow the repository's own kit after onboarding. The thin delegators
`/skill-create` and `/agent-create` route to it. Create a **skill** for a repeatable in-session
procedure, an **agent** for a recurring role with its own model tier and tools, and a **command** only
as a thin delegator. Keep the `.agents/docs/` catalog in sync with what exists on disk.

## 6. Plan and execute

Generate Deep Work Plans for any task and run them task by task:

- `/dwp-create <goal>` — turn a goal into an executable plan. Since standard 2.4.0 a plan has two formats: **Lite**, whose task records live inline in the plan's README, for small bounded work; and **Full**, one file per task, for long-horizon work. Both carry the same contract — stable task ids, touched surface, acceptance criteria, validation gates, completion evidence and one Final Review — so Lite costs less to represent without being weaker. Add `lite` or `full` to force a format and `trust` to materialize without a review round; with no preference DWP recommends one and explains why. A Lite plan is promoted with `/dwp-refine promote`.
- `/dwp-execute` — execute the plan task by task, updating progress and validating each gate.
- `/dwp-status` — report progress without making changes.
- `/dwp-refine` — add, remove, or reorder tasks while preserving completed work.
- `/dwp-resume` — reconstruct state and continue an interrupted plan.
- `/dwp-verify` — objective pass/fail conformance report for the repo (or a specific plan).

Every plan closes with the Final Review — a security pass over the plan's own
changes (keeping `docs/SECURITY.md` current; a critical finding blocks completion), the
final-state validation, and the reconciliation of skills decisions. The Executive Report
remains available on request.

## 7. Verify

Run `/dwp-verify` for an objective pass/fail conformance report (or
`bash {skill_dir}/verify/conformance.sh` for the CI-friendly mechanical layer that exits `0`/`1`, and `2` with an explicit `UNVERIFIED` verdict when it cannot run its checks — it never reports a pass it did not verify).
It checks the criteria in the [specification's Conformance document](https://deepworkplan.com/spec).
Then confirm:

- [ ] The skill is installed and resolvable, with all nine sub-skills available.
- [ ] `AGENTS.md` exists at the root with a real Quick Commands block and inline working principles covering the ten behaviors; `CLAUDE.md` resolves to it.
- [ ] `docs/` holds the standard categories with real, repo-specific content; `docs/TESTING_GUIDE.md`
      describes a real test/lint setup (not empty or stub); major modules have a `README.md`.
- [ ] `.agents/` exists with `agents/`, `commands/` (thin `dwp-*` delegators that reference the skill,
      not copied flows), `skills/`, and a catalog that matches what exists on disk;
      `.claude → .agents` and `.cursor → .agents` resolve.
- [ ] `.dwp/` exists, is gitignored, and has `plans/`; `tmp/` exists and is gitignored.
- [ ] Existing user content was preserved or reconciled with consent — nothing was destroyed silently.
- [ ] You can generate a Deep Work Plan and execute it task by task, validating each gate.

## Outcome

When onboarding is complete the repository is changed in two durable ways — the pillars of the
methodology:

1. **The repository is spec-driven.** Work begins from a written plan and specification, not from
   ad-hoc prompts.
2. **The repository itself is the agent harness.** `AGENTS.md`, `docs/`, per-module docs, and the
   `.agents/` skill home give every agent the context and commands it needs to do structured,
   verifiable work.

Anyone can run this prompt on any repository — and end with a codebase any AI agent can pilot.