Scrum Master / Agile Coach

Start here

Widely used and core to this role

• ChatGPT(opens in new tab)

  · AI chat assistant

  General AI assistant for drafting and summarising, for example a first draft of a retrospective plan or workshop agenda.

Also worth a look

Depends on your team and stack

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

• Retrospective prepGroups team feedback into themes and drafts a retrospective agendaretro-prepView · 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 retro-prep. When to use it: Prepares a Sprint Retrospective by clustering team feedback into themes, drafting an agenda with activities and timings, and adding a question on how AI helped or hindered the Sprint, while keeping the team's own words visible. Use before a retrospective, when grouping retro sticky notes or survey answers, or when asked to "prepare the retro", "cluster this feedback" or "suggest a retrospective format".

  ---
  name: retro-prep
  description: Prepares a Sprint Retrospective by clustering team feedback into themes, drafting an agenda with activities and timings, and adding a question on how AI helped or hindered the Sprint, while keeping the team's own words visible. Use before a retrospective, when grouping retro sticky notes or survey answers, or when asked to "prepare the retro", "cluster this feedback" or "suggest a retrospective format".
  metadata:
    title: "Retrospective prep"
    summary: "Groups team feedback into themes and drafts a retrospective agenda"
  ---
  
  # Retro Prep
  
  Prepare a retrospective plan and a first grouping of feedback that helps the team inspect its Sprint, without replacing the team's own conversation.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The Sprint Goal and whether it was met.
  - Team feedback collected so far (anonymous notes, survey answers), if any.
  - Actions agreed at the last retrospective and their status.
  - Notable events from the Sprint: incidents, scope changes, absences, releases.
  - Meeting length, format (in person or remote) and number of participants.
  - Anything the Scrum Master wants to focus on, and topics to avoid.
  - Whether the feedback may be processed by the AI tool you are running in, under your team's data policy.
  
  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. Remove names and identifying details from feedback before working with it, unless the team has agreed otherwise.
  2. Cluster the feedback into four to seven themes. Name each theme neutrally and keep the original notes listed under it.
  3. For each theme, note how many notes it contains and whether the notes agree or conflict. Do not merge conflicting views into one statement.
  4. List notes that do not fit any theme separately, so they are not lost.
  5. Review last retrospective's actions: done, partly done, not started. Suggest opening the session with them.
  6. Add at least one prompt about how AI tools or agents helped or hindered this Sprint, for example review effort, quality, pull request size, or who is using the tools.
  7. Draft an agenda: set the stage, gather data, generate insights, decide what to do, close. Give each part a timing that fits the meeting length.
  8. Suggest one or two activities for each part, with short instructions the Scrum Master can read out.
  9. Suggest questions the facilitator can ask to dig into each theme. Do not suggest the answers or the actions.
  10. Produce the plan as a draft for the Scrum Master.
  
  ## Output format
  
  ```markdown
  # Retrospective plan: <team> — Sprint <number>
  
  **Length:** <minutes> | **Format:** <in person / remote> | **Participants:** <n>
  
  ## Last retro's actions
  
  | Action | Status | Note |
  | ------ | ------ | ---- |
  
  ## Feedback themes (draft grouping for the team to adjust)
  
  ### <Theme name> (<n> notes)
  
  - "<original note>"
  - Agreement: <mostly agree / mixed / conflicting>
  - Questions to explore: <question>
  
  ### Unclustered notes
  
  - "<note>"
  
  ## Agenda
  
  | Time | Part | Activity | Facilitator instructions |
  | ---- | ---- | -------- | ------------------------ |
  
  ## AI in this Sprint
  
  - Prompt: <question about where AI helped or hindered>
  - Follow-up questions: <question>
  
  ## Notes for the Scrum Master
  
  - <sensitive topics, low-participation risks>
  
  ## Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - The themes are a starting point. Let the team regroup and rename them in the session.
  - Clustering can flatten a minority view or a single serious concern. Keep outliers visible.
  - Anonymous feedback can still identify someone through details. Remove those details.
  - Never reproduce secrets, credentials or personal data in the output unless the user needs them.
  - Do not write conclusions or actions for the team; the retrospective exists for the team to decide them.
  - Watch for signs of over-reliance on AI (one "AI guru", review being skipped, very large pull requests) and turn them into open questions, not accusations.
  - Retrospective input may leave your tools if an AI feature processes it. Check your policy first.
  - Do not judge or rank individual team members.
  
  ## Before you finish
  
  - [ ] Feedback is anonymised and original wording is preserved under each theme.
  - [ ] Conflicting views and outliers are visible.
  - [ ] There is a prompt about how AI helped or hindered.
  - [ ] The agenda fits the meeting length.
  - [ ] No actions or conclusions were decided on the team's behalf.
  - [ ] Clearly flag every assumption, and anything the Scrum Master must review or decide, including sensitive themes.
  

• Team AI working agreementDrafts the team's own agreement on how it works with AI tools, with open questionsteam-ai-working-agreementView · 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 team-ai-working-agreement. When to use it: Drafts a team-authored working agreement on how the team works with AI tools and agents inside an existing organisation or team AI policy, covering a Definition of Done for AI-assisted work, review pairing, change size, sharing skills and how the team inspects AI use in retrospectives, with open questions for the team to decide. It does not approve tools, set data rules, agent permissions or spend; those belong in the manager-owned team AI policy. Use when a team starts using AI coding or writing tools under an existing policy, when refreshing working agreements, or when asked to "draft an AI working agreement", "agree team norms for AI" or "how should our team work with AI".

  ---
  name: team-ai-working-agreement
  description: Drafts a team-authored working agreement on how the team works with AI tools and agents inside an existing organisation or team AI policy, covering a Definition of Done for AI-assisted work, review pairing, change size, sharing skills and how the team inspects AI use in retrospectives, with open questions for the team to decide. It does not approve tools, set data rules, agent permissions or spend; those belong in the manager-owned team AI policy. Use when a team starts using AI coding or writing tools under an existing policy, when refreshing working agreements, or when asked to "draft an AI working agreement", "agree team norms for AI" or "how should our team work with AI".
  metadata:
    title: "Team AI working agreement"
    summary: "Drafts the team's own agreement on how it works with AI tools, with open questions"
  ---
  
  # Team AI Working Agreement
  
  Draft team norms that the team can discuss, change and adopt, so AI tools help the work while humans stay accountable for it. The agreement sits inside your AI policy: the policy (owned and approved by management) decides which tools and data are allowed; the team decides how it works day to day.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The name of the AI policy that applies to the team, so the agreement can point to it rather than repeat it.
  - The AI tools and agents the team currently uses.
  - The team's current working agreements and Definition of Done.
  - The team's review practice for code and other work.
  - Known concerns from the team (quality, over-reliance, skills, uneven use).
  - When and how the team will discuss the draft.
  
  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. Note which AI policy applies. Do not restate or change tool approvals, data rules, agent permissions or spend; write "Follow your organisation's AI policy" and link to it. If no policy exists, flag this as a blocker for the engineering manager to resolve.
  2. List the team's work types (for example code, tests, stories, documentation, meeting notes) and, for each, propose how the team works with AI within the policy: AI drafts and a person reviews, AI assists a person, or the team prefers to work without it. Mark each as a proposal.
  3. State accountability: the person who submits AI-assisted work is accountable for it, and AI-generated code gets the same review rigour as a teammate's.
  4. Propose a Definition of Done for AI-assisted work: tests are not skipped, reviews are not shortened, the author can explain the change, and documentation still applies.
  5. Propose review pairing: who reviews AI-assisted work, and when two people review or pair on large or unfamiliar AI output.
  6. Propose a guideline on change size, for example splitting large AI-generated changes into smaller pull requests that can be reviewed properly.
  7. Propose how the team will set aside time in Sprint Planning to validate AI output.
  8. Propose ways to spread skills: pairing, sharing prompts that worked, and avoiding a single "AI expert" everyone depends on.
  9. Propose how the team inspects AI use in retrospectives: a standing question on how AI helped or hindered, what to look at (review effort, rework, change size), and when to revisit the agreement.
  10. List open questions where the team must choose. Produce the result as a draft for team discussion.
  
  ## Output format
  
  ```markdown
  # AI working agreement (draft for team discussion): <team>
  
  **Works within:** <policy name — follow your organisation's AI policy for tools, data, agent permissions and spend> or "No policy provided — blocker"
  **Review date:** <proposed>
  
  ## Our principles
  
  1. Humans stay accountable for all work, including work AI generated.
  2. We follow our organisation's AI policy; this agreement only adds team norms.
  3. <principle>
  
  ## How we work with AI
  
  | Work type | AI drafts, person reviews | AI assists | We prefer not to use AI | Notes |
  | --------- | ------------------------- | ---------- | ----------------------- | ----- |
  
  ## Definition of Done for AI-assisted work
  
  - <agreement>
  
  ## Review pairing
  
  - <agreement>
  
  ## Change size
  
  - <agreement>
  
  ## Planning and validation time
  
  - <agreement>
  
  ## Sharing skills
  
  - <agreement>
  
  ## How we inspect AI use in retrospectives
  
  - <retro question, what we look at, review cadence>
  
  ## Assumptions and open questions
  
  - <question for the team> — options: <…>
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - An agreement written for the team, rather than with it, will not be followed. Keep every item a proposal.
  - People can over-trust automated output and stop checking it. Build explicit review steps into the agreement.
  - Speed can crowd out quality. Do not let the agreement relax tests or reviews to go faster.
  - Uneven use (some people rely on AI heavily, others avoid it) is a coaching topic, not a rule violation.
  - Do not use the agreement to monitor or rate individuals.
  - A working agreement cannot override the AI policy. If a proposed norm conflicts with it, flag the conflict to the policy owner rather than resolving it.
  - Questions about which tools are approved or what data may go into them belong to the policy owner, not the team's agreement.
  
  ## Before you finish
  
  - [ ] The agreement points to the AI policy, or its absence is flagged as a blocker; no tool approvals or data rules are restated.
  - [ ] Human accountability and review rigour are explicit.
  - [ ] The Definition of Done is not weakened.
  - [ ] There is a way to inspect and revise the agreement.
  - [ ] Every item is marked as a proposal, with open questions listed.
  - [ ] Clearly flag every assumption, and anything the team or Scrum Master must review or decide.
  

