review-requirements

<skill_overview> Ensure that the task or requirement definition is clear, complete, and actionable before or during implementation. User asks to review a task description or ticket. User provides a requirements document for a code review. Analyzing a PR description against the implemented code. </skill_overview>

<checklist_requirements_quality> Clarity: Is the goal of the task unambiguous? Can it be interpreted in multiple ways? Acceptance Criteria: Are there clear "Definition of Done" criteria? (Given/When/Then is preferred). Scope Boundaries: Is it clear what is IN scope and what is OUT of scope? Context: Is the "Why" (user value/business goal) explained? Technical Feasibility: Are there obvious technical blockers or missing dependencies mentioned? Edge Cases: Does the task consider error states, empty states, or boundary conditions? </checklist_requirements_quality>

<analysis_workflow> Identify the core user value/problem statement. Check for missing information (e.g., designs, API specs, error handling behavior). Identify potential contradictions or logical gaps. Suggest specific improvements or clarifying questions. </analysis_workflow>

<implementation_verification> When reviewing code against a task: Does the code cover ALL acceptance criteria? Does the code handle the edge cases mentioned in the task? Did the implementation drift from the original requirement? (Scope creep or missing features). </implementation_verification>

<common_gaps> "Happy Path" Bias: Task only describes what happens when everything goes right. Vague Terms: Using words like "fast", "better", "user-friendly" without metrics. Missing UI/UX: "Add a button" without stating where, what it looks like, or loading states. Data Migration: Forgetting about existing data when changing schemas. </common_gaps>