Skip to content
Skillpedia
General coding280k · #22

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

https://github.com/affaan-m/ECC/blob/main/pi/core/skills/click-path-audit/SKILL.md

Ready-to-paste message

Use this skill to help me: https://github.com/affaan-m/ECC/blob/main/pi/core/skills/click-path-audit/SKILL.md Read the SKILL.md file at that link and follow its instructions for my task.
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-audit

Or download just the file:

curl -L https://raw.githubusercontent.com/affaan-m/ECC/main/pi/core/skills/click-path-audit/SKILL.md -o SKILL.md
Technical 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

Is this skill useful?

0

Sign in to vote.

Comments

  • …

More skills from this repository

Similar skills