Create a project plan summary for [PROJECT NAME] using [PROJECT NOTES]. The audience is [AUDIENCE], the reporting date is [REPORTING DATE], and the project target or deadline is [TARGET DATE]. Use these success measures: [SUCCESS CRITERIA]. Do not turn assumptions into commitments. Preserve named owners, dates, dependencies, decisions, and risks exactly as supported by my notes. If an owner, date, scope boundary, or decision is missing, mark it “TBD” rather than guessing. Distinguish completed work from work in progress, planned work, and blocked work. Do not hide schedule risk by listing a milestone as on track without evidence. Produce a scannable summary of 500 to 800 words with these sections: 1. Executive summary: objective, current status, and the one or two matters leaders should know first.
2. Scope and success: included work, explicit exclusions, and measurable success criteria.
3. Milestones: a table with milestone, owner, planned date, current status, dependency, and next action.
4. Workstream updates: one short paragraph per workstream, stating progress, blocker, and immediate next step.
5. Decisions and asks: decision needed, decision owner, deadline, options if supplied, and consequence of delay.
6. Risks and mitigations: likelihood, impact, early warning sign, owner, and mitigation only where supported by notes.
7. Next seven days: ordered actions with owners and due dates.
Use plain language suitable for [AUDIENCE]. Before answering, check that every action has an owner or is marked TBD, and flag conflicts among dates, scope, dependencies, or status claims. Ask up to three clarifying questions only if a required input is missing.Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROJECT NAME] | Enter the project name and a short description if the name alone is unclear. | Customer self-service returns portal |
| [PROJECT NOTES] | Paste meeting notes, project plan excerpts, status reports, decisions, owners, dates, and known risks. | Kickoff notes: Maya owns product; Leo owns engineering; support owns help-center article. Prototype approved Sept. 19. API integration depends on ERP vendor sandbox by Oct. 3. Security review requested, not scheduled. Launch target Nov. 14. Pilot success: 30% of eligible returns completed without agent help and no increase in failed refunds. |
| [AUDIENCE] | Enter the readers, such as the project team, executive sponsor, or cross-functional stakeholders. | VP of Operations, product, engineering, support, and finance |
| [REPORTING DATE] | Enter the date the summary represents. | September 24, 2026 |
| [TARGET DATE] | Enter the planned launch, completion, or decision date. | November 14, 2026 |
| [SUCCESS CRITERIA] | List the measures that define a successful project outcome. | 30% self-service completion for eligible returns, no increase in failed refunds, help-center article published before pilot |
How to use
- Paste raw notes from the latest meeting along with the prior plan so the model can expose changes instead of summarizing only the newest discussion.
- Include the reporting date; “next Friday” and “this week” become ambiguous when a summary is forwarded.
- Check every red or blocked item against a real dependency, named owner, and decision date before sending the summary.
- Send this follow-up: “Create a 150-word executive version for [AUDIENCE] that retains only decisions, schedule risk, and actions requiring their support.”
Variations
Weekly status
Use this for a recurring update that compares the week’s movement with the plan.
Write a weekly project status update for [PROJECT NAME] covering [REPORTING PERIOD], based on [NOTES]. Use sections for overall status, completed this week, next week, milestones changed, blockers, decisions needed, and risks. For each blocker or ask, name an owner and needed-by date, or mark it TBD. Compare dates against [BASELINE PLAN] and state the specific variance rather than saying “delayed.” Keep it under [WORD LIMIT]. Do not invent progress, percentages, owners, or dates. Flag contradictions before drafting.
Project kickoff
Use this before work starts to align scope, roles, and the first milestones.
Turn [INITIATIVE NOTES] into a project kickoff brief for [TEAM]. Include objective, problem being solved, scope in and out, success measures, stakeholders, roles and decision rights, milestones, dependencies, assumptions, risks, communication cadence, and the first two weeks of actions. Assign responsibility only where [INITIATIVE NOTES] names it; otherwise use TBD. State open questions explicitly. End with a short list of decisions required before execution. Ask up to three clarifying questions only if a required input is missing.
Project handoff
Use this when a new owner or team needs enough context to continue safely.
Create a project handoff document for [PROJECT NAME] from [OUTGOING OWNER] to [INCOMING OWNER], using [HANDOFF NOTES]. Include the objective, current state, completed work with links or artifacts supplied, active work, key contacts and roles, upcoming milestones, dependencies, access or operational requirements, unresolved decisions, risks, and the first five actions for the incoming owner. Separate verified facts from assumptions. Do not claim access was transferred unless the notes confirm it. Flag every missing artifact, owner, date, or approval.
Tips
- Use one status vocabulary across the project, such as not started, in progress, blocked, at risk, and complete; vague “ongoing” labels conceal schedule problems.
- A milestone should represent a decision, deliverable, or measurable readiness point, not a calendar period such as “October work.”
- List dependencies with a clear handoff: what is needed, from whom, by when, and what slips if it does not arrive.
- Keep decisions separate from discussion. A summary should say who decides, by when, and what delay costs.
FAQ
How detailed should an executive project summary be?
Usually one page or less. It should foreground objective, status, material risks, decisions, and actions leaders must take, not task-level activity.
What should I do when owners are unknown?
Mark them TBD and make ownership assignment a visible next action. Assigning a plausible person without agreement creates hidden risk.
Can AI summarize conflicting project notes?
Yes, if you ask it to flag conflicts. It should not resolve a disagreement about scope, dates, or status without an authorized decision.