Deepworkplan Create

DeepWorkPlan — Create

Create a new Deep Work Plan through a smooth, unified flow: the developer provides information once, you generate a single refined draft, the developer reviews it, and you materialize the final plan under .dwp/plans/PLAN_{name}/.

> Single-step change (vs legacy): DeepWorkPlan generates the refined draft > directly. There is no separate raw-draft file. This replaces the legacy > draft → refined-draft two-step (which wrote PLAN_{name}_draft.md and then > PLAN_{name}_draft_refined.md). The only reviewable draft artifact is now > .dwp/drafts/PLAN_{name}_draft_refined.md.

Philosophy

The goal is a delightful, smooth experience. The user provides information once; the system handles all intermediate steps (refined-draft creation, review, final plan generation) automatically.

Shared resources (read these)

• [../shared/context.sh](../shared/context.sh) — resolve repo root, branch,

agent tool, and the .dwp/ output location (dwp_dir).

• [../shared/dwp-paths.md](../shared/dwp-paths.md) — the .dwp/plans/ +

.dwp/drafts/ output convention.

• [../shared/adaptation.md](../shared/adaptation.md) — reasoning-over-copy-paste

and the two repository archetypes (individual repo vs orchestrator hub).

• [../guide/GUIDE.md](../guide/GUIDE.md) — the full methodology: plan README

structure, task-file anatomy, mandatory final tasks, orchestrator (§13), team agents (§14).

• [../examples/CREATE_PLAN.md](../examples/CREATE_PLAN.md) — prompt patterns.
• [../examples/PROMPTS_TEMPLATE.md](../examples/PROMPTS_TEMPLATE.md) — the

PROMPTS.md template for each plan.

Parameter Reference

| Input | Classification | Mode | Behavior | Example | |-------|---------------|------|----------|---------| | (none) | — | guided | Ask for name, then ask questions | /dwp-create | | {short text} | name-only | guided | Extract name, ask questions immediately | /dwp-create improve error handling | | {long text} | full-context | guided | Infer name, proceed to refined draft directly | /dwp-create Refactor auth to use JWT across all services. Currently using sessions... | | trust or auto | — | trust | Ask for name, then ask questions (no confirmations) | /dwp-create trust | | {short text} trust | name-only | trust | Extract name, ask questions (no confirmations) | /dwp-create improve-error-handling trust | | {long text} trust | full-context | trust | Infer name, proceed directly (no confirmations) | /dwp-create Refactor auth... trust | | refined-draft {name} | — | refined-draft-only | Produce ONLY the refined draft (no final plan) | /dwp-create refined-draft my_plan | | from-refined-draft {file} | — | from-refined-draft | Build final plan from an existing refined draft | /dwp-create from-refined-draft PLAN_x_draft_refined.md | | from {file} | — | from-refined-draft | Alias for from-refined-draft | /dwp-create from PLAN_x_draft_refined.md |

> Name format: users type names in any format; you auto-convert to > snake_case internally.

Modes

Guided Mode (default)

• Collects information from the user.
• Creates the refined draft → shows it for review.
• Asks for confirmation before creating the final plan.
• User can request adjustments before final generation.

Trust Mode (trust or auto)

• Collects information from the user.
• Creates the refined draft → final plan automatically (no intermediate

confirmations).

Unified Workflow

Step 0 — Parse Parameters & Determine Mode

0.1 Detect trust mode: if the LAST word is trust or auto, remove it and set trust_mode = true; otherwise false.

0.2 Detect special modes (check FIRST word):

• refined-draft → mode = "refined-draft-only", remaining text = plan name.
• from-refined-draft or from → mode = "from-refined-draft", remaining text

= refined-draft file path.

• Otherwise → continue to input classification (0.3).

0.3 Classify remaining input:

| Condition | Classification | What to do | |-----------|---------------|------------| | No remaining text | no input | Go to Step 1, then Step 2 (ask for name + all info) | | ≤10 words AND no complete sentences AND no line breaks | name-only | Convert to snakecase → plan name. Go to Step 1, then Step 2 (skip name question) | | >10 words OR detailed sentences OR line breaks | full-context | Infer plan name → snakecase. Go to Step 1, then Step 3 (use provided context) |

Name auto-conversion to snake_case: lowercase; replace hyphens/spaces with _; strip everything but a-z0-9_. Examples: improve Feature X → improve_feature_x, add-stripe-payments → add_stripe_payments.

> CRITICAL: when input is name-only, NEVER explore the codebase or > research the topic before asking questions. The name only says what to CALL the > plan, not what to DO. Go directly to Step 2.

Routing by mode:

• from-refined-draft → skip to Step 4.3.
• refined-draft-only → gather info, create only the refined draft, skip final

plan creation.

• no input / name-only → Step 1, then Step 2.
• full-context → Step 1, then Step 3.

Step 1 — Quick Introduction

Show a brief intro matching the mode (guided vs trust): what will happen and that you'll create a refined plan, review it (guided) or proceed (trust), then generate the final executable plan.

