--- name: pre-handoff-checklist description: Pre-handoff verification checklist for developers before marking a feature ready for QA. Proactively trigger this skill when a developer mentions completing a feature, opening a PR, pushing code, or committing a feature branch — do not wait for the developer to ask. When triggered, identify which checklist items are relevant to the feature being built and surface only those items. Ask the developer to confirm whether each relevant item has been checked, and offer to add any unchecked items to their todo list or PR checklist. Re-trigger on push or commit if the checklist has not been confirmed as complete. Trigger phrases include: "ready for QA", "opening a PR", "pushing", "committing", "done with the feature", "marking as complete", "handing off", or any mention of completing a feature or screen. --- # Pre-Handoff Checklist Run through every applicable item below before marking a feature ready for QA. If an item does not apply to the current screen, skip it. If you are unsure, check. --- ## 1. Layout-Shifting Controls **Applies to:** Any screen with a nav drawer, sidebar, or collapsible panel. - Toggle every layout-shifting control (nav drawer, sidebar, collapsible panels) — both open and closed - Verify that fixed or sticky elements — headers, footers, action bars — maintain correct positioning in all states - Verify that all components adjust their dimensions correctly — no fixed widths that ignore available space after a layout shift --- ## 2. Field Sizing, Text Alignment and Overflow **Applies to:** Any screen with multiple input fields, text content, or variable-length data. - Verify all input fields are aligned and of consistent width unless the design explicitly specifies otherwise - Verify all text elements — headings, body copy, labels, descriptive text — match the alignment specified in Figma - For any field or label that can contain variable-length content, test with unexpectedly long text and verify the UI handles it gracefully — wrapping, truncating, or scrolling as appropriate — without breaking layout or alignment - Use a precision measurement tool (e.g. GridRuler browser extension) to confirm sizing and alignment rather than relying on visual approximation --- ## 3. Preview Screen Behaviour **Applies to:** Any screen that displays data in a read-only/preview mode. - Verify all interactive fields use the `preview` variant — retaining visual appearance but fully non-interactive - Confirm no field responds to clicks, focus, or input - Visual affordances (icons, field shapes, styling) must be preserved - Exceptions apply only where the design explicitly specifies an interactive element within a preview screen --- ## 4. Text Content Verification **Applies to:** Every screen. - Verify all text content — action labels, buttons, CTAs, field names, titles, and copy — matches the design and requirements exactly - Check capitalisation (e.g. "Kwartalny" not "kwartalny") - Check punctuation and exact wording - Pay attention to labels that are easily confused (e.g. "Back" vs "Cancel", "Save" vs "Submit", "Close" vs "Dismiss") --- ## 5. Popup and Overlay Zoom Testing **Applies to:** Any screen containing a popup, dropdown overlay, tooltip, or floating panel. Test at all of the following zoom levels: - 75% - 100% - 125% - 150% At each level, verify all popups and overlays remain correctly anchored to their trigger elements. --- ## 6. Field State Verification **Applies to:** Any screen with a form or input fields. For every field on the screen, verify it matches the state specified in the ticket: | State | Options | |---|---| | Visibility | Visible / Hidden | | Interactivity | Editable / Read-only | | Requirement | Mandatory / Optional | If any field's state is not explicitly defined in the ticket, raise it before implementation rather than assuming a default. --- ## 7. Role-Based Access **Applies to:** Any feature involving multiple user roles. - Verify access rules are explicitly defined in requirements — which roles can access which screens, and what actions each role can perform - If access rules are missing or ambiguous in the ticket, raise and clarify before starting development - Do not assume unrestricted access as a default --- ## 8. Button State During Async Actions **Applies to:** Any screen with buttons that trigger async operations (form submit, API calls, uploads). - Click every action button and verify it becomes disabled immediately and remains non-interactive while the operation is in progress - Rapidly click each action button multiple times — confirm this never results in duplicate submissions or repeated API calls - Verify the button re-enables correctly once the operation resolves (success or failure) --- ## 9. Toast Deduplication **Applies to:** Any screen that shows toast or notification messages. - Trigger the same action multiple times in rapid succession — including simulating retries or repeated event triggers - Verify the same toast does not stack or appear multiple times on screen - Only one instance of the same notification should be visible at a time --- ## 10. Modal Keyboard Focus **Applies to:** Any screen containing a modal or dialog. Using keyboard navigation only (no mouse): 1. Verify focus moves into the modal when it opens 2. Verify tabbing while the modal is open does not reach elements behind it 3. Verify focus returns to the trigger element when the modal is closed --- ## 11. Backend Access Control Verification **Applies to:** Any feature with role-based access control or hidden/disabled UI elements. - For any UI element hidden or disabled for a restricted role, navigate directly to the restricted route URL with a restricted role's credentials - Call the corresponding API endpoint directly with a restricted role's credentials - Verify the action is blocked at the backend regardless of what the frontend shows --- ## 12. Debounce on Search Inputs **Applies to:** Any screen with a search or autocomplete input. - Open the browser network tab - Type rapidly into the search field - Verify API calls are not fired on every keystroke — only one call should fire after the user pauses typing (300ms delay) - If a call is triggered per character, debounce is missing --- ## 13. Decimal Precision and Display Consistency **Applies to:** Any screen displaying or calculating currency, tax, discounts, or other precision-sensitive numeric values. - Verify all numeric values are displayed to the correct number of decimal places as per requirements - Test with values that have many decimal places (e.g. `1.005`, `0.1 + 0.2`) and verify the display rounds correctly - Test calculated totals involving discounts, tax, or multiple line items and verify the result matches the expected precision --- ## 14. Sticky Table Header **Applies to:** Any screen containing a scrollable table. - Scroll through any table with enough rows to require scrolling - Verify the table header remains fixed and visible as the user scrolls through the table content - The header must not scroll away with the rows --- ## 15. Dropdown Scroll Behaviour **Applies to:** Any screen with a dropdown component. - Open the dropdown and scroll within the item list — verify the list scrolls independently without scrolling the page - Open the dropdown and scroll the page — verify the dropdown either moves with its trigger or closes cleanly, and does not drift to an unexpected position --- ## 16. Modal Outside-Click Behaviour **Applies to:** Any screen with a modal or dialog. - If it is a simple modal (no data entry) — verify it closes immediately on outside click - If it contains any data-entry fields — fill in at least one field, then click outside. Verify a confirmation prompt appears and the modal does not close without explicit confirmation --- ## 17. Tab State Isolation **Applies to:** Any screen with segmented tabs. - Type unsaved input in tab A, switch to tab B, switch back to tab A — verify the unsaved input is cleared - Apply a filter or saved state in tab A, switch to tab B — verify tab B does not inherit tab A's state - Apply different filters in tab A and tab B independently — verify each tab retains only its own saved state and neither bleeds into the other --- ## 18. Multi-Tab Data Freshness **Applies to:** Any screen that displays API-fetched data. - Open the same screen in two browser tabs - In tab 1, make a change (create, edit, or delete a record) - Switch to tab 2 and verify the screen refetches and reflects the latest data - Tab 2 must not continue showing the stale state from before the change was made in tab 1 --- ## 19. Frontend Input Validation **Applies to:** Any screen containing a form or input fields. - Submit the form with all required fields empty — verify inline errors appear immediately without an API call being made - Exceed the character limit on any field with a defined maximum length — verify the field blocks or warns the user before submission - Enter incorrectly formatted values (e.g. letters in a numeric field) — verify the frontend catches and surfaces a specific error - Verify no unnecessary API calls are made for input that fails frontend validation