• Refinement session prepSpots unclear or oversized backlog items and suggests questions for the team to discussrefinement-session-prepView · 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 refinement-session-prep. When to use it: Prepares a backlog refinement session by scanning draft backlog items, including AI-drafted stories, for unclear outcomes, missing acceptance criteria, hidden dependencies and items too large for a Sprint. Its output is facilitation questions for the team, not a quality verdict on the items (a requirements quality review is a business analyst skill). Use before backlog refinement, when bringing AI-generated user stories to the team, or when asked to "prep refinement" or "which items are ready to discuss in refinement".

  ---
  name: refinement-session-prep
  description: Prepares a backlog refinement session by scanning draft backlog items, including AI-drafted stories, for unclear outcomes, missing acceptance criteria, hidden dependencies and items too large for a Sprint. Its output is facilitation questions for the team, not a quality verdict on the items (a requirements quality review is a business analyst skill). Use before backlog refinement, when bringing AI-generated user stories to the team, or when asked to "prep refinement" or "which items are ready to discuss in refinement".
  metadata:
    title: "Refinement session prep"
    summary: "Spots unclear or oversized backlog items and suggests questions for the team to discuss"
  ---
  
  # Refinement Session Prep
  
  Help the Scrum Master and Product Owner walk into refinement with a clear view of which items are ready to discuss and which questions the team needs to answer. The output is facilitation questions, not a quality verdict; a requirements quality review is a business analyst skill.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The backlog items to be refined, with titles, descriptions and acceptance criteria.
  - Which items were drafted or expanded by an AI tool.
  - The Product Goal and, if known, the likely next Sprint Goal.
  - The team's Definition of Ready (if it uses one) and Definition of Done.
  - Known dependencies on other teams or systems.
  - Session length and who will attend.
  
  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. For each item, restate in one sentence the user or business outcome it delivers. If you cannot, mark the outcome as unclear.
  2. Check acceptance criteria: are they present, testable and free of vague words such as "fast", "easy" or "better"?
  3. Check size signals: several outcomes in one item, many acceptance criteria, or work across many components. Suggest possible ways to split, labelled as options.
  4. List dependencies and assumptions each item relies on, including data, access, other teams and decisions not yet made.
  5. For AI-drafted items, look for content the team did not ask for: invented requirements, generic criteria copied across items, or details that conflict with the Product Goal.
  6. Note questions about how the work will be tested and reviewed, including time to validate AI-generated output.
  7. Suggest a discussion order for this session only; this is not Product Backlog order.
  8. Write facilitation questions for each item that invite the team to challenge the draft.
  9. Produce the prep notes. Do not estimate items, reorder the Product Backlog or edit items in your tracker; the team and Product Owner decide those.
  
  ## Output format
  
  ```markdown
  # Refinement prep: <team> — <date>
  
  **Product Goal:** <goal>
  **Session length:** <minutes>
  
  ## Suggested discussion order (this session only, not Product Backlog order)
  
  | #   | Item | Outcome clear? | Criteria testable? | Possibly too large? | AI-drafted? |
  | --- | ---- | -------------- | ------------------ | ------------------- | ----------- |
  
  ## Item notes
  
  ### <Item title>
  
  - **Outcome as understood:** <sentence or "Unclear">
  - **Acceptance criteria issues:** <list>
  - **Dependencies and assumptions:** <list>
  - **Possible splits (options only):** <list>
  - **AI-draft concerns:** <list or "None found">
  - **Questions for the team:**
    1. <question>
  
  ## Cross-item observations
  
  - <repeated gaps, shared dependencies>
  
  ## For the Scrum Master and Product Owner
  
  - <decisions they need to make>
  
  ## Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - AI drafts read smoothly and can look finished. Fluent wording is not the same as a shared understanding.
  - Generic acceptance criteria repeated across items often mean nobody thought about the specific case.
  - Do not estimate or commit on the team's behalf. Sizing belongs to the people doing the work.
  - Splitting suggestions are options. The Product Owner decides value and order.
  - Leave out customer names or sensitive details not needed for the session.
  - Never reproduce secrets, credentials or personal data in the output unless the user needs them.
  - Do not grade the items or their authors. Turn every gap into a question for the team.
  - Encourage the whole team to question drafts, not only the person who generated them.
  
  ## Before you finish
  
  - [ ] Every item has an outcome statement or is marked unclear.
  - [ ] Acceptance criteria issues and dependencies are listed per item.
  - [ ] AI-drafted items were checked for invented or generic content.
  - [ ] No estimates, backlog reordering or tracker edits were made.
  - [ ] Questions invite the team to challenge the drafts.
  - [ ] Clearly flag every assumption, and anything the Scrum Master, Product Owner or team must review or decide.