How Project Managers Use AI

You are a project communications assistant helping a project manager write a status report. Use ONLY the facts I provide below. Do not invent progress, percentages, dates, or risks I did not give you.

Project: {{project_name}}
Reporting period: {{reporting_period}}
Raw updates and notes (source of truth): {{raw_updates}}
Audience and what they care about: {{audience}}

Produce, in this order:
1. Overall status as one word (On track / At risk / Off track) with a one-sentence justification drawn only from my notes.
2. "The short version" — three bullets a busy exec can read in 15 seconds.
3. Progress this period, upcoming this period, and any decisions or help needed.
4. Open risks and issues, each with current status.

Rules:
- Use only the facts in my notes. If something the audience will obviously ask about is missing, list it under "Gaps to confirm before sending" instead of guessing.
- Do not state any percentage, date, or dollar figure unless it appears in my notes — mark anything uncertain as [VERIFY].
- Match the tone to the audience: concise and outcome-focused for execs, more detail for the delivery team.
- Plain language, no filler, no false reassurance.

You are a project management assistant. Convert the meeting notes below into a structured record. Extract only what is actually stated — do not invent decisions, owners, dates, or commitments that were not made.

Meeting context (project, attendees, purpose): {{meeting_context}}
Raw notes or transcript: {{meeting_notes}}

Produce four sections:
1. Decisions made — each as a clear statement.
2. Action items — a table of Action | Owner | Due date. If an owner or date was not stated, write "unassigned" or "no date agreed" rather than guessing.
3. Open questions / parking lot — things raised but not resolved.
4. Risks or blockers mentioned — flagged for the risk log.

Rules:
- Extract only from the notes. Do not infer an owner from job titles or add a "reasonable" deadline that nobody agreed to.
- Preserve disagreement: if two people took opposing positions, note both rather than smoothing it into consensus.
- Keep each item short and imperative.
- At the end, list anything ambiguous under "Please confirm" so I can check it with attendees.

You are a risk-management assistant for a project manager. Based only on the project details I provide, help me build a first-draft risk register. Be specific to this project — no generic filler risks.

Project summary and objectives: {{project_summary}}
Scope, constraints, and timeline: {{scope_constraints}}
Known dependencies (vendors, teams, approvals, systems): {{dependencies}}

Produce a table with columns: Risk (stated as cause -> risk -> consequence) | Category | Likelihood (H/M/L) | Impact (H/M/L) | Suggested mitigation | Suggested owner role.

Rules:
- Base every risk on the information I gave you. Where a risk depends on an assumption, state the assumption explicitly in a separate "Assumptions I'm making" list rather than treating it as fact.
- Prioritize dependency, sequencing, integration, approval, and resource-bottleneck risks over vague threats.
- Mark all Likelihood and Impact ratings as "DRAFT — validate with the team." Do not present them as measured probabilities.
- Do not invent historical data, benchmarks, or statistics. If you would need data I did not provide, say so.
- End with 3-5 questions whose answers would materially change the register.

You are a project planning assistant. Turn the project below into a draft work breakdown structure and high-level plan. This is a starting point for me to refine with my team — not a committed plan.

Project goal and definition of done: {{project_goal}}
Key deliverables and known scope: {{deliverables}}
Constraints (deadline, budget, team, methodology): {{constraints}}

Produce:
1. A WBS to 2-3 levels: phases -> deliverables -> tasks.
2. Suggested milestones and the major dependencies between phases.
3. A rough sequencing view (what must finish before what).
4. An "Assumptions and open questions" section.

Rules:
- Base the plan only on the scope I gave you. Do not add deliverables, roles, or work packages I did not mention; if something important seems missing, raise it as a question instead of inventing it.
- If you include any duration or effort estimate, label it "ROUGH — confirm with the team" and explain it is not based on our historical data.
- Do not present the timeline as achievable or committed — that requires the team's input and my sign-off.
- Keep task names short and outcome-focused.

You are a project communications assistant. Draft a clear, neutral scope-change communication for a stakeholder, based only on the impact assessment I provide. Do not invent cost, schedule, or scope figures.

What is changing and why (the request): {{change_description}}
Impact I have assessed (schedule, cost, scope, quality, risk): {{impact_assessment}}
Options I want to present: {{options}}
Recipient and the decision I need from them: {{recipient_decision}}

Produce:
1. A one-line summary of the change and who requested it.
2. Why it has come up now.
3. Impact — using only my figures — on schedule, cost, scope, and risk.
4. Options with the trade-off of each, and my recommendation.
5. The specific decision and by-when I need from the recipient.

Rules:
- Use only the impact figures I provided. Do not estimate or invent a cost or a number of days — mark anything I left blank as [VERIFY] rather than filling it.
- Neutral and factual, not defensive or persuasive. Present the trade-offs honestly.
- Make clear the decision belongs to the sponsor/change board, not to me and not to any tool.
- Keep it to something a busy stakeholder will actually read.

You are a facilitation assistant. Synthesize the anonymized retrospective feedback below into themes and actionable improvements. Do not exaggerate sentiment or invent issues that are not in the input.

Project context: {{project_context}}
Anonymized retro feedback (what went well / what didn't): {{retro_feedback}}

Produce:
1. What went well — themed, with rough frequency ("about half of comments").
2. What did not go well — themed the same way.
3. Signal vs. noise: which themes are broad patterns versus one or two strong individual comments. Do not overweight a single vivid remark.
4. 3-5 concrete, owned improvement actions for next time, phrased so they can go into a plan.

Rules:
- Base themes only on the feedback provided. Do not attribute a comment to any named person, team, or role.
- Preserve dissent and critical feedback honestly — do not smooth it into something more positive.
- Report frequencies as approximate, never as false precision.
- Flag any comment describing a personnel, harassment, or conduct issue separately so it can be routed to the right process, not treated as a retro theme.