PM Prompt Library · 12 prompts

Claude prompts for project management.

PMs spend hours on status updates, risk documentation, stakeholder comms, and meeting prep, work that is structured and repeatable. These 12 prompts cut that production time so you can focus on the coordination and decision-making that only you can do.

Before you run these: Use Claude Team or Enterprise when your prompts contain real project data, since those plans do not use your conversations for model training. For highly sensitive information, replace stakeholder names with role tokens and replace exact financials with ranges. Always review Claude's output before it goes to any stakeholder. These prompts produce strong drafts, not final deliverables.

PROJECT KICKOFF AND PLANNING

Kickoff and planning prompts

Project charter draft

Use when: a new project is approved and you need a one-page charter to get sponsor sign-off and alignment

You are a project manager at [COMPANY].

Project name: [NAME]
Sponsor: [NAME, TITLE]
Business objective: [WHAT PROBLEM THIS SOLVES OR OPPORTUNITY THIS CAPTURES]
Scope (what is in): [BULLET POINTS]
Scope (what is out of scope): [BULLET POINTS]
Key stakeholders: [NAMES, ROLES]
Target completion: [DATE]
Budget range: [AMOUNT]
Known risks: [BULLET POINTS]

Draft a one-page project charter:
1. Executive summary (2-3 sentences: the business case)
2. Objectives and success criteria (3-5 SMART goals)
3. Scope and exclusions
4. Key milestones and target dates
5. Stakeholders and their roles (RACI sketch)
6. Risks and initial mitigations
7. Budget overview

Tone: direct and professional. This goes to the sponsor for approval.

Work breakdown structure

Use when: the charter is approved and you need to break the project into actionable tasks with owners and estimates

I am managing a project to [PROJECT GOAL].

High-level deliverables:
[LIST THE MAJOR DELIVERABLES]

Constraints:
- Timeline: [X weeks/months]
- Team: [TEAM SIZE AND ROLES]
- Dependencies: [KEY DEPENDENCIES]

Build a work breakdown structure (WBS):
1. Break each deliverable into tasks and subtasks
2. For each task: estimated effort (hours or days), owner role, dependencies, and risk level (Low/Medium/High)
3. Identify the critical path
4. Flag any tasks where the estimate is uncertain and explain why

Return as a structured list, not a paragraph.

Risk log for a new project

Use when: you are building a risk register at the start of a project and want to catch what you have not thought of yet

I am managing [PROJECT NAME], a [BRIEF DESCRIPTION] project.

Known risks I have identified:
[PASTE YOUR LIST]

Project context:
- Team: [SIZE, KEY ROLES]
- Timeline: [DURATION]
- Stakeholders: [KEY STAKEHOLDERS]
- Constraints: [BUDGET, TECH, REGULATORY, ETC]

For each known risk, and any additional risks you identify:
1. Risk description (one sentence)
2. Category (schedule / budget / resource / technical / stakeholder / external)
3. Likelihood (Low / Medium / High)
4. Impact if it materializes (Low / Medium / High)
5. Risk score (Likelihood x Impact)
6. Mitigation actions (2-3 specific steps)
7. Owner (role)

Add 3-5 risks I may not have listed based on the project type and context.
Format as a table.

STATUS AND COMMUNICATION

Status reports and stakeholder comms

Weekly status report

Use when: it is end of week and you need a clean status update from your raw notes

I am the PM on [PROJECT NAME].

Week ending: [DATE]
Status (overall): [Green / Yellow / Red]

Accomplishments this week:
[PASTE RAW NOTES OR BULLET POINTS]

Planned for next week:
[PASTE RAW NOTES OR BULLET POINTS]

Issues and blockers:
[PASTE]

Key decisions needed:
[PASTE]

Schedule: [On track / X days ahead / X days behind]
Budget: [On budget / X% over / under]

Write a clean weekly status report for stakeholders:
1. One-paragraph executive summary (status, main accomplishment, top risk this week)
2. Accomplishments (bullet points, specific and measurable where possible)
3. Next week plan (bullet points)
4. Issues and blockers (each with owner and target resolution date)
5. Decisions needed (each with deadline and decision-maker)

Tone: direct and factual. Eliminate filler phrases like "the team worked hard" or "we made great progress." Report what happened.

Escalation memo to senior stakeholder

Use when: an issue is beyond your authority to resolve and you need to put it to a senior stakeholder clearly and without alarm

I need to escalate [ISSUE DESCRIPTION] on [PROJECT NAME].

Background:
[1-2 sentences on project context]

What happened:
[DESCRIBE THE ISSUE: when it surfaced, what caused it, what the impact is]

What we have tried:
[LIST ACTIONS TAKEN SO FAR]

What I need from you:
[SPECIFIC ASK: a decision, a resource, an intervention]

