Business Analyst

Start here

Widely used and core to this role

• ChatGPT(opens in new tab)

  · AI chat assistant

  Drafting interview guides, rewording rough requirements, and producing first-draft user stories and acceptance criteria for review.

Also worth a look

Depends on your team and stack

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

• Epic to storiesSplits an epic into user stories with acceptance criteria, flagging anything inventedepic-to-stories-and-criteriaView · 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 epic-to-stories-and-criteria. When to use it: Breaks an epic into user stories with GIVEN/WHEN/THEN acceptance criteria, using a written domain context, and explicitly covers edge cases, business rules and non-functional requirements while flagging anything invented. Use when a business analyst asks to split an epic or feature into stories, write acceptance criteria, draft backlog items from an epic, or produce requirements that testers or coding agents will work from.

  ---
  name: epic-to-stories-and-criteria
  description: "Breaks an epic into user stories with GIVEN/WHEN/THEN acceptance criteria, using a written domain context, and explicitly covers edge cases, business rules and non-functional requirements while flagging anything invented. Use when a business analyst asks to split an epic or feature into stories, write acceptance criteria, draft backlog items from an epic, or produce requirements that testers or coding agents will work from."
  metadata:
    title: "Epic to stories"
    summary: "Splits an epic into user stories with acceptance criteria, flagging anything invented"
  ---
  
  # Epic to Stories and Acceptance Criteria
  
  Draft a reviewable set of user stories and acceptance criteria from an epic, grounded in the domain and honest about gaps.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The epic: goal, scope, business value and any notes from workshops or interviews.
  - A domain context description: key terms, business rules, user roles, the systems involved and the architecture at a high level. If none exists, offer to draft one first and have the analyst correct it.
  - Known non-functional and regulatory requirements (performance, security, privacy, accessibility, audit, retention).
  - The team's story conventions: template, size expectations, definition of ready, and how acceptance criteria are written.
  - Who reads the stories next (developers, testers generating test cases, a coding agent) and what they need.
  - Confirmation that the material may be used here under the organisation's AI and 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. Restate the epic goal, the users involved and what is out of scope. List any terms you could not find in the domain context.
  2. Identify the user roles and the main journeys through the epic. Confirm them with the analyst if they are unclear.
  3. Draft stories in the team's template, one user goal per story. Keep each small enough for the team's usual sprint size.
  4. For each story, write acceptance criteria in GIVEN/WHEN/THEN form. Cover the main path, then alternative paths.
  5. For each story, add edge cases deliberately: empty or missing data, invalid input, permissions, concurrency, cancellation, limits, time zones and dates, and failure of a dependent system.
  6. Add non-functional criteria where they apply. If a non-functional need is likely but unspecified, add it as an open question rather than inventing a number.
  7. Mark every business rule by origin: "from source" (with a reference to the epic, notes or domain context) or "assumed". Assumed rules must be confirmed by a stakeholder.
  8. Check the set as a whole: no gaps between stories, no duplicates, no contradictions, and every part of the epic scope is covered by at least one story.
  9. List questions for stakeholders, grouped by who can answer them.
  
  ## Output format
  
  ```markdown
  # Stories for epic: <epic name>
  
  **Epic goal:** <one sentence>
  **Out of scope:** <items>
  **Domain context used:** <document name or "drafted in this session">
  **Status:** Draft for analyst and stakeholder review
  
  ## Story <N>: <short title>
  
  As a <role>, I want <capability> so that <benefit>.
  
  **Acceptance criteria**
  
  1. GIVEN <context> WHEN <action> THEN <outcome>
  
  **Edge cases**
  
  - GIVEN <context> WHEN <action> THEN <outcome>
  
  **Non-functional**
  
  - <criterion or "open question: …">
  
  **Business rules**
  
  | Rule | Origin (from source + reference / assumed) |
  | ---- | ------------------------------------------ |
  
  ## Coverage check
  
  | Epic scope item | Covered by stories |
  | --------------- | ------------------ |
  
  ## Assumptions and open questions
  
  - <assumption or question, who can confirm, and which story it blocks>
  ```
  
  ## Watch out for
  
  - Never reproduce secrets, credentials or personal data (names, emails, account details) from interview notes or tickets in the output unless the user needs them; anonymise quotes by default.
  - Drafts tend to invent plausible business rules. Never state a rule as fact without a source; mark it "assumed".
  - Look for roles and cases outside the main journey.
  - State non-functional needs explicitly so later test design covers them. If they are unknown, raise them as questions.
  - Vague wording gets built exactly as written when a coding agent or test generator reads it. Replace words like "quickly", "appropriate" or "user-friendly" with testable statements or questions.
  - Poor domain context produces poor stories. If the context is thin, say so at the top of the output.
  - Do not create or update items in the team's tracker. Produce a draft for the analyst to review and enter.
  
  ## Before you finish
  
  - [ ] Every story has main-path, edge-case and non-functional criteria, or an open question in their place.
  - [ ] Every business rule is marked "from source" or "assumed".
  - [ ] The coverage check shows every epic scope item.
  - [ ] No unexplained vague terms remain in acceptance criteria.
  - [ ] Clearly flag your assumptions and anything a stakeholder or the analyst must review or decide before these stories go into refinement.
  

• Stakeholder requirement rewriteRewrites rough stakeholder asks as clear, testable requirements for them to confirmstakeholder-requirement-rewriteView · 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 stakeholder-requirement-rewrite. When to use it: Rewrites rough stakeholder statements from interviews, workshops or emails into clear, testable requirements, keeps each original beside its rewrite, flags any possible change of meaning, and prepares a confirmation message for the stakeholder. Use when a business analyst asks to clean up, reword or formalise requirements, turn meeting notes or wishlists into requirement statements, or prepare requirements for stakeholder sign-off.

  ---
  name: stakeholder-requirement-rewrite
  description: "Rewrites rough stakeholder statements from interviews, workshops or emails into clear, testable requirements, keeps each original beside its rewrite, flags any possible change of meaning, and prepares a confirmation message for the stakeholder. Use when a business analyst asks to clean up, reword or formalise requirements, turn meeting notes or wishlists into requirement statements, or prepare requirements for stakeholder sign-off."
  metadata:
    title: "Stakeholder requirement rewrite"
    summary: "Rewrites rough stakeholder asks as clear, testable requirements for them to confirm"
  ---
  
  # Stakeholder Requirement Rewrite
  
  Turn a stakeholder's rough words into clear requirements without losing what they meant, and set up the stakeholder to confirm it.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The original statements, in the stakeholder's own words where possible, with who said each one and in what setting.
  - The context: the business process, the problem being solved and the project scope.
  - The team's glossary or domain context, so key terms are used consistently.
  - The requirement style the team uses (for example "The system shall…", user stories, or rules tables).
  - Confirmation that the notes may be used here under the organisation's AI and data policy, with personal or confidential details removed if not needed.
  
  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. Number each original statement and keep it word for word. Do not correct or shorten the originals.
  2. Split statements that contain more than one need into separate items, and note which original each came from.
  3. Rewrite each item as a clear requirement in the team's style: one need, a named actor, a measurable or observable outcome, and consistent glossary terms.
  4. Compare each rewrite with its original, looking for meaning drift:
     - anything added (a new condition, number, actor or scope)
     - anything removed (a qualifier, exception or emotion that signals priority)
     - anything changed (a "should" that became "must", a "sometimes" that became "always", a different term)
  5. Record every difference in a drift note. If there are none, write "no differences found" rather than leaving it blank.
  6. Where the original is ambiguous, do not pick one reading silently. Offer two or three interpretations and turn them into a question.
  7. Flag items that sound like solutions ("add a button that…") and propose the underlying need as a question, keeping the original request visible.
  8. Draft a short confirmation message the analyst can send to each stakeholder, showing their words, the rewrite and the specific questions. Do not send it.
  
  ## Output format
  
  ```markdown
  # Requirement rewrites for confirmation
  
  **Source:** <interview/workshop/email, date>
  **Status:** Draft, not yet confirmed by stakeholders
  
  ## Rewrites
  
  | #   | Original (verbatim) | Stakeholder | Rewrite | Drift note | Question |
  | --- | ------------------- | ----------- | ------- | ---------- | -------- |
  
  ## Ambiguous items
  
  ### Item <#>
  
  - **Original:** "<verbatim>"
  - **Interpretation A:** <…>
  - **Interpretation B:** <…>
  - **Question to ask:** <…>
  
  ## Solution-shaped requests
  
  | #   | Request as stated | Possible underlying need (to confirm) |
  | --- | ----------------- | ------------------------------------- |
  
  ## Confirmation message draft: <stakeholder name>
  
  <short, plain message listing their original words, the rewrites and questions>
  
  ## Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - A rewrite can read better than the original and still mean something different. The drift note is required for every item.
  - Do not add numbers, deadlines, thresholds or rules the stakeholder did not state. Ask for them instead.
  - Strength of language carries priority. "It would be nice" and "we cannot go live without" must not end up worded the same.
  - A requirement is not confirmed because it is well written. Mark everything as unconfirmed until the stakeholder agrees.
  - Conflicts between stakeholders should be surfaced side by side, not merged into a compromise.
  - Never send messages or update shared documents; the analyst decides what goes out.
  - Never reproduce secrets, credentials or personal data (names, emails, account details) in the output unless the user needs them; anonymise quotes by default. Stakeholder names are needed only to route confirmations.
  
  ## Before you finish
  
  - [ ] Every original is kept verbatim and linked to its rewrite.
  - [ ] Every rewrite has a drift note, even if it says no differences were found.
  - [ ] Ambiguities are turned into questions, not resolved by guessing.
  - [ ] No new numbers, rules or scope appear in the rewrites.
  - [ ] Clearly flag your assumptions and anything the stakeholder or analyst must review or decide before these requirements are treated as agreed.
  

• Requirements quality reviewChecks stories or requirements for clarity and testability, with suggested fixesrequirements-quality-reviewView · 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 requirements-quality-review. When to use it: Reviews a set of user stories or requirements against explicit quality criteria, such as clear, testable, independent, consistent, complete and covering non-functional needs, and returns specific findings with suggested fixes and questions. Use when a business analyst asks to check, critique or quality-review a backlog, requirements document, stories or acceptance criteria before refinement, sign-off, test design or handing a spec to developers or a coding agent.

  ---
  name: requirements-quality-review
  description: "Reviews a set of user stories or requirements against explicit quality criteria, such as clear, testable, independent, consistent, complete and covering non-functional needs, and returns specific findings with suggested fixes and questions. Use when a business analyst asks to check, critique or quality-review a backlog, requirements document, stories or acceptance criteria before refinement, sign-off, test design or handing a spec to developers or a coding agent."
  metadata:
    title: "Requirements quality review"
    summary: "Checks stories or requirements for clarity and testability, with suggested fixes"
  ---
  
  # Requirements Quality Review
  
  Review requirements against clear criteria and return specific, fixable findings for the analyst to act on.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The requirements or stories to review, each with an identifier.
  - The quality criteria to apply. If the team has none, propose the default list in step 1 and confirm it.
  - The domain context or glossary, and any related documents the requirements must agree with (policies, process maps, earlier decisions).
  - Who uses the requirements next (developers, testers, a coding agent, an external supplier) and the review's purpose, such as refinement readiness or sign-off.
  - Confirmation that the material may be used here under the organisation's AI and 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. Agree the criteria before reviewing. A reasonable default:
     - **Clear:** one reading only; no vague words without a definition.
     - **Testable:** a tester could say pass or fail.
     - **Atomic:** one need per item.
     - **Consistent:** no contradictions with other items or the glossary.
     - **Complete:** actor, trigger, outcome, and error or exception handling are present.
     - **Non-functional covered:** performance, security, privacy, accessibility and regulatory needs are stated or explicitly not applicable.
     - **Valuable and traceable:** the reason or source is known.
  2. Review each item against every criterion. Record only real findings, each tied to a criterion and a quote of the problem text.
  3. Rate each finding as blocking (cannot be built or tested as written), important, or minor. Explain the rating in a few words.
  4. For each finding, suggest a fix. If the fix needs information you do not have, write a question instead of inventing the answer.
  5. Review the set as a whole: contradictions between items, duplicates, gaps between items, and non-functional needs missing across the set.
  6. Note what is good and should be kept, briefly, so the analyst does not rewrite sound items.
  7. Summarise readiness per item: ready, ready with minor fixes, or not ready.
  
  ## Output format
  
  ```markdown
  # Requirements quality review: <document or backlog name>
  
  **Items reviewed:** <count and IDs>
  **Criteria used:** <list>
  **Purpose:** <refinement readiness / sign-off / handover>
  **Status:** AI review draft for analyst judgement
  
  ## Summary
  
  | Item | Readiness | Blocking | Important | Minor |
  | ---- | --------- | -------- | --------- | ----- |
  
  ## Findings
  
  | Item | Criterion | Severity | Problem text | Why it matters | Suggested fix or question |
  | ---- | --------- | -------- | ------------ | -------------- | ------------------------- |
  
  ## Set-level issues
  
  - **Contradictions:** <item IDs and description>
  - **Duplicates:** <…>
  - **Gaps:** <…>
  - **Non-functional coverage:** <…>
  
  ## Worth keeping
  
  - <item ID>: <what works well>
  
  ## Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - Never reproduce secrets, credentials or personal data found in backlog items in the output; refer to the item ID instead.
  - Reviews without explicit criteria drift into style preferences. Tie every finding to an agreed criterion.
  - Suggested fixes can quietly change what a stakeholder asked for. When a fix alters meaning, mark it as a question for the stakeholder, not a correction.
  - Missing non-functional and regulatory requirements are easy to overlook in both drafting and review. Check them on every item and across the set.
  - Do not invent business rules to make an item "complete". Ask.
  - AI reviews can be inconsistent between runs. Keep the criteria and severity definitions fixed, and treat the review as input to the analyst's judgement, not a verdict.
  - Do not edit the source document or tracker items directly.
  
  ## Before you finish
  
  - [ ] Every finding names a criterion and quotes the problem text.
  - [ ] Every item has a readiness rating.
  - [ ] Set-level contradictions, gaps and non-functional coverage were checked.
  - [ ] Meaning-changing fixes are framed as stakeholder questions.
  - [ ] Clearly flag your assumptions and anything the analyst or stakeholders must review or decide before acting on this review.