AI prompts for project management are ready-to-use instructions that help project managers plan work, communicate with stakeholders, run retrospectives, and handle the writing load that comes with keeping a team aligned. This page is for team leads and project managers who use ChatGPT, Claude, Copilot, or Gemini and want a folder of tested prompts they can open, adjust, and run without starting from scratch every time.

What is in this pack

This pack contains 20 prompts organized into five categories: project planning, stakeholder communication, risk and issue tracking, meeting facilitation, and status reporting. Each prompt includes a brief note on when to use it and which variable to change first.

The prompts work across all four major AI assistants. None of them require API access or technical setup.

A few things this pack does not solve: it won't replace a project management tool like Jira or Asana, and it won't make a vague brief precise on its own. If your project scope is genuinely unclear, fix that before running any prompt. A well-structured instruction handed to an AI still produces weak output when the underlying information is thin.

The prompts, by category

These prompts are grouped by the phase of work where you'll actually reach for them. Each one is written to run on ChatGPT, Claude, Copilot, or Gemini without modification. Variables sit in [BRACKETS] so you can see exactly what to swap before you send.

One honest caveat: AI is weakest at estimating task durations and resource loads. The scheduling and capacity prompts below will give you a reasonable starting shape, but treat any numbers they produce as a first draft that needs your judgment, not a finished plan.

CategoryPromptsBest phase
Kickoff and scoping4Before work starts
Status reporting4Weekly or sprint cadence
Risk and issues4Ongoing
Stakeholder communication4As needed
Retrospectives2End of sprint or project
Scheduling and capacity3Planning cycles

You can browse prompts organized by role if you want to compare what's available for other functions. The AI prompts for business page covers prompts that cross team boundaries, which is useful if your project involves multiple departments.

Kickoff and scoping

Draft a project brief from a one-line goal

When to use it: At the very start, when a stakeholder hands you a vague objective and expects a structured brief by end of day. What to change first: Replace [GOAL] with the actual sponsor's words, however rough.

Variables: [GOAL], [TEAM SIZE], [DEADLINE], [KEY STAKEHOLDERS]

You are a senior project manager. A stakeholder has given you the following goal: "[GOAL]".

Write a one-page project brief that includes:
1. Objective (one sentence, outcome-focused)
2. Scope: what is included and what is explicitly excluded
3. Key deliverables (bullet list, maximum five items)
4. Success criteria (how we will know this is done and done well)
5. Risks and assumptions (two or three of each)
6. Stakeholders: [KEY STAKEHOLDERS]
7. Target completion date: [DEADLINE]
8. Team size: [TEAM SIZE]

Write in plain language. Avoid jargon. Flag any place where the goal is ambiguous and needs clarification before work begins.

[NEEDS REAL OUTPUT] What to notice: The model will almost always surface at least one ambiguity in the goal. That list is often the most useful part of the output.

Break a project goal into a work breakdown structure

When to use it: After the brief is approved and you need to move to task-level planning. What to change first: Swap [DEPTH] to 2 if the project is short; use 3 for anything over six weeks.

Variables: [PROJECT NAME], [OBJECTIVE], [DEPTH]

Create a work breakdown structure for "[PROJECT NAME]".

Project objective: [OBJECTIVE]

Decompose the work to [DEPTH] levels. Level 1 is the project name. Level 2 is major phases or deliverables. Level 3 (if requested) is individual tasks within each phase.

Format as an indented outline. For each Level 2 item, add a one-sentence description of what done looks like.

Write a RACI matrix for a defined scope

When to use it: When you have named the deliverables and need to assign accountability before kickoff. What to change first: Update [DELIVERABLES LIST] and [TEAM MEMBERS] before anything else.

Variables: [PROJECT NAME], [DELIVERABLES LIST], [TEAM MEMBERS]

Create a RACI matrix for [PROJECT NAME].

Deliverables: [DELIVERABLES LIST]
Team members and roles: [TEAM MEMBERS]

Format as a markdown table. Columns are team members; rows are deliverables. Each cell contains R, A, C, or I. Add a note below the table if any deliverable has no Accountable owner or more than one.

Generate clarifying questions before a discovery call

When to use it: The day before a scoping meeting with a new sponsor or client. What to change first: Paste in whatever brief you already have so the questions are specific, not generic.

Variables: [BRIEF OR CONTEXT], [CALL DURATION], [SPONSOR ROLE]

I have a [CALL DURATION] discovery call with [SPONSOR ROLE] for a new project.

Here is the context I have so far: [BRIEF OR CONTEXT]

Generate ten clarifying questions I should ask. Prioritize questions that would change the scope, timeline, or success criteria if the answer were different. Group them: scope, constraints, success, stakeholders. Flag the three most important ones.

Status reporting

Write a weekly status update from bullet-point notes

