generate-plan-fact-report

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: «сформируй план-факт», «подготовь отчёт план/факт», «сравни план и факт» English: "generate plan-fact report", "plan vs actual", "variance report"

1. Input Data

project-plan.md

project-charter.md

interim

final

If required data is missing — request it:

To generate the plan-vs-actual report, the following are needed:
1. Project plan (project-plan.md) — in knowledge or paste into chat.
2. Actual data — in any format:
   — milestone completion dates (completed, not completed, actual date);
   — actual costs by budget line;
   — which deliverables have been delivered and which have not.
Available: [list what is present].
Missing: [specify].

2. Execution Algorithm

1. Check input data. Verify project plan and actual data are present. Missing → request using the template in §1. Do NOT generate a placeholder report. Present → proceed to step 2.
2. Structure actual data. If free-form — organize across three dimensions: timelines (milestone dates), budget (costs by line), scope (deliverables). Note ambiguities and clarify with the user.
3. Check for data conflicts. If plan data in chat conflicts with

   project-plan.md

   — do NOT resolve independently. List the conflicts and ask which data is current. Exception: if the user explicitly corrects the plan in chat — apply the correction.
4. Determine report period. From actual data: project start → date of last recorded fact. If the user specified a period explicitly — use it.
5. Read the template

   plan-fact-report-ru.md

   or

   plan-fact-report-en.md

   from project knowledge (based on detected language).
6. Extract planned data from

   project-plan.md

   : milestones with dates, budget lines with amounts, deliverables list.
7. Compare plan vs. actual. For each row: calculate variance (absolute and %), assign status per §3 reference table.
8. Fill template sections per Section 3 rules.
9. Evaluate whether Section 4 is needed. Check statuses for all three dimensions independently: Timelines, Budget, Scope. Scope is a full dimension equal to timelines and budget. If at least one of the three has status

   attention

   or

   critical

   (including scope with incomplete deliverables) → fill Section 4. Only if all three are

   on track

   → remove Section 4 entirely.
10. Validate the result using the checklist in Section 5.
11. Present the result in chat:
    • What was done: "Plan-vs-actual report generated for period [dates] based on [list sources]."
    • Assumptions: list all (if any).
    • Key variances: brief (1–3 lines) — main discrepancies and their statuses.
    • Required action: "Approve, revise, or reject."
    • Do not include internal file paths. Filename only: "Report saved as plan-fact-report.md."
12. Wait for user response.
    • Approval → finalize the document.
    • Revisions → revise and present updated version. After the 3rd iteration — ask: "Continue revising or lock current version?"
13. After approval:
    • Offer the user text for

      log.md

      and

      project-state.md

      .
    • Always notify, regardless of report type and variance statuses: "Plan-vs-actual report approved. Next task available: generate-closure-report (project closure report). Start?"

3. Section Fill Rules

Reference: Variance Status Calculation

Applied to each parameter in Section 1 (summary) and to rows in Sections 2–3.

on track

attention

critical

Sign convention: positive = overrun / delay / shortfall; negative = savings / ahead of schedule / surplus.

Section 1. Summary

Three rows — aggregated variances across three dimensions.

• Timelines: Plan — total project duration (working days or calendar days). Actual — actual duration as of report date. If project is not complete — show actual duration with note "project not complete."
• Budget: Plan — total from

  project-plan.md

  (or

  project-charter.md

  ). Actual — sum of actual costs. Currency from input data.
• Scope: Unit — number of deliverables from project charter (

  project-charter.md

  , Section 2 "Project Deliverables"). Plan — total count. Actual — delivered count. If charter unavailable — request the deliverables list from the user.

For each row: calculate absolute variance, variance %, status per reference table.

Summary commentary — required text block after the table. 1–2 sentences per dimension: nature of variance and its cause. If status is

on track

Section 2. Timelines

Row-by-row comparison of milestones from

project-plan.md

• Include all milestones from the plan — not only completed ones.
• If a milestone is not complete — enter

  not complete

  in "Actual Date." Variance — dash.
• Variance in days:

  actual_date - planned_date

  . Positive = delay, negative = ahead of schedule.
• "Variance reason" — fill from user-provided actual data. If reason not stated — enter

  [clarify]

  .

Section 3. Budget

Row-by-row comparison of cost lines from

project-plan.md

project-charter.md

• Include all cost lines from the plan. If no actual data for a line — actual = 0, note "data not provided" in comment.
• Last row — Total: sum of all rows. Verify: total actual = sum of actual rows.
• If a cash flow plan (breakdown by period) is unavailable — use linear distribution of budget over project duration, note

  estimated

  in comment. State as assumption.