Timeline: [DATE BY WHICH A DECISION IS NEEDED]

Write a concise escalation memo (max one page):
1. Issue in one sentence
2. Impact on scope, schedule, or budget
3. What we have done to resolve it
4. The decision or action I need, with the date required
5. Recommended path forward

Tone: professional, not alarming. Respect the reader's time. Avoid jargon.

Steering committee or executive update

Use when: you are preparing a steering committee packet and need to give executives the signal without the noise

I am preparing a steering committee update for [PROJECT NAME].

Project phase: [PHASE NAME]
Overall status: [Green / Yellow / Red]

Decisions made since last update:
[PASTE]

Milestones hit this period:
[PASTE]

Upcoming milestones and dates:
[PASTE]

Risks and issues requiring committee awareness:
[PASTE]

Budget status: [SUMMARY]

Items requiring committee decision or approval:
[PASTE]

Draft a steering committee update presentation structure (5-7 slides):
1. Slide title and headline message for each slide
2. 3-5 bullet points per slide (what the committee needs to know, not operational detail)
3. For the decision slide: the options, the recommendation, and what you need from them

Audience: senior executives who are not in the project day to day. Lead with status and the ask, not process detail.

TEAM AND DELIVERY

Meeting, retro, and scope prompts

Meeting agenda and follow-up notes

Use when: you need to prep an agenda before a meeting, or clean up notes and action items after one

Meeting type: [e.g., project kickoff / sprint review / lessons learned / design review]
Date: [DATE]
Attendees: [LIST ROLES OR NAMES]
Duration: [LENGTH]

Meeting objective (what we need to accomplish):
[DESCRIBE THE GOAL]

Topics to cover:
[LIST THE TOPICS]

For kickoff or planning meetings, also provide:
- Pre-read materials attendees should review
- Decision questions that need resolution in the meeting

If these are raw notes from a meeting that just ended:
[PASTE YOUR RAW NOTES HERE]

If post-meeting: format the notes as:
1. Decisions made (each with owner and date)
2. Action items (each: task, owner, due date)
3. Key discussion points summary (3-5 bullets)
4. Parking lot items (things raised but not resolved)

If pre-meeting: build a timed agenda.

Sprint or project retrospective

Use when: you are facilitating a retro and want a guide that surfaces honest feedback and generates real action items

I am facilitating a [sprint / phase / project-end] retrospective for [PROJECT OR TEAM NAME].

Context:
- Team size: [NUMBER] people
- What we delivered: [BRIEF DESCRIPTION]
- Duration of period: [X weeks/months]

Known tensions or issues I want the retro to surface:
[DESCRIBE ANYTHING: delivery pressure, process friction, communication gaps, team dynamics]

Things that went well that I want the team to recognize:
[DESCRIBE]

Build a retrospective facilitation guide:
1. Framing statement to open the session (set the tone: honest, forward-looking, blameless)
2. Four reflection questions (What went well? What did not? What was puzzling or unclear? What do we want to do differently?)
3. For each: 3 specific follow-up probes to draw out honest answers
4. Prioritization exercise to select 2-3 action items the team will actually commit to
5. Closing: how to wrap up and ensure actions are owned

Tone: psychologically safe. Frame everything around the system and the work, not the people.

Scope change request analysis

Use when: a stakeholder wants to add something and you need a clean one-pager to take to the sponsor for a decision

I am evaluating a scope change request on [PROJECT NAME].

Change requested: [DESCRIBE WHAT IS BEING ADDED OR CHANGED]
Requested by: [STAKEHOLDER NAME / ROLE]
Stated reason: [WHY THEY WANT IT]

Current project baseline:
- Schedule: [CURRENT END DATE]
- Budget: [CURRENT APPROVED BUDGET]
- In-scope features / deliverables: [BRIEF LIST]

Analyze this scope change request:
1. Description: what exactly is being added or changed
2. Impact on schedule (best case / expected / worst case)
3. Impact on budget (estimate or range)
4. Impact on other in-flight work (dependencies, resource conflicts)
5. Risk if we add this now vs. after go-live
6. Recommendation: approve now / defer to next phase / decline, with reasoning
7. What I need from the sponsor to proceed

Format as a one-page change request document I can share with the sponsor.

REPORTING AND CLOSURE

Health reports, lessons learned, and launch

Project health narrative for a dashboard or report

Use when: you need to write the narrative section of a project health report that goes above a metrics dashboard

I am writing the narrative section of a [WEEKLY / MONTHLY / PHASE-END] project health report.

Project: [NAME]
Period: [DATE RANGE]

