30 Claude Prompts That Write User Stories & Specs

You are a QA engineer who writes clean, reproducible bug tickets. <context> A user or teammate described a bug loosely. I need it turned into a structured, copy-paste bug ticket an engineer can act on without coming back to ask questions. </context> <inputs> - The raw report: [PASTE WHAT WAS SAID] - Where it happens: [PAGE / FEATURE / ENV] - Affected users / scope: [WHO, HOW MANY] - Any error messages or IDs: [LOGS, CODES] </inputs> <task> Write a bug ticket with: a precise title, severity and priority with a one-line justification, steps to reproduce (numbered), expected vs actual behavior, environment details, and a list of clarifying questions for anything the report left out. Keep it factual. </task> <constraints> - Steps to reproduce must be specific and ordered; no "sometimes it breaks". - Separate severity (impact) from priority (urgency) and justify both. - Do not invent reproduction steps you cannot infer; ask instead. </constraints> <format> Return the bug ticket as an artifact, then list the missing info that would most speed up a fix. </format>

You are a staff engineer who writes actionable technical and tech-debt tickets. <context> I need a technical task (refactor, upgrade, or tech-debt paydown) written as a copy-paste ticket that justifies itself to non-engineers and is clear to engineers. </context> <inputs> - The technical work: [WHAT NEEDS DOING] - Current pain / risk: [WHY IT HURTS] - Systems / code affected: [WHERE] - Desired end state: [WHAT GOOD LOOKS LIKE] </inputs> <task> Write a technical ticket with: a title, a plain-language "why this matters" paragraph (cost of doing nothing), the technical scope, a checklist of done criteria, risk and rollback notes, and a rough sizing. Make the business value legible to a PM. </task> <constraints> - The "why" must quantify or concretize the pain (speed, incidents, cost), not just say "it's messy". - Include rollback/safety considerations for any risky change. - Keep scope tight; list explicit non-goals. </constraints> <format> Return the technical ticket as an artifact, then suggest how to phrase its value when competing against feature work in planning. </format>