Step 2 — Gather Information (Conversational)

> Skip this entire step for full-context input — go straight to Step 3.

Collect, conversationally:

• 2.1 Plan name (skip if already extracted) — auto-convert to snake_case, add

PLAN_ prefix internally.

• 2.2 Objective — one or two sentences.
• 2.3 Context — where the changes live, constraints/rules, tech notes.
• 2.4 Tasks — at least 2; if only 1, suggest breaking it down.
• 2.5 Guidelines (optional) — branch/commit format, coverage target, etc.

2.6 Orchestrator detection (automatic). After 2.3–2.4, auto-detect an orchestrator plan when: the work spans 2+ sub-repositories with independent feature work, or the user explicitly mentions child DWPs / orchestrator / "create plans in each repo". If detected, offer the choice between an orchestrator plan (creates child DWPs per repo, each following its own AGENTS.md) and a direct multi-project plan. See ../guide/GUIDE.md §13 and ../shared/adaptation.md (orchestrator-hub archetype).

2.7–2.9 (orchestrator only): ask for target repositories (note each repo root — for an orchestrator hub this is repositories/{repo}/), dependency order, and execution mode (Distributed / Sequential with Output Handoff / Sequential basic). Default to Distributed.

2.10 Team-agents detection (automatic — always runs, non-orchestrator plans). Always analyze whether 2+ tasks touch different files/modules with no data dependencies and would benefit from parallel execution. This is NOT opt-in.

• If parallelizable: in guided mode, inform the user (do not ask) and add the

team-agents configuration; in trust mode, do it silently. Team-agents metadata is always additive and backward compatible (other agents ignore it).

• Auto-assign parallel groups (tasks with no cross-dependencies), teammate roles

(derived from task content), and default model sonnet. Setup/integration and the three mandatory final tasks are always sequential.

• If not parallelizable: add nothing, mention nothing.

Step 2.11 — Parallel Research Phase (Claude Code only, automatic). Before drafting, if the plan spans 2+ repos or several independent modules and context isn't already provided, spawn research teammates (subagent_type: "Explore", one per repo/area) to read each AGENTS.md, identify relevant files, contracts, and validation commands, then synthesize their findings into enriched context for the refined draft. Skip for simple/single-module plans or full-context input. Fallback: research sequentially if team agents are unavailable. In trust mode, run silently.

Step 3 — Create the Refined Draft (Automatic, SINGLE STEP)

> This is the single-step change. Produce the refined draft directly — > one file, written straight to .dwp/drafts/. Do NOT create a separate raw > PLAN_{name}_draft.md first.

Show a 2-step progress UI:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Creating your plan...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[1/2] Drafting refined plan...

3.1 Write the refined draft:

• Resolve dwp_dir via ../shared/context.sh; ensure /drafts/ exists.
• Compose a professional, complete plan prompt following

../examples/CREATE_PLAN.md: objective, context (enriched with Step 2.11 research if applicable), well-formed tasks, guidelines. Expand every section with full detail and clarity in one pass.

• Write only: .dwp/drafts/PLAN_{name}_draft_refined.md.

[1/2] Drafting refined plan... ✓
[2/2] Preparing for review...

Step 4 — Review & Create Final Plan

4.1 Guided Mode — Show for Review

Present a summary (objective, task count + list, location, constraints) and the path → .dwp/drafts/PLAN_{name}_draft_refined.md, then offer:

1. Looks good, create the final plan → Step 4.4.
2. Make adjustments → ask what to change, edit the refined draft in place,

show the menu again.

1. Show the full refined draft → display it, then re-show the menu.
2. Stop here → completion message for the draft phase.

4.2 Trust Mode — Automatic Continue

Skip review; go directly to Step 4.4. Progress: [2/2] Creating final plan....

4.3 From-Refined-Draft Mode

• Validate the file exists in .dwp/drafts/. If not found, list available

refined drafts and ask the user to select.

• Read it; extract plan name, objective, context, tasks, guidelines.
• Skip to Step 4.4.

4.4 Create Final Plan

Follow ../guide/GUIDE.md. Create:

1. Folder: .dwp/plans/PLAN_{name}/
2. README.md — Goal; Context; Plan Variables (optional); Global Guidelines;

Task List with [ ] checkboxes + links (including the three mandatory final tasks); Execution Rules; Skills & Agents Used; Plan Status / Notes; Analysis Outputs (referencing EXECUTIVE_REPORT.md); Quick Reference to PROMPTS.md.

1. PROMPTS.md — from ../examples/PROMPTS_TEMPLATE.md, replacing

{PLAN_NAME}.

1. PROGRESS.md — initial template (Task Summaries / Key Decisions / Important

Values & Paths).

1. analysis_results/ — empty folder inside the plan directory.
2. User-defined task files — N.task_{title}.md, each with Context, Read

