1. Capture the failure before changing CSS
Write down the route, viewport width, device pixel ratio if relevant, content that clips, and the expected relationship between the elements. A screenshot is useful evidence, but include the text or control that is actually failing so another person can reproduce it.
Keep the first run read-only when possible. Do not mix a mobile spacing fix with a redesign, copy rewrite, or dependency update; a small boundary makes the cause and the rollback visible.
- The failing route and viewport are named.
- The clipped, overflowing, or uneven element is identified.
- The expected outcome is written in one sentence.
- The starting screenshot or reproduction note is preserved.
2. Assign one Skill to each question
frontend-design is useful when the interface needs a coherent visual direction, but it is not a mobile regression test. web-design-reviewer is a better fit for comparing rendered layouts across breakpoints and tracing a visible defect back to source. webapp-testing belongs when the fix could change a real user flow or needs browser logs and repeatable assertions.
Choose the smallest role that can answer the question. Installing three Skills for a one-line overflow bug creates more permission and output to review without improving the diagnosis.
3. Recheck three representative widths
After the smallest fix, check the reported phone width, one narrow intermediate width, and a desktop width that was previously healthy. Look for text clipping, horizontal overflow, collapsed controls, inconsistent gaps, and a primary action that has moved below the usable area.
Compare like with like: same route, same content, same browser state, and the same acceptance sentence. If a change improves one width but breaks another, record the tradeoff rather than calling the run a pass.
- The original mobile failure is gone.
- No horizontal scroll or clipped text appears at the intermediate width.
- The desktop baseline remains intact.
- The primary action is usable with keyboard and pointer input.
4. Know what a passing screenshot does not prove
A screenshot shows one rendered state. It does not prove screen-reader semantics, focus order, contrast in every state, loading behavior, performance, or compatibility with every browser. Keep those claims out of the article unless the corresponding check was actually run.
The strongest page-level evidence is a before/after pair, the exact change boundary, and a short acceptance record. That is more useful to a future maintainer than a generic statement that the page is now responsive.