• Currency — uniform across the entire report, from input data.

If budget is missing from the project plan and charter — Section 3 is not generated. Replace with note: "Budget section not included: planned budget data unavailable." In the summary (Section 1), replace the budget row with: "Budget — data unavailable."

Section 4. Recommendations / Next Steps

Conditional section. Generate only if at least one of the three dimensions (Timelines, Budget, Scope) has status

attention

critical

critical

attention

on track

• For each variance with status

  attention

  or

  critical

  — formulate a recommended action.
• Specify the owner (from project data) and deadline (if determinable from context). If not —

  [clarify]

  .
• Minimum 1 recommendation per

  critical

  variance.

Header Metadata

• Version

  : 1.0

• Date

  : current generation date

• File

  :

  plan-fact-report.md

• Document status

  :

  draft

  (at generation). After approval —

  approved

  .

• Period

  :

  {{start_date}} — {{end_date}}

• Report type

  :

  interim

  or

  final

  (from input; default

  interim

  )

• Planned data source

  : filename (e.g.

  project-plan.md

  )

• Actual data source

  : source description (e.g. "PM data provided in chat")

4. Placeholder Reference

Placeholders

{{}}

in the template are fill targets, not auto-substitution variables. Replace each with the corresponding value from input data.

{{project_name}}

{{date}}

{{start_date}}

{{end_date}}

{{report_type}}

interim

final

{{source_plan}}

{{source_fact}}

{{planned_duration}}

{{actual_duration}}

{{delta_time}}

{{delta_time_pct}}

{{status_time}}

on track

attention

critical

{{currency}}

{{planned_budget}}

{{actual_budget}}

{{delta_budget}}

{{delta_budget_pct}}

{{status_budget}}

on track

attention

critical

{{planned_scope}}

{{delivered_scope}}

{{delta_scope}}

{{delta_scope_pct}}

{{status_scope}}

on track

attention

critical

{{milestone_name}}

{{planned_date}}

{{actual_date}}

not complete

{{delta_days}}

{{reason}}

[clarify]

{{cost_item}}

{{planned_cost}}

{{actual_cost}}

{{delta}}

{{delta_pct}}

{{comment}}

{{total_plan}}

{{total_fact}}

{{total_delta}}

{{total_delta_pct}}

{{issue_N}}

{{action_N}}

{{owner_N}}

[clarify]

{{deadline_N}}

[clarify]

5. Validation Checklist

Before presenting the result to the user — verify:

• All required placeholders replaced with values
• No

  {{}}

  placeholders remaining in the text (except removed optional rows)
• Report period is valid: start_date < end_date
• Section 1 (summary) contains exactly 3 rows: timelines, budget, scope (if budget missing — 2 rows + note)
• Variance statuses calculated per §3 reference table (≤10% / 11–25% / >25%)
• Section 2: all milestones from the plan included (not only completed)
• Section 2: incomplete milestones show "not complete," variance is a dash
• Section 3: total = sum of rows (verify arithmetic)
• Section 3: if budget missing — section replaced with note
• Section 4: present if any

  attention

  /

  critical

  variances; absent if all

  on track

• All agent assumptions listed when presenting the result
• Document status =

  draft

• File:

  plan-fact-report.md

  stated in header

6. Dependencies

Consumes (input):

• project-plan.md

  — from skill

  generate-project-plan

  (milestones, budget, timelines)

• project-charter.md

  — from skill

  generate-charter

  (deliverables for scope metric)
• Actual data — from the user (via chat)

Produces (output): plan-vs-actual report → consumed by:

• generate-closure-report

  — Phase 6, Closing

After approval, the user must upload

plan-fact-report.md

generate-closure-report

7. Usage Example

User command:

Generate a plan-vs-actual report. Project plan is in knowledge. Actual data: — M1 (Go/No-Go): completed 11.04, on time. — M2 (Plan approved): completed 25.04, on time. — M3 (Prototype): completed 12.05, 3-day delay — design approval. — M4 (Development): not complete. — Budget: AWS — $10,400 (planned $8,000), design — $10,000 (on plan), rest on plan. — Deliverables: 3 of 5 delivered.

Agent response (after generation):

Plan-vs-actual report generated for period 07.04.2026 — 12.05.2026 based on: project-plan.md (knowledge), actual data from chat.

Assumptions:

• Budget lines without explicit data: actual = planned.
• Duration: actual — 35 days (from start to report date), planned — 63 days (full project). Project not complete.

Key variances:

• Scope: 3/5 deliverables (−40%) — status

  critical

  .
• AWS budget: +$2,400 (+30%) — status

  critical

  .

Required: approve, revise, or reject.

[report text]

Changelog