All skills

click-path-audit

Official
by Api.AirforcePrepends a system promptAI & Agent Building000 uses202,700

追踪每个面向用户的按钮/触点的完整状态变化序列,以发现功能单独工作但相互抵消、产生错误最终状态或使UI处于不一致状态的错误。适用于:系统调试未发现错误但用户报告按钮失效,或在任何涉及共享状态存储的重大重构之后。

open-sourceclaude-codeai-agent-buildingaffaan-m
Share

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: "追踪每个面向用户的按钮/触点的完整状态变化序列,以发现功能单独工作但相互抵消、产生错误最终状态或使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) → 设置: {composeMode}
  selectThread(thread|null) → 设置: {selectedThread, selectedThreadId, messages, drafts, selectedDraft, summary} 重置: {composeMode: false, composeData: null, redraftOpen: false}
  setDraftGenerating(bool) → 设置: {draftGenerating}
  ...

危险的重置(清除不属于自身状态的操作):
  selectThread → 重置 composeMode(由 setComposeMode 拥有)
  reset → 重置所有内容
```

### 步骤 2:审计每个触点

针对目标区域内的每个按钮/开关/表单提交:

```
TOUCHPOINT: [按钮标签] 在 [组件:行]
  HANDLER: onClick → {
    调用 1: functionA() → 设置 {X: true}
    调用 2: functionB() → 设置 {Y: null} 重置 {X: false}  ← 冲突
  }
  EXPECTED: 用户看到 [按钮标签所承诺的描述]
  ACTUAL: X 为 false,因为 functionB 重置了它
  VERDICT: BUG — [描述]
```

**检查以下每种缺陷模式:**

#### 模式 1:顺序撤销

```
handler() {
  setState_A(true)     // 设置 X = true
  setState_B(null)     // 副作用:重置 X = false
}
// 结果:X 为 false。第一次调用毫无意义。
```

#### 模式 2

Use this skill

Per request

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-0206de5f-7fa1-4b7d-a7b1-b86e400656df",
  "messages": [{ "role": "user", "content": "…" }]
}
Always on — no field to send

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 dashboard