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

Data	Required	Source	Notes
Project charter (project-charter.md)	yes	knowledge or chat	Approved charter. Extract: goal, scope, dates, budget (if present), team, constraints, top-3 risks
Duration estimates	no	chat or knowledge	Work package estimates from the user. If absent — agent estimates and marks as assumption
Team availability data	no	chat or knowledge	Load by period, constraints (vacations, part-time). If absent — agent distributes evenly, marks as assumption
Additional inputs	no	chat	Priorities, external dependencies, technical constraints not included in the charter

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).