generate-closure-report

Triggers

Russian: «сформируй отчёт о закрытии», «закрой проект», «подготовь closure report», «отчёт о закрытии проекта» English: "generate closure report", "close project", "project closure report", "prepare closure 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.

1. Input Data

project-charter.md

plan-fact-report.md

risk-register.md

team retrospective

questionnaire

PM input in chat

PM input in chat

If required data is missing — request it (system-prompt-draft.md §3.2):

To generate the project closure report, the following is needed:
1. Project charter (project-charter.md) — in knowledge or paste in chat.
2. Plan-fact report (plan-fact-report.md) — in knowledge or paste in chat.
3. Project lessons — in any format:
   — team retrospective results;
   — questionnaire answers;
   — free-form description: what went well, what went wrong, what to do differently.
Available data: [list what is present].
Missing: [specify].

2. Execution Algorithm

1. Verify input data. Check for minimum: charter, plan-fact report, lessons from user. Missing → request using the template from §1. Do NOT generate a stub report, template, or example — respond ONLY with a data request. Present → step 2.
2. Structure lessons. If data is free-form — categorize into: Processes, Technologies, Communications, Resources, Risks. For each lesson — formulate a recommendation. Count: 1 to 5, only those supported by data. Do not pad artificially.
3. Check data for contradictions. If charter data conflicts with plan-fact report (e.g., different planned dates or budget) — do NOT choose independently. List the discrepancies, ask which data is current. Exception: if the user explicitly corrects in chat — use the correction.
4. Read the template

   closure-report

   from project knowledge. Select the file with the appropriate language suffix based on Language Detection.
5. Fill section 1 (general information): planned data from charter, actual data from plan-fact report (summary).
6. Fill section 2 (project results): list of deliverables from charter (section 2, "Project Result"). Actual status from plan-fact report (scope data) or from user. Split into "Delivered" / "Not delivered / deferred". For each incomplete deliverable — state the reason. If reason not provided — use

   [clarify]

   .
7. Fill section 3 (plan-fact deviations): copy the summary table from plan-fact-report.md (section 1). Data: plan, actual, deviation — without recalculation. Rephrase the "Comment" column in a closing tone (1 sentence per metric). At the bottom — reference: "Details — in

   plan-fact-report.md

   ."
8. Fill section 4 (realized risks):
   • If

     risk-register.md

     is available → extract risks with status "realized" or mentioned in user data. Verify: each risk in section 4 must have an ID from the register.
   • If

     risk-register.md

     is unavailable → use data from user. If user did not specify realized risks — ask: "Which planned risks were realized? If none — I will note 'No realized risks'."
   • If no risks occurred → replace the table with: "No realized risks".
9. Fill section 5 (lessons learned): 1 to 5 lessons, structured in step 2. Category from the reference in §3.
10. Fill section 6 (open items) and section 7 (closure approval):
    • Section 6: if user provided open items → fill in. If not → replace the table with: "All items closed".
    • Section 7: names from charter (Sponsor, PM). Dates — empty.
11. Verify the result against the checklist (section 5 of this spec). Present the result in chat. Format (system-prompt-draft.md §3.4):
    • What was done: "Generated project closure report based on [list sources]".
    • Assumptions: list all (if any).
    • Key outcomes: 1–3 lines — main results (delivered X of Y, budget, timeline).
    • Required: "Approve, provide comments, or reject".
    • Do not show system file paths. Use name only: "Report saved as closure-report.md".
12. Wait for user response (system-prompt-draft.md §3.5).
    • Approval → produce the final text.
    • Comments → revise, show updated version. After the 3rd iteration — ask: "Continue revising or finalize the current version?"
    • After approval:
      • Offer the user text to insert into log.md and project-state.md (system-prompt-draft.md §11).
      • State: "Closure report approved. Project completed." This is the final skill in the MVP chain — no subsequent tasks.

3. Section Fill Rules

Section 1. General Information

• Project goal — from charter (section 1). Copy as-is, do not rephrase.
• Sponsor — from charter (section 5 or header).
• Start and end dates (planned) — from charter (section 3).
• End date (actual) — from plan-fact report (last actual date) or from user. If project closes early — state the actual date with a note.
• Budget (planned) — from charter (section 4). Budget (actual) — from plan-fact report (summary).

Section 2. Project Results

• Delivered: each deliverable from charter (section 2, "Included") that is complete. Format:

  deliverable — brief result description

  .
• Not delivered / deferred: deliverables that are incomplete or deferred. Format:

  deliverable — reason: [explanation]

  . If reason not provided by user —

  [clarify]

  .
• Status source: plan-fact report (scope data) > user data in chat.
• If a deliverable is partially complete — list under "Delivered" with a "partial" note and description of what was excluded.

Section 3. Plan-Fact Deviations

• Direct transfer of the summary table from plan-fact-report.md (section 1, 3 rows: timeline, budget, scope). Do not recalculate data.
• "Comment" column — rephrase from plan-fact report in a closing tone. One sentence per metric. Example: "Delay +1 week due to Safari hotfix" → "Project completed with a +1 week delay; root cause — Safari incident during launch phase".
• If budget was absent in plan-fact report — replace the budget row with "Budget — data unavailable".
• Below the table — in italics: Details — in

  plan-fact-report.md

  .

