Click Path Audit

by affaan-mef648e01899bNo license275K starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated 3 days ago

ユーザー向けボタン/タッチポイントを完全な状態変更シーケンスを通して追跡し、機能が個別に機能するが互いにキャンセルされたり、間違った最終状態を生成したり、UIを矛盾した状態にしたままにするバグを見つけます。次の場合に使用します:体系的なデバッグがバグを見つけたが、ユーザーは壊れたボタンを報告する場合、または共有状態ストアに触れる主要なリファクター後。

Instructions onlySoftware Development
AI-generated overview

Audits user-facing click paths to find state-interaction bugs where handlers silently cancel each other.

What it does
This skill provides a structured audit procedure for interactive UI touchpoints. It has the agent map state stores and their side effects, then trace each handler's function calls in order to see which state is read, written, or reset. It produces a side-effect map of store actions and per-touchpoint findings about cancelled state changes, wrong final states, and race conditions.
When to use it
Use it when systematic debugging has found bugs but users still report broken buttons, or after a major refactor that touches shared state stores. It targets bugs that static code reading misses, such as side effects, ordering conflicts, and handlers that quietly undo each other.
Requirements
Instructions only; no scripts are shipped. It assumes access to the application source, including components with interactive handlers and shared state stores such as Zustand, Redux, or React context.

/click-path-audit — 行動フロー監査

静的コード読み取りが見落とすバグを見つけ:状態相互作用の副作用、順序を付けられた呼び出し間の競合状態、および互いに静かに取り消すハンドラー。

この解決する問題

従来のデバッグチェック:

  • 関数が存在しますか?(不足している配線)
  • クラッシュしますか?(ランタイムエラー)
  • 正しいタイプを返しますか?(データフロー)

しかし、それはチェックしません:

  • 最終UI状態がボタンラベルが約束したものと一致しますか?
  • 関数Bが関数Aが行ったばかりをサイレンス的に取り消しますか?
  • 共有状態(Zustand/Redux/context)に意図した操作をキャンセルする副作用がありますか?

実例:「新しいメール」ボタンがsetComposeMode(true)を呼び出してからselectThread(null)。両方は個別に機能しました。しかし、selectThreadにはcomposeMode: falseをリセットする副作用がありました。ボタンは何もしなかった。54のバグは体系的なデバッグによって見つかりました — これは見落とされました。


動作方法

対象領域のすべてのインタラクティブなタッチポイントについて:

1. ハンドラーを特定(onClick、onSubmit、onChangeなど)2. ハンドラーのすべての関数呼び出しを**順序で**追跡3. 各関数呼び出し**について**:   a. どの状態を読んでいますか?   b. どの状態を書き込んでいますか?   c. 共有状態に副作用がありますか?   d. 副作用として状態をリセット/クリアしますか?4. チェック:後の呼び出しが以前の呼び出しからの状態変更を取り消しますか?5. チェック:最終状態はユーザーがボタンラベルから期待するもの?6. チェック:競合状態がありますか(非同期呼び出しが間違った順序で解決される)?

実行ステップ

ステップ1:マップ状態ストア

任意のタッチポイントを監査する前に、すべての状態ストアアクションの副作用マップを構築:

範囲内の各Zustand ストア / React コンテキストについて:  各アクション/セッター:    - どのフィールドをセットしますか?    - 副作用として他のフィールドをリセットしますか?    - ドキュメント:actionName → {sets: [...], resets: [...]}

これは重要な参照です。「新しいメール」バグはselectThreadがcomposeModeをリセットしていることを知らないと見えなくなりました。

出力形式:

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(所有していない状態をクリアするアクション):  selectThread → composeMode をリセット(setComposeModeで所有)  reset → すべてをリセット

ステップ2:各タッチポイントを監査

対象領域の各ボタン/トグル/フォーム送信について:

TOUCHPOINT: [ボタンラベル] in [Component:line]ハンドラー:[関数呼び出しの完全なシーケンス]最終状態:[これが達成されるべきもの]

詳細については、ドキュメントを参照してください。

Source and attribution

Source:affaan-m/eccindocs/ja-JP/skills/click-path-auditat commitef648e0

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal