Generate Project Plan

generate-project-plan

Language Detection

Determine the language of the user's request:

• If the request is in Russian → use templates with -ru suffix
• Otherwise → use templates with -en suffix

All output (headings, labels, comments, instructions) must match the detected language.

Triggers

Russian: «сформируй план проекта», «подготовь план», «составь project plan», «нужен план проекта» English: "generate project plan", "create project plan", "build plan", "prepare project plan"

1. Inputs

If no charter is available — request it (system-prompt-draft.md §3 p.2):

A project plan requires an approved charter (project-charter.md).
Available data: [list what is available].
Charter status: [not started / draft / approved].
If the charter has not been created yet — start with generate-charter.

2. Execution Algorithm

1. Validate inputs. Check for an approved charter. Not found → request per §1 template. Do NOT generate a plan without a charter — this breaks the dependency chain. Found → step 2.
2. Extract data from the charter. Break down by category: goal, scope (included/excluded), dates (start/end), budget (if specified), team, constraints, risks. Record gaps.
3. Check data for conflicts. If charter dates conflict with user-provided duration estimates — do NOT resolve independently. List discrepancies, ask which takes precedence. Exception: if the user explicitly clarifies in chat — use the clarification.
4. Decompose scope into work packages (WP). Each deliverable from the charter's "Included" section → one or more WPs. Granularity: a WP is a group of related tasks with a single output. Do NOT decompose to individual tasks — that is Jira level. Assign each WP an ID (WP-001, WP-002, etc.). Group WPs by project phase. After decomposition, count total WPs: if >20 — consolidate adjacent packages within the same phase. WP count must be ≤ 20 for MVP. If consolidation would lose meaning — record as assumption and proceed to step 5.
5. Set duration for each WP.
   • Use user-provided estimates if available.
   • If no estimates — assess based on: scope volume, resource count, comparable projects, charter constraints. Mark each such estimate as assumption.
   • Unit: project ≤ 3 months → working days (wd); project > 3 months → weeks (wk). Unit must be consistent within one plan. 1 wk = 5 wd.
   • Verify: sum of critical path durations (accounting for maximum parallelism) ≤ total project duration from charter. If it doesn't fit — record as issue, propose options (parallel execution / scope reduction / resource increase / date shift). Do NOT generate WP dates beyond the charter end_date. If unavoidable — mark affected WPs with [⚠ exceeds deadline] and require a decision from the user before finalizing.
6. Identify dependencies between WPs. For each related WP pair: dependency type (FS / SS / FF). FS is the default if the relationship is not explicit. Verify no circular dependencies.
7. Define milestones. A milestone is a checkpoint marking the achievement of a significant result. A milestone is NOT a task — it has zero duration. It answers "what must be done by this point", not "what needs to be done". What counts as a milestone: phase completion (all WPs in phase closed); delivery of a key deliverable to the customer; external event the project depends on (approval, procurement, integration); go/no-go decision point. What does NOT count as a milestone: completion of a routine WP that is not a deliverable; internal intermediate results without external review; recurring events (weekly status, sprint reviews). Milestones from the charter (section 3) — must be included. ID: M1, M2, etc. Minimum: 3 milestones (start, mid, finish). Maximum: one per phase + key deliverables.
8. Fill the resource map.
   • Use availability data if provided.
   • If not — take team from charter (section 5), distribute across WPs by role, treat load as uniform. Mark as assumption.
   • Period columns — actual project months (not fixed).
9. Read the template project-plan-ru.md (or project-plan-en.md) from project knowledge.
10. Fill the template per the rules in section 3.
11. Validate the output using the checklist (section 5).
12. Present the output in chat. Format (system-prompt-draft.md §3 p.4):
    • What was done: "Project plan generated based on [list sources]."
    • Assumptions: list all (duration estimates, resource allocation, etc.).
    • Issues: if found (schedule overrun, insufficient resources).
    • What is required: "Approve, provide comments, or reject."
    • Do not include system paths. Use file name only: "Plan saved as project-plan.md."
13. Wait for user response (system-prompt-draft.md §3 p.5).
    • Approval → generate final version.
    • Comments → revise, show updated version. After 3rd iteration — ask: "Continue revising or finalize the current version?"
14. After approval:
    • Propose text for the user to insert into log.md and project-state.md (system-prompt-draft.md §11).
    • Notify: "Project plan approved. The following tasks are now available (can run in parallel): generate-risk-register (detailed risk register) and generate-comm-plan (communications plan). Which one to start?" (system-prompt-draft.md §7).

3. Section Fill Rules

Header Metadata

• Version: 1.0
• Date: current generation date.
• File: project-plan.md
• Document status: draft (on generation). After approval — approved.
• Source: list documents used to generate the plan.

"Project Summary" Section

• Fill from the charter. Fields Project goal, Dates, Team, Customer, PM — required.
• Project goal — from charter section 1 (verbatim or condensed).
• Dates — start_date and end_date from charter; duration — calculate.
• Budget — from charter section 4 (total amount). If not specified — enter: "not defined". The plan is generated without budget data. This does not block generation.
• Team — headcount from charter section 5.
• Customer and PM — from charter sections 5/8.

"Phases and Work Packages" Section

Table is the core of the plan.

• Minimum WPs: one per deliverable from the charter.
• Maximum WPs: no more than 20 for MVP. Consolidate if exceeded.

"Milestones" Section

"Dependencies" Section

Table details the relationships from the WP table's Dependencies column.

• Verify: no circular dependencies (A→B→C→A).
• Every dependency from the WP table must appear here.

"Assumptions and Constraints" Section

• Assumptions: all agent assumptions (duration estimates, resource allocation, priorities). One item per line.
• Constraints: from charter (section 6) + identified during planning.

"Resource Map" Section

• Use provided load data if available.
• If not — distribute evenly across WPs, mark as assumption.
• Total load per person per period must not exceed 100% (record as issue if exceeded).

4. Placeholder Table

Placeholders {{}} in the template are fill-in guides, not auto-substitution variables. Replace each with the corresponding value from the inputs.

5. Validation Checklist

Before presenting the output to the user — verify:

• Charter used as primary source (no fabricated data)
• All required placeholders replaced with values
• No {{}} placeholders remain in the text
• Every deliverable from the charter is covered by at least one WP
• Dates are consistent: start_date ≤ WP dates ≤ end_date
• No circular dependencies between WPs
• Charter milestones included; milestone dates match the end of corresponding WPs/phases
• Each milestone meets the criteria from §2 p.7: marks phase completion, deliverable handoff, external event, or go/no-go. No "false milestones" (routine WP completion, recurring events)
• Completion criterion for each milestone is specific and verifiable (contains artifact/result + action + by whom)
• Sum of durations (accounting for parallelism) ≤ total project duration. If not — recorded as issue
• Duration unit is consistent throughout the plan (wd or wk) and follows the rule: ≤ 3 months → wd, > 3 months → wk
• Each resource load ≤ 100% per period (or issue is recorded)
• All agent assumptions listed in the Assumptions section
• Document status = draft
• File: project-plan.md listed in the header

6. Dependencies

Consumes (input):

• project-charter.md (approved) — from skill generate-charter
• Optional: duration estimates and team availability data from the user

Produces (output): project plan → consumed by skills (system-prompt-draft.md §7):

• generate-risk-register (mode: detailed) — phase 2, Planning (parallel with comm-plan)
• generate-comm-plan — phase 2, Planning (parallel with risk-register)
• generate-resource-plan — phase 2 (Product 1, not MVP)
• monitor-progress — phases 4–5 (Product 1)
• generate-plan-fact-report — phase 6
• coordinate-executors — phases 3, 5 (Product 1)
• generate-checklist — phases 5, 6 (Product 1)

After the plan is approved, the user must upload project-plan.md to project knowledge so dependent skills can access it.

7. Example Invocation

User command:

Generate a project plan. The charter is approved and uploaded to knowledge. I don't have duration estimates for work packages — assess based on scope.

Agent response (after generation):

Project plan "[name]" generated based on: project charter (project-charter.md).

Assumptions:

• Duration of all work packages estimated by the agent based on scope volume and team composition.
• Team load distributed evenly (no availability data provided).
• Phase priority: Development → Testing → Launch (standard order for IT projects).

Issues:

• [Name]'s load exceeds 100% in May (WP-005 + WP-007 in parallel). Options: shift WP-007 to June or add a resource.

Required: approve, provide comments, or reject.

[plan text]

Changelog