gsd-task-manager: Skill for Claude Code

verify-frontend-change

Confirm a frontend change does what it's supposed to in the running app, not just in your head. The output is a PASS/FAIL verdict backed by evidence — never a confident guess.

This skill exists because two traps in this codebase silently turn verification into theater:

1. The service worker serves stale JS chunks. You edit border-l-4 → border, reload, and still see the old UI. Your screenshot "confirms" code that isn't running.
2. Data surfaces render empty on a fresh load. The dashboard and matrix have nothing to show until tasks exist. A screenshot of an empty dashboard "confirms" a layout you never actually saw.

Either trap produces a false PASS — the most dangerous outcome, because it ends the investigation with the wrong answer. Everything below is built to make PASS mean something.

Right-size the effort. The verification is the observation of the running change — the rendered result, the click working, the console staying clean. Static checks (typecheck, the unit suite) are a cheap precondition, not the verification, and they don't need to balloon: run the few that bear on this change, not the whole app. A CSS spacing tweak doesn't warrant the full test suite or a fresh Playwright run; it warrants eyes on the rendered card. Spending twenty minutes on static analysis to avoid two minutes of looking is the over-engineering this skill is meant to replace.

When to use

Use this after editing any .tsx/.jsx under components/ or app/, or any change that affects what the user sees or does — the matrix, capture bar, edit drawer, dashboard, settings, task cards. Reach for it before pushing or opening a PR on UI work.

Don't use it for backend/sync-only logic (lib/sync/**), pure data transforms with unit-test coverage, or styling-only token tweaks already covered by inkwell-retrofit — those have better-fit verification.

Default dimensions

Verify these two by default — they catch the most regressions per unit of effort: