click-path-audit
Trace every user-facing button/touchpoint through its full state change sequence to find bugs where functions individually work but cancel each other out, produce wrong final state, or leave the UI in an inconsistent state. Use when: systematic debugging found no bugs but users report broken buttons
By affaan-m · 2,833 installs
npx skills add affaan-m/ecc --skill click-path-audit
Source repository · Upstream listing
/click path audit — Behavioural Flow Audit
Find bugs that static code reading misses: state interaction side effects, race conditions between sequential calls, and handlers that silently undo each other.
The Problem This Solves
Traditional debugging checks:
Does the function exist? (missing wiring)
Does it crash? (runtime errors)
Does it return the right type? (data flow)
But it does NOT check:
Does the final UI state match what the button label promises?
Does function B silently undo what function A just did?
Does shared state (Zustand/Redux/context) have side effects that cancel the intended action?
Real example: A "New Email" button called setComposeMode(true) then selectThread(null) . Both worked individually. But selectThread had a side effect resetting composeMode: false . The button did nothing. 54 bugs were found by systematic debugging — this one was missed.
How It Works
For EVERY interactive touchpoint in the target area:
Execution Steps
Step 1: Map State Stores
Before auditing any touchpoint, build a side effect map of every state store action:
This is the critical reference. The "New Email" bug was invisible without knowing that selectThread resets composeMode .
Output format:
Step 2: Audit Each Touchpoint
For each button/toggle/form submit in the target area:
Check each of these bug patterns:
Pattern 1: Sequential Undo
Pattern 2: Async Race
Pattern 3: Stale Closure
Pattern 4: Missing State Transition
Pattern 5: Conditional Dead Path
Pattern 6: useEffect Interference
Step 3: Report
For each bug found:
Scope Control
This audit is expensive. Scope it appropriately:
Full app audit: Use when launching or after major refactor. Launch parallel agents per page.
Single page audit: Use after building a new page or after a user reports a broken button.
Store focused audit: Use after modifying a Zustand store — audit all consumers of the changed actions.
Recommended agent split for full app:
Agent 1 MUST complete first. Its output is input for all other agents.
When to Use
After systematic debugging finds "no bugs" but users report broken UI
After modifying any Zustand store action (check all callers)
After any refactor that touches shared state
Before release, on critical user flows
When a button "does nothing" — this is THE tool for that
When NOT to Use
For API level bugs (wrong response shape, missing endpoint) — use systematic debugging
For styling/layout issues — visual inspection
For performance issues — profiling tools
Integration with Other Skills
Run AFTER /superpowers:systematic debugging (which finds the other 54 bug types)
Run BEFORE /superpowers:verification before completion (which verifies fixes work)
Feeds into /superpowers:test driven development — every bug found here should get a test
Example: The Bug That Inspired This Skill
ThreadList.tsx "New Email" button:
Store definition:
Systematic debugging missed it because:
The button has an onClick handler (not dead)
Both functions exist (no missing wiring)
Neither function crashes (no runtime error)
The data types are correct (no type mismatch)
Click path audit catches it because:
Step 1 maps selectThread resets composeMode
Step 2 traces the handler: call 1 sets true, call 2 resets false
Verdict: Sequential Undo — final state contradicts button intent