Project Plan

When to Use

When a Spec is approved and needs to be broken into implementable Plans.

Inputs

• Project path ({Dept}/Projects/{Project}/)
• Vision document
• Spec document

Procedure

1. Read Vision and Spec
2. Update {Project}_Phase.md: set Phase: Plan_Started
3. Identify natural breakpoints — the Spec should decompose into units that can each be completed in a single focused agent session
4. For each Plan:
   • Copy Forge/Forge_Project/Skills/Project_Create/templates/Plan_Template.md to {Project}_Plan_{N}.md
   • Each Plan is a separate file. One Plan per file — never combine multiple Plans into one file
   • Number Plans sequentially: Plan 1, Plan 2, etc. Even a single plan is Plan 1, written to {Project}_Plan_1.md
   • Write Tasks with enough context that the implementing agent never needs to consult Vision or Spec (the self-containment rule)
   • Set document status to draft
5. Validate self-containment: for each Plan, verify an agent could implement it with only the Plan and Execute_State
6. Add sidebar entries by spawning the Page Manager bot via spawnAgent with { botGroup: 'forge', botHandle: 'page-manager' }
7. Build, commit, push
8. Proceed directly to Plan_Eval — do not wait for user approval before evaluation
9. Set all Plan document statuses to review
10. After Plan_Eval converges (no findings, or all findings auto-resolved), present the final Plans to the user for approval
11. Iterate on any remaining user feedback
12. Set all Plan document statuses to approved
13. Update {Project}_Phase.md: set Phase: Plan_Completed
14. Build, commit, push

Plan Quality Criteria

• Scoped: Each Plan covers a coherent slice of work (not too broad, not too narrow)
• Ordered: Implementation happens in a logical sequence, previous Plans implementing dependencies of later Plans
• Self-Contained: Plan and referenced resources contain all context needed to implement — implementer should not need to read upstream docs
• Testable: The output of a completed plan can be tested before later plans are implemented

Task Quality Criteria

• Ordered: Tasks respect dependencies — no forward references
• Actionable: Each step is specific enough to execute without ambiguity
• Verifiability: Each task has a clear output that can be verified

Rules

• Each Plan must be implementable in a single focused agent session
• Plans are self-contained: the implementing agent reads only Plan + Execute_State
• Plans do not contain checkboxes — that’s the Execute_State’s role
• The next phase (Project_Execute step) produces its own numbered Execute_State document ({Project}_Execute_State_{N}.md where N matches the Plan number)
• Plans are frozen once the next Plan’s execution starts — during a Plan’s own Execute/Execute_Eval cycle, the Plan can be updated to correct mistakes or outdated information
• Later Plans are tentative and may be revised based on evaluation of earlier Plans
• Number Plans sequentially: Plan 1, Plan 2, etc. Even a single plan is Plan 1
• One file per Plan: Each Plan is a separate file named {Project}_Plan_{N}.md. Never combine multiple Plans into one file. If you repartition during a Plan_Eval auto-fix round (e.g., 5 Plans → 7 Plans), each resulting Plan still gets its own file — create new {Project}_Plan_{N}.md files rather than stacking Plans inside a single {Project}_Plan.md
• Planning scope rule: Updating a plan means editing the Plan (and Execute_State if it exists) only, and Vision+Spec if changes there are required. Never create, modify, or delete any other file when updating a plan. Implementation is a separate step