SKILL.md
Default output: return only the result, blockers, and required evidence. Omit preambles, process narration, repeated context, confidence scores, and follow-up offers. Use at most five bullets unless a required artifact or schema needs more.
Browser Testing with DevTools
Overview
Use browser DevTools to verify runtime behavior, debug issues, and measure performance. DevTools provides ground truth that code review and unit tests cannot.
When to Use
- Verifying that a UI component renders correctly
- Debugging layout, styling, or interaction issues
- Measuring page load performance
- Inspecting network requests and responses
- Profiling JavaScript execution
DevTools Capabilities
Elements Panel
- Inspect DOM structure
- Verify CSS properties and computed styles
- Check accessibility properties
- Debug layout issues (box model, flex, grid)
Console Panel
- View runtime errors and warnings
- Execute debugging expressions
- Monitor custom log output
- Check network-related errors
Network Panel
- Inspect HTTP requests and responses
- Verify request headers, payloads, and status codes
- Check timing and waterfall for performance
- Identify unnecessary or failed requests
Performance Panel
- Record and analyze runtime performance
- Identify long tasks blocking the main thread
- Check rendering performance (layout thrash, paint storms)
- Profile memory usage and leaks
Application Panel
- Inspect localStorage, sessionStorage, cookies
- Verify service worker status
- Check indexedDB contents
- Review cached resources
Process
Step 1: Open DevTools
- Chrome: F12 or Cmd+Option+I
- Navigate to the relevant panel for the task
Step 2: Reproduce the Scenario
- Navigate to the affected page or component
- Trigger the user action that needs verification
- Observe the result in the relevant panel
Step 3: Collect Evidence
- Screenshots of rendering issues
- Console output for errors and warnings
- Network requests for API-related issues
- Performance traces for speed issues
Step 4: Analyze and Fix
- Identify the root cause from the evidence
- Make the fix
- Verify the fix in DevTools
- Document the issue and resolution
Common Rationalizations
| Rationalization | Reality |
|---|---|
| "It looks fine in the code" | Code can look correct and still render incorrectly due to CSS specificity, browser bugs, or dynamic state. |
| "Unit tests cover this" | Unit tests cannot catch rendering issues, layout bugs, or network timing problems. |
| "DevTools is too slow to use regularly" | A 30-second DevTools check catches issues that take hours to debug later. |
Verification
- Component renders correctly in the browser
- No console errors or warnings
- Network requests succeed with correct payloads
- Performance meets acceptable thresholds
- Accessibility properties are correct in the DOM
Anti-Rationalization Table
| Excuse | Counter |
|---|---|
| "It looks fine in the code" | Code can be correct and still render incorrectly due to CSS, browser bugs, or dynamic state. |
| "Unit tests cover this" | Unit tests cannot catch rendering issues, layout bugs, or network timing problems. |
| "DevTools is too slow to use regularly" | A 30-second DevTools check catches issues that take hours to debug later. |
| "I'll test it in production" | Production is not a testing environment. Catch issues before users do. |
| "The performance numbers look good on my machine" | Your machine is not your users' machine. Profile on realistic hardware and network conditions. |