Everything a business analyst reaches for, in one place.

I'm a business analyst preparing a 45-minute discovery interview with [stakeholder role] about [process or problem].

Context: [what we already know, in 2-3 sentences]

Draft an interview guide with:
1. A one-line purpose statement I can open with
2. 12 open questions grouped into: current process, pain points, exceptions, data and systems, success measures
3. Two follow-up probes for each question
4. Three questions that surface unstated assumptions or politics
Avoid leading and yes/no questions.

Below are my raw notes from an interview with [role].
<notes>
[paste notes]
</notes>

Organise them into: confirmed facts, pain points (with frequency or impact if mentioned), requirements stated or implied, assumptions to validate, open questions and quotes worth keeping.
Mark anything you inferred rather than read in the notes with (inferred).

Design a [duration] requirements workshop for [number] participants from [teams]. Goal: [decision or output we need].

Give me: a timed agenda, the activity for each block (e.g. silent brainstorming, dot voting, process walk-through), the materials needed, the output each block should produce, and how to handle one dominant voice in the room.

Write a short survey (max 10 questions, under 5 minutes) for [audience] to validate these findings from interviews:
[list findings]

Mix multiple choice, a 1-5 scale and at most 2 open questions. For each question note which finding it validates. Keep the wording neutral and avoid double-barrelled questions.

Here is what I know about [initiative] so far:
[summary of findings, scope and stakeholders]

Act as a senior business analyst reviewing my discovery. List the 15 most important questions I haven't answered yet, grouped by: scope, users, data, edge cases, non-functional needs, compliance and change impact. Rank each as high, medium or low risk if left unanswered.

Turn these notes into user stories using "As a [role], I want [goal], so that [benefit]".
<notes>
[paste notes]
</notes>

For each story add 3-5 acceptance criteria in Given/When/Then form. Keep stories small enough to finish in one sprint. List anything ambiguous as an open question rather than guessing.

Review these user stories against INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable):
[paste stories]

For each story: score each letter pass/weak/fail with a one-line reason, then rewrite the story so it passes. If a story is too big, split it and say which splitting pattern you used.

Sort these requirements into functional and non-functional:
[paste list]

For non-functional ones, name the category (performance, security, availability, usability, compliance, scalability) and rewrite each so it is measurable, e.g. "loads in under 2 seconds for 95% of requests".

Here is a feature description:
[describe the feature]

List the edge cases, exception flows and error states. For each give: the trigger, what the system should do, and the message the user sees. Include empty states, permissions, timeouts, duplicate submissions and partial failures.

Review these requirements as a strict QA lead:
[paste requirements]

Flag words that make a requirement untestable (fast, easy, user-friendly, etc.), missing actors, conflicting requirements and anything that describes a solution instead of a need. Return a table: ID, issue, why it matters, suggested rewrite.

Here is how [process] works today, as described by the team:
<description>
[paste description]
</description>

Write it as a numbered as-is process with: step, actor, system or tool, input, output and average time if mentioned. Then list the hand-offs, wait states and rework loops you can see.

Using this as-is process:
[paste as-is steps]

Propose a to-be process that removes waste. For each change say what was removed or automated, why, and what it depends on (system change, policy change, training). Keep a human in the loop for any judgement or approval step.

Build a SIPOC for [process]: Suppliers, Inputs, Process (5-7 high-level steps), Outputs, Customers.
Context: [one paragraph]
Then list 3 scope questions the SIPOC raises that the sponsor should answer.

Convert this process into a Mermaid flowchart (flowchart TD). Use rectangles for steps, diamonds for decisions and label every decision branch. Keep labels under 6 words.
[paste process steps]

Problem: [describe the problem and its impact]
Facts we know: [list]

Run a 5 Whys analysis. Show two alternative causal chains if the evidence supports more than one. End with the most likely root cause, how to verify it with data, and one countermeasure for each chain.

Here are column names and 10 sample rows from [table or file]:
[paste]

Draft a data dictionary: field name, plain-English definition, data type, example value, allowed values or format, whether it can be empty, and the likely source system. Flag fields whose meaning is unclear.

Database: [PostgreSQL / SQL Server / BigQuery / other]
Tables and columns:
[paste schema]

Write a SQL query that answers: "[business question]".
Explain each clause in one line, state any assumptions about the data, and add a second version that handles NULLs and duplicates safely.

Explain this SQL to a business stakeholder in plain English, then to an analyst in technical terms. Point out performance risks and logic that could produce wrong numbers (joins that fan out, filters in the wrong place, NULL handling).
[paste query]

For a dataset about [subject] with these fields:
[list fields]

List the data quality checks I should run: completeness, uniqueness, validity, consistency and timeliness. For each give the rule, a SQL snippet to test it, and the threshold that should trigger an alert.

We want to measure [goal] for [team or product].

Propose 5 KPIs. For each: name, exact formula, data source, refresh frequency, owner, target or benchmark, and one way it could be gamed or misread. Mark which are leading and which are lagging indicators.

Initiative: [name and one-line goal]
Stakeholders: [list names or roles]

