Project Manager

Start here

Widely used and core to this role

• Microsoft 365 Copilot(opens in new tab)

  · AI chat assistant

  Summarising Teams meetings, including who spoke and what they said, with suggested action items. With a Copilot license, Planner Agent generates status reports from a plan's current state of work.^[5][8]

• ChatGPT(opens in new tab)

  · AI chat assistant

  General AI assistant for drafting and summarising project documents and analysing files and data.

Also worth a look

Depends on your team and stack

Written from the changes above. Read and adapt one before you use it.

• Weekly status reportDrafts a weekly project status report, checks it against the data and flags doubtsweekly-status-reportView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named weekly-status-report. When to use it: Drafts a weekly project status report from plan, tracker and meeting notes, checks it against the underlying data, and flags low-confidence items and escalation decisions for the project manager. Use when preparing a weekly or fortnightly status update, a steering group summary or a sponsor report, or when asked to "write the status report", "summarise project progress" or "check this AI-generated status update".

  ---
  name: weekly-status-report
  description: Drafts a weekly project status report from plan, tracker and meeting notes, checks it against the underlying data, and flags low-confidence items and escalation decisions for the project manager. Use when preparing a weekly or fortnightly status update, a steering group summary or a sponsor report, or when asked to "write the status report", "summarise project progress" or "check this AI-generated status update".
  metadata:
    title: "Weekly status report"
    summary: "Drafts a weekly project status report, checks it against the data and flags doubts"
  ---
  
  # Weekly Status Report
  
  Draft a status report that reflects the real state of the project, and make clear which parts need the project manager's judgement.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The reporting period and the audience (team, sponsor, steering group), plus any required template.
  - The plan or schedule: milestones, baseline dates and current forecast dates.
  - A tracker export or list of work items with status, owner, due date and last updated date.
  - Notes, decisions and action items from this period's meetings.
  - The current risk and issue log.
  - Last period's report, so changes can be shown.
  - Budget or resource figures (planned and actual spend), if the report covers them.
  - The status scale your organisation uses (for example On track / At risk / Off track, or Red / Amber / Green).
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. Check data freshness first. List work items not updated during the reporting period, items with no owner, and milestones with no forecast date. Report these before drafting.
  2. Compare each milestone's forecast with its baseline and with last period's report. Note what moved and by how much.
  3. Group completed work, work in progress and upcoming work by milestone or workstream.
  4. Pull decisions made and decisions still needed from the meeting notes. Link each to the meeting it came from.
  5. Pull new, changed and closed risks and issues from the log. If no risk log is provided, propose risks drawn from the inputs and label each one "Proposed".
  6. Check budget only if figures were given. If there is no planned spend to compare against, say that budget status can't be judged.
  7. Propose an overall status and a status per milestone, with one sentence of evidence each. Use On track / At risk / Off track; if the organisation uses RAG colours, map them to Green / Amber / Red and state which scale the report uses.
  8. Give a confidence level (High, Medium, Low) for the overall status, each milestone and each progress bullet. Use "Low" where the source data is stale, contradictory, missing, or where the status depends on context not in the data.
  9. List candidate escalations: items that may need sponsor or steering attention. Do not decide; describe the trigger and the options.
  10. Tailor length and wording to the audience. Keep the executive summary to a few sentences.
  11. Produce the draft. Do not send it, post it or update any tracker item.
  
  ## Output format
  
  ```markdown
  # Status report: <project> — <period>
  
  **Draft prepared for review by:** <project manager>
  **Status scale used:** On track / At risk / Off track | Green / Amber / Red
  **Proposed overall status:** <status> (confidence: High/Medium/Low)
  
  Confidence levels apply to the overall status, each milestone and each progress bullet.
  
  ## Executive summary
  
  <3–5 sentences>
  
  ## Milestones
  
  | Milestone | Baseline | Forecast | Change since last report | Status | Confidence |
  | --------- | -------- | -------- | ------------------------ | ------ | ---------- |
  
  ## Progress this period
  
  - <workstream>: <completed> / <in progress> (confidence: High/Medium/Low)
  
  ## Budget
  
  - <planned vs actual, or "Budget status can't be judged: no planned spend provided">
  
  ## Next period
  
  - <planned work>
  
  ## Decisions
  
  | Decision | Made or needed | By whom | Source |
  | -------- | -------------- | ------- | ------ |
  
  ## Risks and issues
  
  | Item | New/changed/closed/Proposed | Owner | Summary |
  | ---- | --------------------------- | ----- | ------- |
  
  ## For the project manager to decide
  
  - **Possible escalations:** <item — trigger — options>
  - **Low-confidence items to check:** <item — why confidence is low>
  - **Data quality problems found:** <stale or ownerless items>
  
  ## Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - The report can only be as accurate as the plan and tracker. A task marked "on track" that has not been updated in weeks is unknown, not on track.
  - Summaries of complex work can miss context that was never written down. Flag anything that looks inconsistent rather than smoothing it over.
  - "Blocked" may mean blocked, or may mean nobody updated the item. Say which you can confirm.
  - Do not guess the reason for a slip. State the fact and leave the explanation to the owner.
  - Deciding which risks to escalate, and how to frame them, stays with the project manager.
  - Leave out personal or confidential details that are not needed for the audience.
  - Never reproduce secrets, credentials or personal data in the output unless the user needs them.
  
  ## Before you finish
  
  - [ ] Stale and ownerless items are listed, not hidden.
  - [ ] Every status has evidence and a confidence level.
  - [ ] Milestone changes are compared with the baseline and last report.
  - [ ] Escalations are presented as options, not decisions.
  - [ ] Nothing was sent, posted or changed in any tool.
  - [ ] Clearly flag every assumption, low-confidence item and escalation decision that the project manager must review or decide.
  

• RAID log triageChecks new risks and issues before they enter the log; a person decides what to escalateraid-log-triageView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named raid-log-triage. When to use it: Reviews AI-flagged or newly raised risks, assumptions, issues and dependencies before they enter the RAID log, removing duplicates, checking evidence, suggesting owners and ratings, and listing escalation options for a human to decide. Use when triaging risk flags from a tool or agent, preparing a risk review meeting, cleaning up a RAID log, or when asked to "review these risks", "update the risk register" or "which risks should we escalate".

  ---
  name: raid-log-triage
  description: Reviews AI-flagged or newly raised risks, assumptions, issues and dependencies before they enter the RAID log, removing duplicates, checking evidence, suggesting owners and ratings, and listing escalation options for a human to decide. Use when triaging risk flags from a tool or agent, preparing a risk review meeting, cleaning up a RAID log, or when asked to "review these risks", "update the risk register" or "which risks should we escalate".
  metadata:
    title: "RAID log triage"
    summary: "Checks new risks and issues before they enter the log; a person decides what to escalate"
  ---
  
  # RAID Log Triage
  
  Turn a pile of raw risk flags into a clean, evidence-based set of proposed RAID log entries, with escalation choices left to the project manager.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The new flags or items to triage, and where each came from (tool alert, meeting, team member).
  - The current RAID log, including owners, ratings and last review dates.
  - The project's rating scale for likelihood and impact, and its escalation thresholds, if defined.
  - The current plan with milestones and dependencies.
  - Recent tracker data for the work items the flags mention.
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. List each incoming flag with its source and the evidence it cites.
  2. Check each flag against the tracker and plan. Mark it as confirmed, not confirmed (for example, the item is stale but work is happening) or unclear.
  3. Match flags against the existing log. Mark duplicates and flags that should update an existing entry instead of creating a new one.
  4. Classify each remaining item as a risk (might happen), issue (is happening), assumption or dependency.
  5. Rewrite each entry in a clear form: cause, event, effect. Keep it short and factual.
  6. Suggest likelihood and impact using the project's scale, with a one-line reason. Mark these as suggestions.
  7. Suggest an owner based on the work affected. Mark it as a suggestion to confirm with that person.
  8. Suggest a response (avoid, reduce, transfer, accept, or monitor) and one next action for each.
  9. Review existing log entries: flag ones not reviewed recently, ones whose trigger dates have passed, and ones that look closed.
  10. List items that may meet escalation thresholds, with the trigger and options. Do not update the live log or notify anyone.
  
  ## Output format
  
  ```markdown
  ## RAID triage: <project> — <date>
  
  ### Incoming flags
  
  | #   | Source | Flag | Evidence checked | Result (Confirmed / Not confirmed / Unclear / Duplicate) |
  | --- | ------ | ---- | ---------------- | -------------------------------------------------------- |
  
  ### Proposed new or updated entries
  
  | Type | Description (cause → event → effect) | Suggested likelihood | Suggested impact | Suggested owner | Suggested response and next action |
  | ---- | ------------------------------------ | -------------------- | ---------------- | --------------- | ---------------------------------- |
  
  ### Existing entries needing attention
  
  | Entry | Problem (stale / trigger passed / possibly closed) | Suggested action |
  | ----- | -------------------------------------------------- | ---------------- |
  
  ### Escalation candidates for the project manager
  
  | Item | Why it may need escalation | Options | Who might need to know |
  | ---- | -------------------------- | ------- | ---------------------- |
  
  ### Assumptions and open questions
  
  - <assumption, gap or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - Automated flags such as "stale work" or "slipping deadline" are signals, not conclusions. The work may be progressing outside the tracker.
  - Tools can spot trends, but deciding which risks to escalate and how to approach them needs knowledge of the people and politics involved. Leave that to the project manager.
  - Do not assign blame in risk descriptions. Describe the situation, not a person's failings.
  - A long list of low-value risks hides the important ones. Recommend merging or dropping noise.
  - Ratings are only comparable if everyone uses the same scale. Say if no scale exists.
  - Keep confidential commercial or personnel details out of the log draft.
  - Never reproduce secrets, credentials or personal data in the output unless the user needs them.
  
  ## Before you finish
  
  - [ ] Every incoming flag was checked against the tracker or plan, or marked unclear.
  - [ ] Duplicates are merged into existing entries.
  - [ ] Ratings and owners are marked as suggestions.
  - [ ] Escalation candidates list options, not decisions.
  - [ ] The live log was not changed and nobody was notified.
  - [ ] Clearly flag every assumption, and anything the project manager must review or decide, especially escalations and owner assignments.
  

• Meeting actions follow-upTurns meeting notes into decisions, action items and a draft follow-up messagemeeting-actions-followupView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named meeting-actions-followup. When to use it: Turns meeting notes or a transcript into a checked list of decisions, action items and proposed tracker updates, plus a draft follow-up message, marking anything unclear for the organiser to confirm. Use after a project meeting, steering group or stand-up, when reviewing AI-suggested action items or tracker updates, or when asked to "write up the actions", "draft meeting minutes" or "what did we agree in this meeting".

  ---
  name: meeting-actions-followup
  description: Turns meeting notes or a transcript into a checked list of decisions, action items and proposed tracker updates, plus a draft follow-up message, marking anything unclear for the organiser to confirm. Use after a project meeting, steering group or stand-up, when reviewing AI-suggested action items or tracker updates, or when asked to "write up the actions", "draft meeting minutes" or "what did we agree in this meeting".
  metadata:
    title: "Meeting actions follow-up"
    summary: "Turns meeting notes into decisions, action items and a draft follow-up message"
  ---
  
  # Meeting Actions Follow-up
  
  Produce an accurate record of what a meeting decided and who agreed to do what, ready for the organiser to confirm before anything is shared or updated.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The meeting notes, transcript or AI-generated summary.
  - The meeting purpose, date, and list of attendees with their roles.
  - The agenda, if there was one.
  - Open action items from the previous meeting.
  - Related tracker items, if tracker updates are expected.
  - The audience for the follow-up message and any confidentiality limits.
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. Read the full notes or transcript, not only an existing summary. Compare the summary with the source if both exist.
  2. List decisions. For each, quote or closely paraphrase the words that show a decision was made, and note who made it.
  3. Separate real decisions from ideas that were only discussed. Put the latter under "discussed, not decided".
  4. List action items with owner, due date and the source line. If the owner or date was not stated, write "Not stated" rather than guessing.
  5. Check previous open actions: mark each as done, still open or not mentioned.
  6. For each AI-suggested tracker update (status, priority, assignee, comment), state whether the notes support it and recommend accept, change or discard.
  7. Note open questions and disagreements that were not resolved.
  8. Draft a short follow-up message for the stated audience, leaving out sensitive or off-the-record parts.
  9. Produce everything as a draft. Do not send messages or change tracker items.
  
  ## Output format
  
  ```markdown
  ## Meeting follow-up: <meeting name> — <date>
  
  **Attendees:** <names and roles>
  **Status:** Draft for the organiser to confirm
  
  ### Decisions
  
  | Decision | Made by | Evidence from notes | Confidence |
  | -------- | ------- | ------------------- | ---------- |
  
  ### Discussed, not decided
  
  - <topic> — <what is still open>
  
  ### Action items
  
  | Action | Owner | Due | Source | Confidence |
  | ------ | ----- | --- | ------ | ---------- |
  
  ### Previous actions
  
  | Action | Owner | Status (Done / Open / Not mentioned) |
  | ------ | ----- | ------------------------------------ |
  
  ### Suggested tracker updates
  
  | Item | Suggested change | Supported by notes? | Recommendation (Accept / Change / Discard) |
  | ---- | ---------------- | ------------------- | ------------------------------------------ |
  
  ### Draft follow-up message
  
  <short message>
  
  ### Assumptions and open questions
  
  - <assumption or question (unclear owner, date, decision or sensitive point), and who can confirm>
  ```
  
  ## Watch out for
  
  - Automatic summaries can attribute statements to the wrong person or turn a suggestion into a decision. Check against the source.
  - Transcripts miss side conversations, sarcasm, and things agreed after the recording stopped.
  - An action with no owner will not happen. Flag it rather than assigning someone.
  - Suggested tracker changes such as reassigning work or changing priority affect other people. Each one needs a human to accept it.
  - Meetings often contain sensitive remarks about people, budgets or suppliers. Keep them out of the follow-up unless the organiser says otherwise.
  - Never reproduce secrets, credentials or personal data in the output unless the user needs them.
  - Check whether meeting content may be processed by AI tools under your organisation's policy.
  
  ## Before you finish
  
  - [ ] Decisions are separated from things only discussed.
  - [ ] Every action has an owner and date, or is marked "Not stated".
  - [ ] Every suggested tracker update has a recommendation and evidence.
  - [ ] The follow-up message contains nothing sensitive.
  - [ ] Nothing was sent and no tracker item was changed.
  - [ ] Clearly flag every assumption, and anything the organiser must review or decide before sharing.