When to use it: End of the week, when your notes are scattered and you need a clean update for the sponsor before Monday. What to change first: Paste your raw notes into [NOTES]. Leave them messy; the model handles formatting.

Variables: [PROJECT NAME], [REPORTING PERIOD], [AUDIENCE], [NOTES], [RAG STATUS]

Write a weekly status update for [PROJECT NAME] covering [REPORTING PERIOD].

Audience: [AUDIENCE]
Overall status: [RAG STATUS] (Red / Amber / Green)

My raw notes from this week: [NOTES]

Format:
- Overall status and one-sentence summary
- Accomplishments this week (bullet list)
- Planned for next week (bullet list)
- Issues and risks requiring attention
- Decisions needed from [AUDIENCE]

Tone: direct and factual. Do not soften bad news. If status is Red or Amber, the issue section should lead with the most critical item.

[NEEDS REAL OUTPUT] What to notice: Check whether the model buried a risk in the middle of the issues list. Reorder manually if the most critical item isn't first.

Summarize a long project thread or email chain

When to use it: You've inherited a project mid-stream or missed a week of emails and need to get current fast. What to change first: Paste the full thread into [THREAD]. Truncate attachments; paste body text only.

Variables: [THREAD], [YOUR ROLE]

I am a [YOUR ROLE] who needs to get up to speed on an ongoing project.

Here is the email or message thread: [THREAD]

Summarize:
1. What has been decided (and by whom, if clear)
2. What is still open or unresolved
3. Any commitments made with named owners and due dates
4. What I need to do or respond to

Keep it under 200 words. Use bullet points for items 1 through 4.

Draft a milestone completion announcement

When to use it: A phase or key deliverable just landed and you need to tell stakeholders without it reading like a press release. What to change first: Adjust [TONE] to match your organization, "formal" or "conversational" both work.

Variables: [MILESTONE NAME], [DATE], [WHAT WAS DELIVERED], [NEXT MILESTONE], [TONE], [AUDIENCE]

Write a short announcement (150 words or fewer) that [MILESTONE NAME] was completed on [DATE].

What was delivered: [WHAT DELIVERED]
Next milestone: [NEXT MILESTONE]
Audience: [AUDIENCE]
Tone: [TONE]

Include one sentence on why this milestone matters for the overall project. Do not use superlatives. Do not say "excited" or "thrilled."

Rewrite a status report for a non-technical executive audience

When to use it: Your original update was written for the delivery team and now needs to go to the board or a senior sponsor. What to change first: Paste the original update into [ORIGINAL UPDATE] without editing it first.

Variables: [ORIGINAL UPDATE], [EXECUTIVE NAME OR ROLE], [DECISION NEEDED]

Rewrite the following project status update for [EXECUTIVE NAME OR ROLE].

Original update: [ORIGINAL UPDATE]

Rules:
- Remove all technical terms or explain them in plain language
- Lead with status and impact, not activity
- Keep it under 150 words
- End with one clear ask: [DECISION NEEDED]

[NEEDS REAL OUTPUT] What to notice: Compare the two versions side by side. The rewrite often reveals that the original update buried the actual problem under process detail.

Risk and issues

Generate a risk register from a project brief

When to use it: Early in planning, before the first team meeting, so you walk in with a draft list rather than a blank page. What to change first: Add [INDUSTRY] for better-calibrated risks; a construction project and a software rollout have different failure modes.

Variables: [PROJECT BRIEF], [INDUSTRY], [TEAM SIZE], [TIMELINE]

You are a risk manager. Read the following project brief and generate a risk register.

Project brief: [PROJECT BRIEF]
Industry: [INDUSTRY]
Team size: [TEAM SIZE]
Timeline: [TIMELINE]

Format as a table with columns: Risk ID, Description, Category (schedule / budget / resource / external / technical), Likelihood (H/M/L), Impact (H/M/L), Risk Rating (multiply scores: H=3, M=2, L=1), Mitigation action, Owner (leave blank).

Include at least ten risks. Sort by Risk Rating, highest first.

Write a risk escalation memo

When to use it: A risk has moved from amber to red and you need a written record that you flagged it to the right people. What to change first: Be specific in [RISK DESCRIPTION]; vague escalations get vague responses.

Variables: [RISK DESCRIPTION], [IMPACT IF REALIZED], [DATE IDENTIFIED], [PROPOSED MITIGATION], [DECISION NEEDED FROM], [YOUR NAME AND ROLE]

Write a formal risk escalation memo from [YOUR NAME AND ROLE].

Risk: [RISK DESCRIPTION]
Date identified: [DATE IDENTIFIED]
Potential impact: [IMPACT IF REALIZED]
Proposed mitigation: [PROPOSED MITIGATION]
Decision needed from: [DECISION NEEDED FROM]

