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

---

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.

Column	Rule
ID	Unique code: WP-001, WP-002, etc. Sequential numbering
Phase	Phase name (Initiation, Planning, Development, etc.). Group WPs by phase
Work package	Group of related tasks with a single output. NOT an individual task — task-level detail belongs in Jira
Owner	Role or name from charter team
Duration	Unit selected by project duration: ≤ 3 months → working days (wd); > 3 months → weeks (wk). Consistent unit throughout the plan. Use suffix: "5 wd" or "2 wk". Calculation: 1 wk = 5 wd
Start / End	YYYY-MM-DD. Calculate from dependencies and duration. First WP start ≥ charter start_date. Last WP end ≤ charter end_date
Dependencies	IDs of predecessor work packages. "—" if none

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

"Milestones" Section

Column	Rule
ID	M1, M2, etc.
Milestone	Checkpoint — event marking the achievement of a significant result. Zero duration
Date	YYYY-MM-DD. Matches the end date of the corresponding WP or phase
Completion criterion	Specific, verifiable condition. Format: "[artifact/result] [action] [by whom]". Example: "Prototype accepted by customer", "API deployed to staging and passed smoke tests"
Status	On generation: not achieved. Allowed values: not achieved / achieved / overdue

"Dependencies" Section

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

Column	Rule
Source block	ID of WP that must finish/start
Target block	ID of WP that depends on the source
Type	FS (Finish-to-Start) — default; SS (Start-to-Start); FF (Finish-to-Finish)
Comment	Explanation of the relationship. Required for SS and FF types

• 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

Column	Rule
Team member	Name from team roster
Role	Role from charter
Period columns	Project months (adapt to actual dates). Load in % of full working time
Constraints / Notes	Vacations, part-time, outsourcing, dual roles

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

Placeholder	Required	Source	Allowed values
{{project_name}}	yes	charter	text
{{version}}	yes	agent	"1.0" on creation
{{date}}	yes	system	YYYY-MM-DD
{{doc_status}}	yes	agent	draft / pending approval / approved / revision
{{source_docs}}	yes	agent	list of input documents
{{project_goal}}	yes	charter, section 1	text
{{start_date}}	yes	charter, section 3	YYYY-MM-DD
{{end_date}}	yes	charter, section 3	YYYY-MM-DD
{{duration}}	yes	agent (calculate)	"N weeks" or "N months"
{{budget}}	no	charter, section 4	number + currency or "not defined"
{{team_size}}	yes	charter, section 5	number
{{customer}}	yes	charter, sections 5/8	name
{{pm}}	yes	charter, sections 5/8	name
{{phase_name}}	yes (≥1)	agent	project phase name
{{work_package}}	yes (≥1)	agent / scope	work package description
{{owner}}	yes	charter / team	role or name
{{wp_duration}}	yes	user / assumption	number + "wd" or "wk"
{{wp_start}}	yes	agent (calculate)	YYYY-MM-DD
{{wp_end}}	yes	agent (calculate)	YYYY-MM-DD
{{wp_dependency}}	no	agent	WP ID or "—"
{{milestone_name}}	yes (≥3)	charter + agent	milestone name
{{done_criteria}}	yes	agent	completion condition: "[result] [action] [by whom]"
{{assumption_N}}	no	agent	assumption text
{{constraint_N}}	yes (≥1)	charter	constraint text
{{name_N}}	no	charter / team	team member name
{{role_N}}	no	charter / team	role
{{load_period}}	no	data / assumption	number (% load)

---

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

Date	Version	Change
2026-03-25	1.0	Skill created. Algorithm: 14 steps. Hybrid duration estimation model. Resource map with fallback to charter data. Milestone definition criteria. Budget is optional
2026-03-26	1.1	§2 p.4: added explicit WP counter — verify ≤20 after decomposition, consolidate adjacent packages if exceeded. §2 p.5: clarified behavior on date conflict — do NOT generate dates beyond end_date; mark affected WPs with ⚠ and require user decision
2026-03-29	1.2	Translated to English. Added Language Detection block and bilingual triggers