← Teljes munkafolyamat adatlapja
Nézd meg, miben segít
Követelmények és elfogadás felülvizsgálata
Megvizsgálja, teljes felhasználói útra világos, következetes és tesztelhető elvárás vonatkozik-e.
requirements-acceptance-review
Ezt a skillt használó ügynökök
Mikor hasznos?
Akkor használd, ha hiba, jogosultság vagy helyreállás nincs pontosan leírva.
Miben segít neked?
- Feltérképezi az előfeltételt, műveletet, állapotot és következményt.
- Hiányzó feltételt keres üres adatra, párhuzamos szerkesztésre és ismétlésre.
- Elkülöníti a döntetlen kérdést az igazolt hibától.
Például ezt kérheted
Nézd át a meghívást létrehozástól elfogadásig, lejárt linkkel, visszavont joggal és ismételt meghívóval. Nyitott oldalon járjon le a meghívó. Az elfogadott elutasítási szabály különüljön el az újraküldés és kitöltött adatok megőrzésének nyitott kérdésétől.
Részletes dokumentáció
Itt a skill eredeti útmutatóját, példáit és ellenőrzési szempontjait olvashatod az eredeti nyelven.
Összecsukás
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.
Csomagban lévő fájlok 1
SKILL.md