Format: short memo, under 200 words. Opening sentence states the risk and asks for a decision. Close with a deadline for the response. Do not soften the severity.

Identify dependencies from a task list

When to use it: You have a task list but no one has mapped which tasks block others. Paste the list in and get a dependency map before you build the schedule. What to change first: Clean up any duplicate or vague task names before pasting; the model will create dependencies for whatever it sees.

Variables: [TASK LIST]

Here is a list of tasks for a project: [TASK LIST]

Identify dependencies between tasks. For each dependency, state:
- Task A (the predecessor)
- Task B (the dependent task)
- Type of dependency: finish-to-start, start-to-start, finish-to-finish, or start-to-finish
- Brief reason (one sentence)

Format as a table. Flag any tasks that have no dependencies (potential parallel work) and any tasks that are on what appears to be a critical path.

Write a post-incident summary for a project issue

When to use it: After something went wrong on a project and you need a written record for the lessons-learned log or a sponsor debrief. What to change first: Replace [WHAT HAPPENED] with a factual description; avoid blame language and the model will mirror your tone.

Variables: [WHAT HAPPENED], [DATE], [IMPACT], [ROOT CAUSE], [RESOLUTION], [PREVENTIVE ACTION]

Write a post-incident summary for a project issue.

Date: [DATE]
What happened: [WHAT HAPPENED]
Impact: [IMPACT]
Root cause: [ROOT CAUSE]
Resolution: [RESOLUTION]
Preventive action for future: [PREVENTIVE ACTION]

Format: plain paragraphs, under 300 words. Factual and neutral. No blame language. End with a clear statement of the preventive action and who owns it.

Stakeholder communication

Write a stakeholder communication plan outline

When to use it: At project kickoff, when you know who your stakeholders are but haven't formalized how you'll keep them informed. What to change first: Update [STAKEHOLDER LIST] with real names and roles; generic outputs are less useful here than in most other prompts.

Variables: [PROJECT NAME], [STAKEHOLDER LIST], [PROJECT DURATION], [CADENCE PREFERENCES]

Create a stakeholder communication plan for [PROJECT NAME].

Stakeholders: [STAKEHOLDER LIST]
Project duration: [PROJECT DURATION]
Any known cadence preferences: [CADENCE PREFERENCES]

Format as a table with columns: Stakeholder, Information needs, Channel (email / meeting / dashboard / report), Frequency, Owner, Notes.

After the table, add a short paragraph on any stakeholder whose needs conflict with each other (for example, one wants weekly detail, another wants monthly summaries).

Draft a difficult message about a delay

When to use it: A milestone is going to slip and you need to tell a sponsor before they find out another way. What to change first: Fill in [REASON] honestly; the model will help you frame it, but it can't invent a reason for you.

Variables: [ORIGINAL DEADLINE], [NEW DEADLINE], [REASON], [MITIGATION STEPS], [SPONSOR NAME OR ROLE]

Draft an email to [SPONSOR NAME OR ROLE] explaining that [ORIGINAL DEADLINE] will not be met.

New expected date: [NEW DEADLINE]
Reason: [REASON]
Steps already taken or planned to mitigate: [MITIGATION STEPS]

Rules:
- Lead with the key fact (the delay) in sentence one
- Acknowledge the impact on the sponsor
- Do not over-apologize or pad the message
- End with a concrete next step and a date
- Under 200 words

[NEEDS REAL OUTPUT] What to notice: The model reliably puts the delay in sentence one. Check whether the reason paragraph sounds defensive; if it does, trim it by half.

Prepare talking points for a steering committee meeting

When to use it: 24 hours before a formal governance meeting where you'll be presenting. What to change first: Add any political sensitivities in [CONTEXT]; the model will adjust the framing if you tell it what tensions exist.

Variables: [PROJECT NAME], [MEETING DATE], [STATUS SUMMARY], [DECISIONS NEEDED], [AUDIENCE], [CONTEXT]

Prepare talking points for a steering committee meeting for [PROJECT NAME] on [MEETING DATE].

Audience: [AUDIENCE]
Current status summary: [STATUS SUMMARY]
Decisions needed from this meeting: [DECISIONS NEEDED]
Context or political sensitivities: [CONTEXT]

Format: five to eight bullet points I can speak to, not read verbatim. Each point should be one or two sentences. End with a slide-by-slide outline if the meeting runs more than 20 minutes.

Summarize stakeholder feedback into action items

When to use it: After a review meeting or feedback round, when you have a messy set of comments and need to turn them into a clean action list. What to change first: Paste in the raw feedback, including contradictions. Don't pre-filter; let the model surface conflicts.

Variables: [RAW FEEDBACK], [PROJECT NAME], [DELIVERY TEAM]

Here is stakeholder feedback collected for [PROJECT NAME]: [RAW FEEDBACK]

