Spec prompts

I'm going to describe a feature. Write acceptance criteria as a numbered list, where every single criterion is something a QA tester could concretely fail: it names a specific input, a specific expected output, and where relevant a measurable threshold (a time limit, a count, an error rate).

Do not write a criterion using words like "should feel," "intuitive," "smooth," or "graceful" unless you immediately follow it with the concrete, testable condition that word is standing in for. If you can't make a criterion concrete, flag it as a question for me rather than writing a vague version.

Feature: [describe the feature]

Here is a PRD's problem statement and proposed solution. Based on how similar features usually expand during a build, list 5 to 8 specific adjacent things someone on the team might reasonably assume are included, but that are not explicitly stated as in scope.

For each one, phrase it as a non-goal statement I could add directly to the document, for example "Out of scope: [specific thing], because [one clause reason]." Prioritise the ones most likely to come up in the first engineering review meeting, not the most exotic edge cases.

Problem and solution: [paste your PRD's problem and solution sections]

Below is a Slack thread where a product decision was worked out in conversation. Turn it into a first draft one page PRD with four sections: Problem (with any evidence mentioned in the thread), Solution and non-goals, Acceptance criteria, Rollout and risk.

Only include claims that are actually supported by something said in the thread. Where the thread doesn't settle a question needed for one of these sections, write "OPEN QUESTION:" followed by what needs deciding, instead of inventing an answer.

Thread:
[paste the Slack thread]

Here is a feature spec that describes the intended, working behaviour. List the edge cases and failure states it doesn't address: empty input, a duplicate submission, a slow or failed network call, a user who does the steps out of order, and a user who already has the end state this feature is meant to create.

For each edge case, propose the specific behaviour rather than just naming that it's missing, so it can be added directly to the acceptance criteria.

Spec: [paste your spec]

Turn this spec's acceptance criteria into a QA test plan. For each criterion, write: the exact steps to reproduce, the expected result, and one variant of the input that's likely to break it if the implementation is subtly wrong (a boundary value, an unusual but valid input, a repeat of the same action).

Format as a table: Test ID, Steps, Expected result, Notes. Do not write a test that just restates the acceptance criterion as a question; write the actual steps a person would follow with the actual product.

Spec: [paste your acceptance criteria]

Here is a feature spec. Without giving me a time estimate (you don't know our codebase), identify which parts of this spec are likely to be the most expensive to build, based on common patterns: anything touching data migration, anything requiring a new third party integration, anything with a real-time or performance requirement, and anything that changes an existing, already-shipped flow rather than being purely additive.

For each expensive-looking part, suggest a smaller first version that would let us ship and learn before committing to the full scope.

Spec: [paste your spec]