← Back to Mobile app developers
See how it helps
Requirements and acceptance review
Checks whether a complete user journey has clear, consistent and testable expected behavior.
requirements-acceptance-review
Team members using this skill
When is it useful?
Use when a specification or implementation leaves uncertainty about errors, permissions or recovery.
What does it help you do?
- Maps preconditions, actions, state changes, feedback and downstream effects.
- Finds missing criteria for empty data, concurrent edits and safe retries.
- Separates unspecified decisions from proven implementation defects.
Try asking this
Review our invitation feature from creation through acceptance, including expired links, revoked access and duplicate invitations. Walk through an invitation that expires while its page is open. Separate the agreed rejection behavior from any unresolved question about resending or preserving entered details.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Requirements & Acceptance Review
Use this skill when reviewing specifications, task briefs, designs, or implementations to verify that expected user-visible behavior is complete, unambiguous, and testable across the entire workflow.
Workflow
- Map the complete end-to-end user journey:
- Trace the feature from start to finish rather than inspecting isolated screens or endpoints:
- Preconditions: Required account state, workspace context, permissions, feature flags, and initial data.
- Inputs & actions: What the user or caller submits, selects, or triggers.
- State transitions: What changes in the database, UI state, URL, or background jobs.
- Feedback & recovery: Loading states, success confirmation, validation messages, and how the user recovers when an error occurs (Don Norman's Gulf of Evaluation & Execution).
- Side effects: Notifications, audit logs, webhooks, cache invalidation, or downstream counters.
- Trace the feature from start to finish rather than inspecting isolated screens or endpoints:
- Surface missing and contradictory acceptance criteria:
- Check existing project documentation and accepted decisions first before raising a question.
- Look for classic specification gaps:
- What happens when the list is empty, has 1 item, or has 10,000 items?
- What happens if a collaborator edits or deletes the record while the user has the form open?
- Can the action be cancelled, undone, or retried safely?
- Which roles are forbidden from seeing or performing the action?
- Separate requirement gaps from implementation bugs:
- Proven implementation defect: The specification or established system contract clearly states behavior $X$, and the code does $Y$.
- Open requirement question: The brief never specified what should happen in scenario $Z$. Report this as a concise Requirement Clarification Needed item for the product analyst rather than inventing a personal rule and grading it as a bug.
Anti-Patterns to Avoid
- Rewriting requirements to match broken code: Never weaken an acceptance criterion just so an incomplete implementation passes review.
- Treating personal aesthetic preferences as functional defects: Anchor every finding to user task success, documented specifications, or system invariants.
Included files 1
SKILL.md