Place each stakeholder on a power/interest grid and explain why. Then give an engagement plan: what they care about, what they need from us, channel, frequency and the risk if we get them wrong.

Rewrite this for a senior executive in under 150 words. Lead with the decision or ask, then impact in numbers, then risks and the next step. No jargon.
[paste update or document]

A stakeholder ([role]) asked to add [request] to [project] after scope was agreed. Impact: [time, cost, risk].

Draft a short, friendly reply that acknowledges the value, explains the trade-off with numbers, and offers options: add later, swap for something of equal size, or extend the timeline with sponsor approval.

Turn these notes into a status update with: overall RAG status and why, done this week, planned next week, risks and issues (owner and date), and decisions needed. Keep it scannable.
[paste notes]

[Stakeholder A] wants [requirement A] because [reason]. [Stakeholder B] wants [requirement B] because [reason].

Analyse the underlying interests of both, find what they have in common, and propose 3 options that satisfy the shared goal. For each option list trade-offs and who would need to agree.

Split this epic into user stories that each deliver value on their own:
[epic description]

Use splitting patterns such as workflow steps, business rules, data variations and happy path first. For each story give a one-line acceptance summary and mark the smallest set that would be a useful first release.

Prioritise these backlog items using [MoSCoW / RICE / WSJF]:
[paste items with any data on reach, impact, effort]

Show your scoring, state any assumptions you made, and highlight items that look important but have weak evidence.

Draft a Definition of Ready and a Definition of Done for a [team type] team working on [product]. Keep each to 6-8 checkable items, and add a note on who checks each item and when.

Sprint goal: [goal]
Completed: [list]
Not completed: [list and why]

Write a 15-minute sprint review outline that demos outcomes for users, shows progress toward the product goal, and ends with 3 specific questions for stakeholder feedback.

Here are retrospective notes from the team:
[paste notes]

Group them into themes, identify the 2 themes with the biggest impact, and propose one specific, owned and time-boxed action for each. Note any theme that keeps repeating from previous retros: [previous themes].

Write test cases for this user story and its acceptance criteria:
[paste story and criteria]

Return a table: test ID, scenario, preconditions, steps, test data, expected result, priority. Include positive, negative and boundary cases.

Draft a UAT plan for [release or system] with [number] business testers from [teams].

Include: scope and out of scope, entry and exit criteria, schedule, roles, how defects are logged and triaged (severity definitions), sign-off process and a daily check-in agenda.

Turn this description into a defect report: title, environment, steps to reproduce, expected result, actual result, severity with reason, and any data or screenshots to attach.
[paste what happened]

We are changing [component or feature]: [describe change].
Related features: [list]

List what could break, ranked by likelihood and impact, and propose the minimum regression test set that covers the highest risks.

Design test data for [feature] covering normal, boundary and invalid cases. Fields: [list fields and rules].
Return it as a CSV-ready table of 15 rows, with a column explaining what each row is testing. Do not use real personal data.

Using these notes, draft a business requirements document with: background, problem statement, objectives with measures, scope (in and out), stakeholders, business requirements (numbered), assumptions, constraints, dependencies and open questions.
<notes>
[paste notes]
</notes>
Keep requirements numbered so they can be traced later.

Rewrite this for [audience] at a reading level they will understand. Keep every requirement and number intact, use short sentences and active voice, and add a 3-bullet summary at the top.
[paste text]

Write a decision log entry: decision, date, context, options considered with pros and cons, rationale, who decided, who was consulted, and how we will know if it was the right call.
Notes: [paste notes]

Turn these tickets into release notes for [audience]: group by new, improved and fixed, lead each item with the user benefit, and skip internal-only changes.
[paste ticket titles and descriptions]

Extract every term, acronym and piece of jargon from this document and build a glossary: term, plain-English definition, and where it is used. Flag terms that are used inconsistently.
[paste document]

Process: [describe]
Volume: [times per week or month]
Time per run: [minutes]
Error rate today: [if known]

Assess whether to automate: annual hours saved, rough build effort, risks, and what must stay human. Give a go / not yet / no answer with reasons.

Turn this process into an automation spec for [n8n / Make / Zapier]:
[paste process steps]

Include: trigger, each step as a node (app, action, key fields), data mapping between steps, error handling and retries, where a human approves, logging, and how we will test it before go-live.

Outline an n8n workflow that [goal], starting from [trigger, e.g. new form submission or webhook].

List each node in order with its type (e.g. Webhook, IF, Set, HTTP Request, AI Agent, Google Sheets), what it does and the key settings. Add an error workflow and say where credentials are needed. Keep it simple enough to build in an afternoon.

Inside an automation, an AI step must [classify / extract / summarise / draft] [input type].

Write the system prompt for that step, the exact JSON output schema, 3 example inputs with expected outputs, and the rule for when the result should go to a human for review (e.g. low confidence or missing fields).

Write a one-page runbook for this automation: [name and what it does].
Cover: purpose, trigger and schedule, systems and credentials involved (no secrets), what normal looks like, common failures and how to fix them, who to contact, and how to pause it safely.