Section 4. Realized Risks

Conditional section.

• If risks were realized — table with columns: ID, Risk, Project Impact, Response Result.
• ID — from risk-register.md (if available). If register unavailable — leave empty or assign R1, R2, ...
• Project Impact — specific: what happened, what consequences (delay, overrun, scope change).
• Response Result — what was done: did the response plan work, what actions were taken.
• If no risks occurred → replace the table with: "No realized risks".
• Do not include risks that were in the register but did not materialize.

Section 5. Lessons Learned

• 1 to 5 lessons. Count is determined by user data — do not pad artificially.
• Columns: #, Lesson, Category, Recommendation.
• Category — from reference:

  Processes

  /

  Technologies

  /

  Communications

  /

  Resources

  /

  Risks

  .
• Lesson — a fact or observation. Wording: what happened and why it matters.
• Recommendation — a concrete action for future projects. Not an abstraction.
• If user provided lessons without categories — agent assigns based on content.

Section 6. Open Items and Handover

Conditional section.

• If open items exist — table: #, Item/Task, Owner, Deadline.
• Owner — from user data. If not specified —

  [clarify]

  .
• Deadline — specific date (YYYY-MM-DD). If not specified —

  [clarify]

  .
• If no open items → replace the table with: "All items closed".

Section 7. Closure Approval

• Sponsor and PM — from charter (section 5). Date — empty (filled upon approval).

Header Metadata

• Version

  : 1.0

• Date

  : current generation date.

• File

  :

  closure-report.md

• Document status

  :

  draft

  (on generation). After approval —

  approved

  .

• Project manager

  : from charter.

• Lessons source

  : from input data. Default:

  PM input in chat

  .

4. Placeholder Table

Placeholders

{{}}

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

{{project_name}}

{{date}}

{{pm_name}}

{{lessons_source}}

PM input in chat

team retrospective

questionnaire

PM input in chat

{{project_goal}}

{{sponsor_name}}

{{planned_start}}

{{planned_end}}

{{actual_end}}

{{planned_budget}}

{{actual_budget}}

{{deliverable_N}}

{{status_N}}

{{excluded_N}}

{{reason_N}}

[clarify]

{{planned_duration}}

{{actual_duration}}

{{delta_time}}

{{comment_time}}

{{delta_budget}}

{{comment_budget}}

{{planned_scope}}

{{actual_scope}}

{{delta_scope}}

{{comment_scope}}

{{risk_id}}

{{risk_description}}

{{impact}}

{{response_result}}

{{lesson_N}}

{{category_N}}

Processes

Technologies

Communications

Resources

Risks

{{recommendation_N}}

{{open_item_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 remain in text (except removed optional rows)
• Section 1: planned data matches charter, actual data matches plan-fact report
• Section 2: all deliverables from charter listed (delivered + undelivered)
• Section 2: each undelivered deliverable has a reason (or

  [clarify]

  )
• Section 3: data matches plan-fact report summary (no recalculation)
• Section 3: reference to

  plan-fact-report.md

  present
• Section 4: if conditional — correctly filled or replaced with "No realized risks"
• Section 5: 1 to 5 lessons, each with category and recommendation
• Section 6: if conditional — correctly filled or replaced with "All items closed"
• All agent assumptions listed when presenting result
• Document status =

  draft

• File:

  closure-report.md

  stated in header

6. Dependencies

Consumes (input):

• project-charter.md

  — from skill

  generate-charter

  (goal, deliverables, team, budget, timeline)

• plan-fact-report.md

  — from skill

  generate-plan-fact-report

  (deviation summary, actual data)

• risk-register.md

  — from skill

  generate-risk-register

  (optional, for realized risks)
• Lessons and open items — from user (via chat)

Produces (output): project closure report — the final artifact. Not consumed by other MVP skills.

In Product 1: additionally consumes data from

generate-questionnaire

After report approval, user should upload

closure-report.md

7. Example Invocation

User command:

Generate the project closure report. Charter and plan-fact report are in knowledge. Risk register too. Lessons: — Underestimated DB filter complexity, lost a week. Need to budget buffer for unknown tasks. — Formalized change request saved us from scope creep — CEO wanted to add Intercom, but impact assessment stopped it. — Safari testing was done only before release — needs to happen earlier. Open items: — Email integration assigned to Dmitry, deadline July 31. — Pricing — on me, by August 1.

Agent response (after generation):

Generated project closure report for "ClientBoard" based on: charter, plan-fact report, risk register, lessons from chat.

Assumptions:

• Lessons source: PM input in chat.
• Realized risks identified based on risk-register.md and PM data.

Key outcomes:

• Delivered 4 of 5 deliverables (email integration deferred).
• Budget: $76,400 of $80,000 (4.5% savings).
• Timeline: +1 week (13 instead of 12).

Required: approve, provide comments, or reject.

[report text]

Changelog