Skill Introduction

Overview

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

Core value

Turns reusable Documentation know-how into an installable skill, helping users complete github, community work faster.

Target users

Developers, testers, and maintainers who handle Documentation tasks in Focus Code.
Teams that already trust workflows or content from affaan-m.
Users who want standardized prompts, steps, or conventions instead of repeating setup work.

Best practices

Read the skill content first to confirm required inputs, expected outputs, and dependencies.
Try it on a small task before relying on it for critical work.
Add project-specific constraints such as coding style, target platform, test expectations, and delivery format.
For external sources, verify the source link, version, and recent maintenance activity.

Best use cases

Tasks related to github, community that need a reusable execution flow.
Converting a community repo, team convention, or personal workflow into day-to-day assistance.
Starting from a proven skill instead of writing prompts or procedures from scratch.

Limits and boundaries

Results depend on the quality of the original skill content and may need human correction.
It does not replace code review, tests, security review, or professional judgment.
External tools, APIs, account permissions, and local dependencies still need separate setup.

Differentiation

Structured around Documentation, making it easier to discover and reuse than loose prompt snippets.
Marked as GitHub, which helps users judge trust and maintenance expectations.
Keeps the original source link available for repository, documentation, or discussion follow-up.
Tagged with github, community, so it can be filtered by concrete task intent.

Install and use

Install

Copy Install Command

focus install click-path-audit-890732

View source

Detail Preview

SKILL.md

Primary filemarkdown5 KB

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

/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]
ハンドラー：[関数呼び出しの完全なシーケンス]
最終状態：[これが達成されるべきもの]

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

click path audit