06-harden-a-feature-as-a-project-test-via-ui-then-fix-looplisted

Trigger when the user says to treat a feature as a PROJECT and harden it - phrasings like make X a project, test X fully via the UI and fix, loop on X until I stop you, or points at a specific surface (the taskboard, the calendar, the OP directory) and asks to make it just work. This is the DRIVE-THE-REAL-UI-THEN-FIX loop: for a project you exercise every function through the real browser against the live app, watch what actually happens (network, console, DB side effects), and when something is broken or clunky you fix it, redeploy, and re-test - repeating until the surface works end to end hands-free. It pairs the browser as source of truth with the deploy engine and the DB inspector. Not for a one-shot bug fix - this is sustained looped hardening of a whole feature.
markkennethbadilla/public-agent-provisioning · ★ 0 · AI & Automation · score 72

Install: claude install-skill markkennethbadilla/public-agent-provisioning

# Harden A Feature As A Project: Test-Via-UI-Then-Fix Loop **Why (2026-07-22):** A feature is not done because the code compiles or a gate is green - it is done when a real person can drive it through the browser and it just works, hands-free, with no surprise. So for a PROJECT (a whole surface, not a single bug) the unit of work is a loop: exercise it in the real UI, observe the truth, fix what is actually broken, redeploy, exercise again. The browser is the oracle; reasoning from code is never a substitute (rules 11a, 14). ## When this fires - The user says make X a project / test X fully via UI and fix / loop on X / make X just work hands-free. - A named surface is handed to you to harden (the taskboard, the meeting workspace, onboarding). - NOT a one-shot fix. This is sustained hardening until the surface is solid or the user interrupts. ## The loop (repeat until solid or interrupted) 1. **Record it as a project.** Create/refresh a row in the projects table (title plus body describing the hardening goal) so the effort is tracked. File the concrete defects you find as dev-tickets under that project. 2. **Map intended behavior first.** Read the feature code (jcodemunch) enough to know what SHOULD happen - the trigger, the data flow, the side effects - so you can tell broken from working. Write the expected outcome of each action BEFORE you test it (separate looking from making, rule 14f). 3. **Drive the real UI (chrome-devtools).** Against the LIVE app, do ea