关于 fix-what-i-pointed-at
供编码 Agent 处理 Reticle 界面反馈的技能。它将用户指向的元素转为带源码位置的标记,并引导 Agent 修复、验证后再解决标记。
主要功能
- 01读取 Reticle 反馈标记
- 02依据元素标签和源码位置定位
- 03按文件归并修复
- 04在运行中的应用验证更改
- 05验证后解决标记
适用场景
- 01修复应用中指出的界面问题
- 02处理指向同一源码文件的多条备注
- 03关闭反馈前验证视觉或交互修复
MCP 相关
通过 `reticle_session` 等 `reticle_*` MCP 工具查看标记并验证更改。
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ reticlehq/ reticle --skill fix-what-i-pointed-at安装后在 Claude Code 中输入/fix-what-i-pointed-at确认已加载。
详细介绍
人类指出了 bug。去修复它。
“那张卡片的间距不对”在聊天中无法采取行动,在应用中却很明确。运行中的应用里有一个 Reticle HUD,其中包含 Notes 面板。人类点击 Add notes,指向一个元素,并输入问题所在。每条备注都会成为一个标记,包含该元素、备注内容和 file:line,因此通常需要一张截图、一段描述和两个澄清问题才能完成的往返,现在只需一次调用。
还没设置?按照 reticle 技能操作:它会安装 Reticle,在 init 修改应用文件前征求用户同意,并验证一条工作流。
处理标记
reticle_session({ action: "review", sessionId })
{
"marks": [
{
"id": "m1",
"note": "this button is misaligned",
"label": "button \"Pay\"",
"source": { "file": "src/Checkout.tsx", "line": 42 },
"fix": "Open src/Checkout.tsx:42 and fix: this button is misaligned."
}
],
"pendingCount": 1
}
在会话开始时检查一次,并在每次人类使用过应用后再次检查。读取不会消耗标记,因此可以按任意顺序安全地执行列出 → 修复 → 验证 → 解决。
工作流程
- 读取标记。如果多条标记指向同一个文件,就将它们归组:一次编辑往往能解决三个问题。
- 打开
source.file中的source.line。这正是关键:无需费力查找是哪个组件渲染了那个按钮。 - 修复
note中提出的问题。如果备注含糊不清,元素标签及其源代码通常能消除歧义。只有在确实无法判断时,才询问人类。 - 在应用中验证,不要凭感觉判断。使用
reticle_act_and_wait重新操作受影响的控件,并说明操作结果;如果是布局或主题问题,则对该元素使用reticle_look { action: "element" }。通过查看确认视觉修复后,标记就会重新打开。 - 解决标记:
reticle_session({ action: "review", sessionId, resolve: "m1" })
只有在验证修复后才能解决标记。已解决的标记意味着向人类承诺,他们指出的问题已经处理完毕。
无法修复时
针对该标记说明原因,并保持未解决状态。悄悄丢弃标记比保留一个未解决的标记更糟:人类会以为问题已处理,之后才发现并非如此。如果备注描述的是预期行为而不是 bug,也要说明这一点,让他们决定如何处理。
使用他们的表达方式反馈
他们指的是“那个按钮”。反馈时要说“结账页上的 Pay 按钮”,并说明你做了哪些更改,以及有什么证据表明它现在能正常工作。标记来自正在看屏幕、而不是查看仓库的人,因此,反馈中堆满文件路径却没有面向用户的说法,就答非所问了。
其他所有内容:curl https://docs.reticle.sh/llms.txt。如果收到的标记没有可用的源代码指针,值得使用 reticle_session { action: "feedback" } 并设置 kind: "gap" 反馈这一问题。