plan-maker

Plan Maker

Use this skill to design a PlanWeave package-shaped plan draft from incomplete input. Write package files only when the user requests materialization. Use plan-auditor to audit an existing package; execution is a separate task requiring an execution request.

Required Planning Checklist

Use the planning checklist to check plan structure, execution options, acceptance criteria, and package validity.

Quick Start

1. Restate the user's goal, non-goals, constraints, and likely success criteria.
2. Ask only blocking clarification questions; otherwise state assumptions and continue.
3. Gather lightweight context from README, current code, schemas, tests, examples, and nearby docs.
4. Identify core objects, lifecycle stages, contracts, risks, and validation paths.
5. Draft tasks, blocks, dependencies, prompt placement, review gates, and verification, then group tasks into canvases using PlanWeave's existing package concepts.
6. End with open assumptions and the recommended next action: refine with the user, audit with plan-auditor, or materialize the draft when explicitly requested.

Context Discovery

• If strong source docs exist and the main job is converting them into a Plan Package, use plan-importer.
• If no docs exist, inspect the current codebase enough to avoid invented architecture.
• Search producers and consumers for likely core objects before splitting tasks.
• Treat user goals as authority, but mark uncertain scope, missing domain rules, and unknown external dependencies.
• Do not invent large product requirements to make the plan look complete.

Planning Principles

• Design around core object lifecycles: create, validate, transform, state, storage, consumption, side effects, final output, failure, retry, rollback, and manual intervention.
• Keep schema, types, APIs, CLI flags, events, files, and prompt inputs/outputs consistent across producers and consumers.
• Split tasks by data flow, contract boundary, ownership, risk, or independently verifiable acceptance.
• Do not split only to create more nodes; merge tiny tasks that cannot be claimed, tested, or reported independently.
• A canvas groups a cohesive deliverable; a task owns an independently verifiable outcome; blocks express its execution and review steps. Put design detail in prompts and keep abstractions proportional to the work.
• Default to one canvas for a cohesive deliverable, with implementation, testing, and acceptance expressed as tasks or blocks. Use multiple canvases for independently delivered or maintained scopes, and state each concrete boundary. A single-canvas plan can omit new project-graph.json materialization; multi-canvas plans use a formal project graph.
• Encode required execution order in graph dependencies and gates, not only in prompts or narrative text.
• Parallel tasks must be genuinely independent in data and contract timing, with writes to shared files, configuration, and build outputs isolated or coordinated.
• Record overlap with parallel.sharedResources; this is advisory, not a lock. Limit concurrency when shared writes cannot be coordinated; use scheduling settings rather than artificial dependency edges.
• Do not schedule broad UI/package polish before foundation contracts and runtime behavior are stable.
• Follow the target repository's existing conventions.