click-path-audit
OfficialTrace 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, or after any major refactor touching shared state stores.
What this skill does
When applied, it prepends a system prompt before your request is sent — no extra calls and no change to how you are billed beyond the added tokens.
--- name: click-path-audit description: "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, or after any major refactor touching shared state stores." origin: community --- # /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: ``` 1. IDENTIFY the handler (onClick, onSubmit, onChange, etc.) 2. TRACE every function call in the handler, IN ORDER 3. For EACH function call: a. What state does it READ? b. What state does it WRITE? c. Does it have SIDE EFFECTS on shared state? d. Does it reset/clear any state as a side effect? 4. CHECK: Does any later call UNDO a state change from an earlier call? 5. CHECK: Is the FINAL state what the user expects from the button label? 6. CHECK: Are there race conditions (async calls that resolve in wrong order)? ``` --- ## Execution Steps ### Step 1:
Use this skill
Add a "skill" field with the skill’s ID to your chat completion request. It is applied server-side before your prompt is sent — no extra calls.
{
"model": "gpt-4o-mini",
"skill": "imp-5d9ead78-4201-47cc-802d-19b11da8c320",
"messages": [{ "role": "user", "content": "…" }]
}Install the skill, enable it in your dashboard and (optionally) limit it to specific models. It then applies automatically to every matching request — with no "skill" field to send each time.
Set it up in your dashboardMore skills
Set up and use 1Password CLI for sign-in, desktop integration, and reading or injecting secrets.
Create, view, edit, delete, search, move, or export Apple Notes via the memo CLI on macOS.
List, add, edit, complete, or delete Apple Reminders and reminder lists via remindctl.
Create, search, and manage Bear notes via grizzly CLI.
Monitor blogs and RSS/Atom feeds for updates using the blogwatcher CLI.
BluOS CLI (blu) for discovery, playback, grouping, and volume.
Capture frames or clips from RTSP/ONVIF cameras.
Search, install, update, sync, or publish agent skills with the ClawHub CLI and registry.