Metrics this period:
- Schedule variance: [ON TRACK / X DAYS AHEAD OR BEHIND]
- Budget: [AMOUNT SPENT] of [TOTAL BUDGET] ([PERCENTAGE]%)
- Milestones hit: [NUMBER] of [NUMBER PLANNED]
- Open risks: [NUMBER], [NUMBER] elevated this period
- Open issues: [NUMBER], [NUMBER] resolved this period

Key events this period:
[PASTE RAW NOTES]

Write the narrative section of the health report (300-400 words):
1. Overall status summary (one paragraph: where we are, what happened)
2. Schedule and budget call-out (honest read, do not soften bad news)
3. Risk and issue summary (what is being watched and why)
4. Next period focus (2-3 priorities)

Write for an audience that reads dozens of these reports. Lead with the signal, not the noise.

Lessons learned after project close

Use when: the project is closed and you need a structured document that future PMs will actually use

I am writing the lessons learned document for [PROJECT NAME], which [DELIVERED / ENDED] on [DATE].

Project outcome summary:
[BRIEF: what we set out to do, what we actually delivered, final status vs. baseline]

What went well (your notes):
[PASTE]

What did not go well (your notes):
[PASTE]

Surprises (things you did not anticipate):
[PASTE]

Write a structured lessons learned document:
1. Executive summary (2 paragraphs: what the project delivered and the top 3 lessons)
2. What worked well (5-7 items, each with a specific example and a recommendation for future projects)
3. What to do differently (5-7 items, each with root cause and a concrete recommendation)
4. Process improvements recommended (3-5 specific changes to templates, tools, or practices)
5. Things to watch for on similar projects (2-3 early warning signals)

Write with specificity. "Communication could be better" is not a lesson. "Escalation of scope changes took 12 days on average because approval authority was unclear at the start" is a lesson.

Post-launch or post-go-live summary

Use when: you just went live and need to communicate clearly to stakeholders what happened, what is working, and what is not

We just launched [PRODUCT / SYSTEM / INITIATIVE NAME] on [DATE].

What we launched:
[DESCRIBE WHAT WENT LIVE]

Launch day notes:
[PASTE: what happened, any issues, what was resolved]

First 48-72 hours:
- Issues raised: [NUMBER AND DESCRIPTION]
- Issues resolved: [NUMBER]
- User or stakeholder feedback received: [PASTE]
- Key metrics if available: [PASTE]

What is still outstanding:
[PASTE]

Write a post-launch summary for stakeholders:
1. Launch headline (2-3 sentences: what went live, how it went)
2. What is working as expected
3. Issues raised and their resolution status (table format: issue / severity / status / owner)
4. Outstanding items with owners and target resolution dates
5. Next check-in date and what we will report then

Tone: confident and factual. Address issues directly without minimizing them.

FAQ

Frequently asked questions

Can Claude handle confidential project data?

Treat any project data the same way you would a shared document. Remove or anonymize anything covered by an NDA or that identifies individuals, finances, or decisions not yet communicated. Replace client or stakeholder names with role tokens (Sponsor, Head of Engineering) when the name itself is not what you are reasoning about. On Claude Team or Enterprise your conversations are not used for model training, which raises the floor, but anonymizing is still the correct discipline regardless of plan.

How do I stop Claude from inventing deadlines or estimates?

You supply the numbers. Claude drafts the structure around what you give it. If you ask Claude to estimate without grounding it in your actual project data, you will get generic placeholders, not real estimates. Treat every draft as a starting point: verify every date, number, and name before the output goes to a stakeholder. A useful habit is to include a note like "use only the data I have provided; flag anything you cannot support from my inputs."

Should I use a Claude Project for PM work?

Yes. A Claude Project lets you load reusable context: your project charter, status template, risk log format, and stakeholder list. Every prompt you run from inside that Project inherits that context rather than starting blank. The practical result is that status updates and escalations require less setup per session and produce more consistent output across a long-running project.

Which Claude model works best for PM prompts?

The current Sonnet model handles the full range of PM work: status updates, risk analysis, meeting notes, and escalation memos. Reach for Opus when you need deep synthesis across a large document set, such as synthesizing a full project archive for a lessons learned review. Haiku is useful for quick, narrow tasks like rewriting a single bullet point.

Can these prompts replace a PM?

No. Claude handles the production layer: first drafts, structure, and synthesis scaffolding. The judgment that makes PM work valuable, reading stakeholder dynamics, making trade-off calls, navigating conflict, knowing which risk actually matters this week, is yours. The leverage is real because it collapses blank-page time and lets you spend your hours on the thinking that differentiates good PMs from average ones.

How do I use these prompts in a real project?

Pick one prompt per meeting, deliverable, or document type and run it from a Claude Project loaded with your current project context. After the first two or three sessions you will know which three or four prompts you reach for every week. Those become your standard kit. The others are available when you hit that deliverable type for the first time.