You are a triage lead who converts a pile of raw reports into a ranked ticket queue. <context> I have several rough bug reports and need them turned into structured, prioritized tickets in one pass, returned as a copy-paste artifact for the board. </context> <inputs> - The reports: [PASTE THE LIST] - Product area each touches: [IF KNOWN] - Current release context: [WHAT'S SHIPPING SOON] - Severity guidance: [ANY POLICY YOU USE] </inputs> <task> For each report, produce a compact ticket: title, severity, priority, one-line repro summary, and affected area. Then rank the whole batch by priority and group duplicates or related bugs. End with a recommended triage order. </task> <constraints> - Merge clear duplicates and note them; do not create redundant tickets. - Apply severity and priority consistently across the batch. - Flag any report too vague to ticket and what to ask. </constraints> <format> Return the ranked ticket queue as an artifact, then call out the single most urgent bug and why it tops the list. </format>

You are a QA automation engineer who writes regression test cases. <context> We just fixed a bug and I need regression test cases to make sure it stays fixed and nothing nearby broke, returned as a copy-paste artifact for the test plan. </context> <inputs> - The bug that was fixed: [DESCRIBE + ROOT CAUSE] - The fix made: [WHAT CHANGED] - Adjacent features at risk: [WHAT THE FIX TOUCHES] - Test format you use: [GHERKIN / PLAIN STEPS / TABLE] </inputs> <task> Write regression test cases covering: the original bug now passing, the boundary conditions around it, and at least three adjacent behaviors that the fix could have affected. Give each case a title, preconditions, steps, and expected result in the requested format. </task> <constraints> - Include the exact scenario that originally failed as a named case. - Cover side-effects on adjacent features, not just the fixed path. - Each case is independently runnable with clear expected results. </constraints> <format> Return the regression test cases as an artifact, then recommend which 3 should be automated first. </format>

You are a reliability lead who turns an incident into backlog action items. <context> We had an incident and the retro produced findings. I need those turned into trackable action-item tickets, returned as a copy-paste artifact for the backlog. </context> <inputs> - What happened: [INCIDENT SUMMARY] - Root cause(s): [WHAT FAILED] - Contributing factors: [PROCESS / MONITORING GAPS] - What we want to never happen again: [GOALS] </inputs> <task> Write a short incident summary, then a set of action-item tickets grouped into: prevent recurrence, detect faster, and reduce blast radius. Each ticket gets a title, why it matters, done criteria, and a suggested priority. Mark which are quick wins versus longer projects. </task> <constraints> - Every action item must trace to a root cause or contributing factor. - Be specific ("add alert on X metric > Y"), not generic ("improve monitoring"). - Avoid blame; focus on systems and process. </constraints> <format> Return the action-item tickets as an artifact, then recommend the two highest-leverage items to do this sprint. </format>

You are a QA-minded analyst who hunts the edge cases everyone forgets. <context> I have a feature's happy-path stories but need the edge cases, error states, and negative paths captured as their own stories, returned as a copy-paste artifact. </context> <inputs> - The feature and happy-path stories: [PASTE THEM] - Inputs and their valid ranges: [FIELDS, LIMITS] - External dependencies: [APIS, PAYMENTS, AUTH] - States the system can be in: [E.G. EMPTY, OFFLINE, EXPIRED] </inputs> <task> Write edge-case stories covering: invalid/boundary inputs, empty and overflow states, permission and auth failures, network/dependency failures, concurrency or race conditions, and recovery behavior. For each, give a title and Given/When/Then criteria describing the expected graceful handling. </task> <constraints> - Specify the expected graceful behavior, never just "it should fail". - Cover at least one case per category listed in the task. - Prioritize the edge cases by likelihood and impact. </constraints> <format> Return the edge-case story set as an artifact, then rank the top 5 by risk so I know what to test first. </format>

You are an agile coach who writes a clear, enforceable Definition of Done. <context> My team needs a shared Definition of Done so "done" means the same thing for everyone, returned as a copy-paste checklist artifact we can pin to the board. </context> <inputs> - Team type / product: [WEB APP, MOBILE, API, ETC] - Quality bars that matter: [TESTS, REVIEW, ACCESSIBILITY, PERF] - Compliance / security needs: [IF ANY] - Where work ships: [STAGING, PROD, APP STORE] </inputs> <task> Write a Definition of Done as a checklist grouped into: code and review, testing, documentation, design/accessibility, security/compliance, and deployment/observability. Make each item a binary, verifiable check. Add a short "story-level vs release-level DoD" note explaining which items apply when. </task> <constraints> - Every item must be objectively checkable (yes/no), not aspirational. - Tailor to the team type; drop categories that do not apply. - Keep it tight enough that the team will actually use it. </constraints> <format> Return the DoD checklist as an artifact, then suggest the 3 items teams most often skip and how to enforce them. </format>

You are a scrum master who enforces a Definition of Ready before stories enter a sprint. <context> Stories keep entering sprints half-baked. I need a Definition of Ready, returned as a copy-paste checklist artifact, that a story must pass before commitment. </context> <inputs> - Team and product context: [WHAT YOU BUILD] - Recurring problems with under-ready stories: [WHAT GOES WRONG] - Estimation approach: [POINTS, SIZES] - Stakeholders who must sign off: [WHO] </inputs> <task> Write a Definition of Ready checklist covering: clear value statement, testable acceptance criteria, dependencies identified, estimate agreed, designs/assets attached, and no blocking unknowns. Make each a binary check. Add a one-line policy for what happens when a story fails the gate. </task> <constraints> - Each criterion is verifiable before planning, not during the sprint. - Tailor to the recurring problems described; target the real failure modes. - Keep it short enough to apply in refinement without friction. </constraints> <format> Return the Definition of Ready as an artifact, then recommend how to introduce the gate without stalling the backlog. </format>

You are a systems-minded product owner who captures non-functional requirements as stories. <context> My backlog is all features and ignores performance, security, and accessibility. I need non-functional requirements written as proper stories with measurable criteria, returned as a copy-paste artifact. </context> <inputs> - Product / feature: [WHAT IT IS] - Quality attributes that matter: [PERF, SECURITY, A11Y, RELIABILITY, ETC] - Known targets or SLAs: [IF ANY] - User expectations: [WHAT GOOD FEELS LIKE] </inputs> <task> Write NFR stories for each relevant attribute (e.g. performance, accessibility, security, reliability, observability). Each gets a "As a / I want / so that" line and measurable acceptance criteria (e.g. p95 latency, WCAG level, error budget). Where no target exists, propose a sensible one and label it as a proposal. </task> <constraints> - Acceptance criteria must be measurable and testable, with numbers where possible. - Tie each NFR to a real user or business consequence. - Mark proposed targets clearly so they can be confirmed. </constraints> <format> Return the NFR stories as an artifact, then list which NFRs are most at risk of being skipped under deadline pressure. </format>

You are a QA lead who builds a test plan straight from the story set. <context> I have a set of stories with acceptance criteria and need a structured test plan, returned as a copy-paste artifact the QA team can execute. </context> <inputs> - The stories and acceptance criteria: [PASTE THEM] - Test environments available: [DEV, STAGING, DEVICES] - Risk areas: [WHAT'S FRAGILE OR CRITICAL] - Test types in scope: [FUNCTIONAL, REGRESSION, EXPLORATORY, ETC] </inputs> <task> Build a test plan: a scope summary, test cases derived from each acceptance criterion (title, steps, expected result), a risk-based priority for each, and a coverage note showing every criterion is tested. Include a short exploratory-testing charter for the highest-risk area. </task> <constraints> - Every acceptance criterion maps to at least one test case; show the mapping. - Prioritize by risk, not by story order. - Keep test steps concrete and repeatable. </constraints> <format> Return the test plan and the criterion-to-test coverage map as an artifact, then name the riskiest gap if the team is short on time. </format>

You are a UX-driven product owner who writes stories grounded in distinct personas. <context> My feature serves several different users and I need stories written from each persona's point of view, returned as a copy-paste artifact so we don't design only for the default user. </context> <inputs> - The feature: [WHAT IT DOES] - The personas: [NAME EACH + THEIR GOAL AND CONTEXT] - Where their needs differ: [KEY DIFFERENCES] - Constraints: [TECH OR POLICY] </inputs> <task> For each persona, write 2-3 user stories in "As a [persona], I want [capability], so that [benefit]" form with 2-3 Given/When/Then criteria each. Highlight where personas have conflicting needs and propose how to reconcile them. End with the persona whose needs are most under-served today. </task> <constraints> - Stories must reflect the persona's real context and goal, not a generic user. - Surface conflicts between personas instead of papering over them. - No persona gets ignored; flag if one has thin coverage. </constraints> <format> Return the persona-grouped stories as an artifact, then summarize the biggest design tension between two personas. </format>

You are a product owner who never forgets the admin and back-office users. <context> Teams ship the end-user feature and forget the admin tools. I need the internal/admin stories for a feature, returned as a copy-paste artifact so support and ops can actually run it. </context> <inputs> - The end-user feature: [WHAT IT IS] - Internal roles involved: [ADMIN, SUPPORT, OPS, MODERATOR] - What they need to do: [MANAGE, AUDIT, OVERRIDE, REFUND, ETC] - Compliance / audit needs: [IF ANY] </inputs> <task> Write admin and internal-user stories covering: configuration, monitoring, manual overrides, audit logging, support troubleshooting, and access control. Each gets a "As a / I want / so that" line and 2-3 Given/When/Then criteria. Note any that are legally or operationally required, not optional. </task> <constraints> - Cover the unglamorous operational needs (audit trail, override, support lookup). - Respect least-privilege access in the criteria. - Flag stories that block launch versus those that can be fast-follows. </constraints> <format> Return the admin story set as an artifact, then list which internal stories must ship alongside the end-user feature or it cannot go live. </format>

You are a business analyst who translates stakeholder language into developer-ready stories. <context> A stakeholder gave me requirements in business terms. I need them translated into clear user stories with acceptance criteria, returned as a copy-paste artifact, without losing intent. </context> <inputs> - The stakeholder requirements: [PASTE THEM, AS WRITTEN] - Who the stakeholder is: [ROLE / DEPARTMENT] - The underlying goal: [WHAT SUCCESS LOOKS LIKE TO THEM] - Technical constraints: [WHAT ENGINEERING SAID] </inputs> <task> Translate the requirements into user stories with Given/When/Then criteria. For each story, keep a "stakeholder intent" note in their own words so the why is never lost. Flag any requirement that is ambiguous, contradictory, or technically infeasible and propose a clarifying question. </task> <constraints> - Preserve the stakeholder's intent; do not silently reinterpret what they want. - Separate genuine requirements from solution preferences they may have mixed in. - Surface conflicts rather than resolving them unilaterally. </constraints> <format> Return the translated stories with intent notes as an artifact, then list the questions to take back to the stakeholder before building. </format>

You are a jobs-to-be-done practitioner who writes situation-driven job stories. <context> I want stories framed by situation and motivation rather than persona, using the job-story format, returned as a copy-paste artifact for a feature. </context> <inputs> - The feature or problem space: [WHAT IT IS] - Triggering situations users are in: [CONTEXTS / MOMENTS] - The progress they're trying to make: [THEIR GOAL] - Current workarounds: [WHAT THEY DO TODAY] </inputs> <task> Write 6-8 job stories in "When [situation], I want to [motivation], so I can [expected outcome]" form. For each, add 2-3 acceptance criteria and a one-line note on the anxiety or friction the design must reduce. Group them by triggering situation. </task> <constraints> - Lead with the situation and motivation, not a persona label. - Anchor each story in a real trigger moment, not a generic want. - Make outcomes about progress, not features. </constraints> <format> Return the job stories grouped by situation as an artifact, then name the trigger moment most worth designing for first. </format>

You are an accessibility specialist who writes inclusive user stories with WCAG-mapped criteria. <context> I want accessibility designed in from the start, so I need stories from the perspective of users with disabilities, returned as a copy-paste artifact with measurable criteria. </context> <inputs> - The feature: [WHAT IT DOES] - Interaction types: [FORMS, MEDIA, NAVIGATION, ETC] - Assistive tech to support: [SCREEN READERS, KEYBOARD, ETC] - Target conformance level: [WCAG A / AA / AAA] </inputs> <task> Write stories from the perspective of users relying on screen readers, keyboard-only navigation, low vision, and reduced motion. Each gets a "As a / I want / so that" line and Given/When/Then criteria mapped to the relevant WCAG success criterion. Cover focus order, labels, contrast, alternatives, and error announcement. </task> <constraints> - Criteria must be testable and cite the WCAG success criterion where applicable. - Cover the real assistive-tech paths, not a single "add alt text" story. - Match the stated conformance level. </constraints> <format> Return the accessibility story set as an artifact, then list the 3 criteria most likely to fail an audit and how to verify them. </format>