Before Starting (optional), Goal, Instructions (with re-anchoring), Acceptance Criteria, Outputs (optional), Validation, Rollback (optional), Execution Checklist, Completion & Log. For any task that adds new core functionality or changes product behavior, bake the test discipline into it (../guide/GUIDE.md §5.3): its Acceptance Criteria must require automated test coverage for the new/changed behavior, and its Validation must run the repo's tests plus lint/type-check/format checks (not the build alone). Where related work is substantial, prefer a dedicated N.task_add_tests_for_{feature}.md task right after the implementation task. Likewise, for any task that touches auth, input handling, secrets/config, network surface, or dependencies, bake the security discipline into it (../guide/GUIDE.md §5.4); where the security-sensitive work is substantial, prefer a dedicated N.task_security_hardening_{feature}.md task placed after the implementation tasks and before the comprehensive-tests task, so findings are fixed before tests encode the behavior and become regression test cases rather than rework.

1. State layer (RECOMMENDED, ../spec/PLAN_STATE.md) — write

manifest.json (plan identity: name, archetype, rigor tier, spec version, task count, creating agent — once, never edited after) and the initial state.json (every task pending, empty gates). Both atomically (write-temp-then-rename). REQUIRED when the plan will run unattended (../spec/AGENT_PROTOCOL.md §7.2) or the workspace has no git.

Proportional rigor check first (../spec/DWP_SPECIFICATION.md §11): before materializing anything, confirm the work actually warrants a plan. A trivial single-concern change is micro tier — say that a plan is disproportionate, offer to state goal + acceptance criteria + validation gate inline and just do it. Declare the chosen tier (standard or deep) and why in the refined draft.

Three mandatory final tasks (always):

• Security Review (MANDATORY, third-to-last, task N-2,

{N-2}.task_security_review.md): reviews the plan's full accumulated diff for hardcoded secrets, injection risks, unsafe input handling, new attack surface, and auth/permission changes; audits dependencies the plan introduced (best-effort, with the ecosystem's audit tooling where available); verifies docs/SECURITY.md still reflects reality and updates it when the plan changed secrets handling, the auth model, or data boundaries; writes analysis_results/SECURITY_REVIEW.md even when clean. A critical finding blocks completion until fixed or explicitly accepted by the user (../spec/DWP_SPECIFICATION.md §6.1).

• Skills & Agents Discovery (MANDATORY, second-to-last, task N-1,

{N-1}.task_skills_agents_discovery.md): reviews completed tasks for new patterns, checks the catalog, creates/updates skills/agents if warranted, evaluates the skills-generator system. If no skills-generator exists in the target repo, write a simplified evaluate-and-document-only version.

• Executive Report (MANDATORY, last, task N,

{N}.task_executive_report.md): generates analysis_results/EXECUTIVE_REPORT.md with Executive Summary, Product Impact, Technical Details, QA Verification Guide, FAQs, Next Steps.

Add to the README a note: "Every plan includes Security Review (third-to-last), Skills & Agents Discovery (second-to-last), and Executive Report (last). These are auto-generated by /dwp-create."

Quality gates: atomic, ordered tasks; both mandatory files present; analysis_results/ exists; PROGRESS.md exists; numbering correct (user tasks → security review → skills discovery → executive report); behavior-changing tasks carry test coverage in their Acceptance Criteria and tests + lint/type-check in their Validation (../guide/GUIDE.md §5.3).

Accelerate generation with team agents (Claude Code only, automatic): for 5+ user-defined task files, the lead creates README/PROMPTS/PROGRESS/ analysis_results + the mandatory final task files, then spawns teammates (1 per 2–3 task files) to write user task files in parallel (no file overlap), verifies all files, and cleans up. Fallback: generate sequentially.

Orchestrator additions (orchestrator plans):

• README Child DWP Plans table (`# | Repository | Child Plan | Status |

Depends On`), an Execution Mode subsection, and Dependency Rules.

• ORCHESTRATOR_MANIFEST.md at .dwp/plans/PLAN_{name}/ORCHESTRATOR_MANIFEST.md

(template in ../guide/GUIDE.md §13.8): Shared Context, Child DWP Registry, Dependency Graph, Output Contracts, Execution State.

• Task files: direct design tasks first (if hybrid); then create_child_dwp

tasks in dependency order (template ../examples/ORCHESTRATOR_TASK_TEMPLATE_create_child_dwp.md); optional integration_checkpoint tasks (../examples/ORCHESTRATOR_TASK_TEMPLATE_integration_checkpoint.md); execute_child_dwp tasks for Sequential-with-Output-Handoff mode (../examples/ORCHESTRATOR_TASK_TEMPLATE_execute_child_dwp.md); then the two mandatory final tasks last. Each create_child_dwp task instructs the agent to navigate to the target repo, read its AGENTS.md, and create a child DWP at repositories/{repo}/.dwp/plans/PLAN_{child}/ using tha

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: DailybotHQ
• Source: DailybotHQ/deepworkplan-skill
• License: MIT
• Homepage: https://deepworkplan.com/

Install and usage instructions live in the source repository linked above.