Organize this feedback into:
1. Action items with a suggested owner from [DELIVERY TEAM] and a priority (High / Medium / Low)
2. Decisions that need to be made before work can continue
3. Comments that are noted but require no action
4. Contradictory feedback that needs resolution (list the conflicting points side by side)

Format items 1 through 4 as separate sections with bullet lists.

Retrospectives

Facilitate a written retrospective from team responses

When to use it: When the team has submitted retrospective responses asynchronously and you need to synthesize them before the live session. What to change first: Paste in the raw responses as-is, including negative feedback. Sanitizing them before input removes the most useful signal.

Variables: [TEAM RESPONSES], [SPRINT OR PROJECT NAME], [TEAM SIZE]

You are helping a project manager facilitate a retrospective for [SPRINT OR PROJECT NAME].

Team size: [TEAM SIZE]
Raw team responses (what went well, what didn't, what to change): [TEAM

## Real example outputs

Five of the prompts above have captured model outputs linked below. [NEEDS REAL OUTPUT] marks each one. When outputs are added, look for three things.

| Prompt | What to notice |
|---|---|
| Kickoff agenda | Whether the model front-loads the right questions for your project type, not a generic list |
| RAID log | Whether risks are specific and ranked, not vague placeholders |
| Stakeholder update | Whether the tone matches the seniority of the audience you specified |
| Retrospective summary | Whether the model groups themes rather than just listing every comment |
| Scope change impact | Whether trade-offs across time, cost and quality are all surfaced, not just one |

A good output is one you would send with minor edits, not one you have to rewrite from scratch. If you are rewriting more than a third of the response, the prompt needs a tighter constraint, usually a more specific project type or a word-count ceiling.

:::keypoint heading="Worth pausing on"
Model outputs for project management work best when you paste in real context: actual team names, actual deadlines, actual constraints. Generic inputs return generic outputs.
:::

## How to adapt these for your team

The prompts above work as written, but a few small changes make them significantly more useful for a specific team or project type.

**Replace the generic variables first.** Every `[PROJECT NAME]`, `[STAKEHOLDER]`, and `[DEADLINE]` is a placeholder, not a suggestion. Fill those in before you share a prompt with a colleague, otherwise you're handing them busywork.

**Add your methodology.** If your team runs Scrum, add "using two-week sprints and a Scrum framework" to any planning prompt. If you're on a waterfall schedule, say so. The model doesn't know your process unless you tell it.

**Set a standing context line.** One sentence at the top of any prompt, something like "We are a five-person product team at a B2B SaaS company, mid-market focus," cuts down on irrelevant output without requiring a long system prompt.

One honest caveat: the more context you add, the longer the output tends to get. Sometimes a tighter, less personalized prompt produces something more actionable than a heavily customized one. Worth testing both before you settle on a version.

## Save this folder to your workspace

These prompts are worth keeping somewhere your whole team can reach them. A shared folder means a new project coordinator doesn't have to reverse-engineer what the senior PM typed last quarter, and it means the prompts actually improve over time instead of living in someone's browser history.

:::cta heading="Want your team running from the same prompt set?" href="/product/shared-folders" button="Start free"
Convergence shared folders let you store, organize, and update prompts once. Every teammate pulls the current version, across ChatGPT, Claude, Copilot, and Gemini.
:::

A few practical suggestions before you save:

- Rename prompts to match your team's terminology. If you call them "workstreams" not "phases", change the label so there's no translation step at 9am.
- Pin the four or five prompts your team uses every week. The rest can stay in the folder without cluttering the daily view.
- Add a version note when you update a prompt. Even a short "revised after Q3 retro" saves future confusion.

For more prompt sets organized by role, see the [full prompts by role library](/prompts).

## Frequently asked questions

### Do AI prompts for project management work across different AI tools?

Yes. The prompts on this page run without modification on ChatGPT, Claude, Copilot, and Gemini. Each model phrases output slightly differently, but the structure holds. If one tool's response feels thin, paste the same prompt into another and compare.

### Can I use these prompts if my team is new to AI?

Absolutely. The prompts are written for people who manage projects, not people who write code. Start with one category, run a few prompts yourself, then share the outputs with your team before handing off the prompts directly.

### What does AI handle badly in project management?

Judgment calls involving team dynamics, stakeholder politics, and anything that requires reading the room. AI will draft your escalation email, but it cannot tell you whether sending it will damage a relationship. Use it for structure and language, not for decisions.

### How do I keep prompts consistent across my team?

Store them in a [shared Convergence folder](/product/shared-folders) so everyone pulls from the same source rather than rewriting from memory each time.

### Are these prompts suitable for agile teams?

Yes, though the sprint planning and retrospective prompts are the most directly relevant. Waterfall and hybrid teams will get more use from the risk and stakeholder categories.