Generate Actionable Project Plans

Plan Writing turns a development goal into clear, actionable tasks with verification criteria. Each task has one focused outcome that can be checked independently. The framework encourages small units of work, identifies dependencies, highlights the critical path, and allows parallel work where dependencies permit it. Verify each task as it is completed, then run a final acceptance check for the overall result.

The planning style is deliberately concise: aim for five to ten clear tasks, avoid lists of every micro-step, and simplify a plan that grows beyond a page. Task descriptions should name concrete actions and observable results rather than generic intentions such as setting up a project or checking that a component works.

Use it for starting a project, adding a feature, fixing a complex bug, or refactoring several files. The content changes with the kind of work. A new project needs decisions about the technology stack, minimal feature scope, and file structure. A feature plan identifies affected files, required dependencies, and functional verification. A bug-fix plan identifies the root cause, the relevant file or line, and a way to test the correction.

Do not apply a fixed template mechanically or attach every available script to every plan. Use only existing, inspected scripts that are relevant to the change. The example audit and validation script names illustrate categories rather than bundled prerequisites. Missing inputs, permissions, boundaries, or success criteria require clarification.

Inputs are the task goal, project type, affected implementation areas, dependencies, and success criteria. The output is a short Markdown plan with a goal, actionable checklist, verification for each item, and overall completion conditions. Optional notes can capture important considerations without adding unnecessary phases or subsections.

The opening of the flexible example is:

# [Task Name]

One sentence: What are we building/fixing?

Plan files normally use a task-derived filename in the project root. Repository or user conventions can specify a different location, and an existing supplied plan should be preserved. Mark completed tasks as work progresses. If the work requires more than ten tasks, divide it into multiple plans rather than creating a deeply nested checklist.

Verification can be a visible interaction, an API request with an expected result, or another direct check suited to the change. Frontend, backend, mobile, database, and full-stack work call for different relevant checks. The plan's value comes from connecting each specific action to evidence that its intended outcome occurred.