Write Negative Acceptance Criteria
Generates explicit 'what should NOT happen' acceptance criteria to prevent scope creep and surface hidden assumptions. Built for PMs whose stories keep growing during implementation.
When to use this prompt
Use this when a user story has well-defined positive criteria but engineers keep asking about related behaviors during implementation. Negative criteria shut down scope creep by naming it out loud. You will need the user story, the positive acceptance criteria, and a rough sense of what related features exist. This prompt is most valuable in mature products where every new feature has dozens of adjacent behaviors that could be accidentally changed. It is less useful in greenfield work with little surrounding state.
The Prompt
You are a product manager writing negative acceptance criteria for a user story. Your job is to make explicit what the story should NOT do, so that scope creep is prevented and hidden assumptions are surfaced. User story: {{user_story}} Positive acceptance criteria: {{positive_criteria}} Adjacent features: {{adjacent_features}} Produce three sections of negative criteria: 1. OUT OF SCOPE â Features or behaviors explicitly NOT part of this story. Each as a sentence starting with "This story does NOT...". Cover related features that might be confused with this one. 2. STATE INVARIANTS â System state that must NOT change as a result of this story. For example: "User preferences in other modules must not reset" or "Billing history must not be modified." 3. GUARDRAILS â Things users should NOT be able to do, even accidentally. Think about privilege escalation, data access, and destructive actions. For each item, add a 1-line rationale explaining why the exclusion matters. If any negative criterion is in tension with a positive criterion, flag it and ask for clarification. End with a "FUTURE SCOPE" list: features that are out of scope now but are good candidates for a follow-up story, so the work is not lost.
Example Output
OUT OF SCOPE - This story does NOT add bulk approval; only single-record approval. Rationale: bulk mode adds permission complexity worth a separate story. - This story does NOT email the requester on approval. Rationale: notification policy is handled by a separate subsystem. - This story does NOT modify the audit log format. Rationale: log schema changes require SRE signoff. STATE INVARIANTS - Approval status MUST NOT cascade to related records. Rationale: each record is independently governed. - User session state MUST NOT be extended by the approval action. Rationale: prevents privilege escalation via hold-open sessions. - Other pending approvals MUST NOT be auto-rejected. Rationale: each decision is independent. GUARDRAILS - Users MUST NOT approve their own records. Rationale: separation of duties, compliance requirement. - Users MUST NOT see records from other tenants. Rationale: hard isolation boundary, never relaxed. - Users MUST NOT be able to delete an approval decision. Rationale: auditability requires immutable history. FUTURE SCOPE - Bulk approval workflow (separate story) - Delegated approval for vacation coverage - Email notifications on approval status change
Recommended Tools
Jira and Linear both render negative criteria inline with positive criteria in the same story description, which keeps engineers from hunting across documents. ClickUp supports the explicit "out of scope" section as a subtask list that cannot be checked off, serving as a visible reminder during implementation. All three support the future scope section as linked items for later pickup.
Frequently Asked Questions
When should I use this prompt?
Use it whenever a story touches an area of the product with many adjacent features, or when past stories in the same area have consistently grown during implementation. It is especially valuable in regulated or enterprise products where scope creep has compliance implications. Skip it for greenfield stories with no adjacent state; the out-of-scope list will be empty. Also skip for trivial UI tweaks where there is nothing to invariantly protect.
Will negative criteria slow down my team?
Counterintuitively, no. Negative criteria usually speed up implementation because they resolve the ambiguous edge questions engineers would otherwise have to ask during standup. The 15 minutes spent writing them saves hours of mid-sprint clarification. The risk is over-specifying and making the story feel like a lawyer's contract, so aim for 5-10 negative criteria total. If the list grows past 15, the underlying story is probably too large and should be split first.