click-path-audit
Lets your agent trace all user buttons and interactions to find bugs. It finds issues where functions seem to work alone but fail together. Useful when bugs persist even after debugging.
What it does
This tool helps find bugs in buttons and other on-screen interactions that aren't caught by common debugging methods. It checks if a button's action leads to the expected outcome in the interface, even if individual parts work.
When to use it
- ✓When buttons don't work as expected, but normal debugging finds no issues.
- ✓After major code changes that affect how data is managed.
- ✓To ensure user interactions result in the correct final UI state.
Example of what to ask your AI
“Audit all buttons on the user profile page to ensure they work correctly and don't conflict with each other.”
Want more? Open the sections below.
How to use
The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.
Skill link
Ready-to-paste message
How it works
The tool analyzes every click or interaction, tracing all state changes that occur. It checks if one action undoes another or if the final result doesn't match what the button promised.
Installation
Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.
In the terminal (Claude Code, Codex, Cursor), in your project folder:
npx skills add affaan-m/ECC --skill click-path-auditOr download just the file:
curl -L https://raw.githubusercontent.com/affaan-m/ECC/main/pi/core/skills/click-path-audit/SKILL.md -o SKILL.mdTechnical content (original SKILL.md)
Original text by the author, straight from GitHub.
/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: Map State Stores
Before auditing any touchpoint, build a side-effect map of every state store action:
For each Zustand store / React context in scope:
For each action/setter:
- What fields does it set?
- Does it RESET other fields as a side effect?
- Document: actionName → {sets: [...], resets: [...]}
This is the critical reference. The "New Email" bug was invisible without knowing that selectThread resets composeMode.
Output format:
STORE: emailStore
setComposeMode(bool) → sets: {composeMode}
selectThread(thread|null) → sets: {selectedThread, selectedThreadId, messages, drafts, selectedDraft, summary} RESETS: {composeMode: false, composeData: null, redraftOpen: false}
setDraftGenerating(bool) → sets: {draftGenerating}
...
DANGEROUS RESETS (actions that clear state they don't own):
selectThread → resets composeMode (owned by setComposeMode)
reset → resets everything
Step 2: Audit Each Touchpoint
For each button/toggle/form submit in the target area:
TOUCHPOINT: [Button label] in [Component:line]
HANDLER: onClick → {
call 1: functionA() → sets {X: true}
call 2: functionB() → sets {Y: null} RESETS {X: false} ← CONFLICT
}
EXPECTED: User sees [description of what button label promises]
ACTUAL: X is false because functionB reset it
VERDICT: BUG — [description]
Check each of these bug patterns:
Pattern 1: Sequential Undo
handler() {
setState_A(true) // sets X = true
setState_B(null) // side effect: resets X = false
}
// Result: X is false. First call was pointless.
Pattern 2: Async Race
handler() {
fetchA().then(() => setState({ loading: false }))
fetchB().then(() => setState({ loading: true }))
}
// Result: final loading state depends on which resolves first
Pattern 3: Stale Closure
const [count, setCount] = useState(0)
const handler = useCallback(() => {
setCount(count + 1) // captures stale count
setCount(count + 1) // same stale count — increments by 1, not 2
}, [count])
Pattern 4: Missing State Transition
// Button says "Save" but handler only validates, never actually saves
// Button says "Delete" but handler sets a flag without calling the API
// Button says "Send" but the API endpoint is removed/broken
Pattern 5: Conditional Dead Path
handler() {
if (someState) { // someState is ALWAYS false at this point
doTheActualThing() // never reached
}
}
Pattern 6: useEffect Interference
// Button sets stateX = true
// A useEffect watches stateX and resets it to false
// User sees nothing happen
Step 3: Report
For each bug found:
CLICK-PATH-NNN: [severity: CRITICAL/HIGH/MEDIUM/LOW]
Touchpoint: [Button label] in [file:line]
Pattern: [Sequential Undo / Async Race / Stale Closure / Missing Transition / Dead Path / useEffect Interference]
…
FAQ
What are 'side effects' in state?
These are changes to parts of the system that aren't the direct goal of the action. For example, clicking 'new email' should open an editor, but an unexpected side effect closes the editor.
What are 'race conditions'?
This happens when two actions occur almost simultaneously, and the order in which they finish affects the final outcome, leading to an unexpected state.
Does this replace traditional debugging?
No, it complements it. Traditional debugging checks if the code exists and doesn't crash. This tool focuses on how user interactions affect the final UI state.
Details
Original description by the author
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.
repo: affaan-m/ECC
Popularity
- GitHub stars
- 280k
- Ranking position
- #22
- License
- MIT
- Updated
- 10/15/2026
Comments
- …
More skills from this repository
accessibility
Helps your agent create interfaces that everyone can use. Ensures websites and apps work well for people with disabilities, like those who are blind or have reduced mobility.
affaan-m/ECC
agent-architecture-audit
Makes your agent check if everything is working correctly. It finds and fixes problems in AI systems, ensuring they perform as expected.
affaan-m/ECC
agent-eval
Helps your agent compare different AI coding tools. It measures which one is faster, cheaper, and more reliable for specific tasks.
affaan-m/ECC
agent-harness-construction
Makes your agent better understand how to perform tasks. It optimizes the tools and instructions the agent uses to increase its chances of success.
affaan-m/ECC
Similar skills
karpathy-guidelines
Helps your agent write better code by avoiding common mistakes. It's useful for ensuring code is simple, clear, and easy to verify.
multica-ai/andrej-karpathy-skills
skill-creator
Lets the agent create, modify, and optimize skills. Useful for testing skill performance and improving their accuracy.
anthropics/skills
ponytail-debt
Lists all code shortcuts ('shortcut:') left for later. It helps to see what still needs to be fixed in the project.
DietrichGebert/ponytail