跳到正文
cccskills
免费在 GitHub 公开

debug-broken-ui

Find out why something in a running web app does not work, when the console is empty and the code looks correct. Reads the click, the request, the store and the console together and returns the file:line to open. Use when a button does nothing, a form will not submit, data will not load, a page renders blank or stale, a modal will not close, or the user says "it's broken" and the code review says it is fine.

中文简介正在准备中。当前显示原文说明。

查看安装方法

包含的文件(1)

  • SKILL.md5.3 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

The app is broken and the code looks fine

Reading the source again will not tell you why. The evidence is in the running app, and most of it never reaches the screen: the request that failed, the store that never moved, the handler that was never bound, the element covered by something invisible.

Reticle reads all of it from inside the page. Not installed? RETICLE_INSTALL_SOURCE=npx_skill npx @reticlehq/server@latest init, then the install-and-verify skill.

Do not start by guessing. Start by reproducing.

reticle_look({ action: "page", sessionId, mode: "interactive" })   // controls only, with refs
reticle_act_and_wait({ sessionId, ref, action: "click", until: { kind: "element", query: { testid: "..." } } })

The verdict already narrows it: no / contradicted means a channel saw something incompatible with the UI: you have the bug. unknown means Reticle drove it and could not tell, which is a different investigation from "it failed".

Read the act result before you call anything else. Its summary block already carries the whole causal window of that one click: net {total, errors, headline}, consoleErrors, stateDiffs [{path, from, to}], storageDiffs [{key, from, to}], route, signals, layoutShift, longTasks: real before→after diffs, not counts. The console, network, storage and state calls below are for going DEEPER into something the summary already pointed at. Calling all three straight after an act pays three model round trips (and, in an approval-gated client, three human clicks) for evidence you were already holding.

summary.stateUnwatched: true means the state channel is dark: no subscribable store is registered, so an empty stateDiffs means unwatched, not unchanged, and no state-based conclusion is available until someone registers the store. It is the one field here that is about your instrumentation rather than about the app.

When the summary does point somewhere, read that channel scoped to what you just did: pass since from the act result, or you are reading a buffer that predates the click:

reticle_observe({ action: "console", sessionId, since })
reticle_observe({ action: "network", sessionId, since })
reticle_look({ action: "state", sessionId, store })

The diagnosis table

What you seeWhat it isNext
No request fired at allthe handler is not bound, or a client cache served a stale valuereticle_look { action: "element" } the element for its file:line; check the cache if it is TanStack Query
Request fired, 4xx/5xxa real backend failure the UI swallowedthe response body is in the network entry
2xx but nothing changedthe app never read the response: verdict says outcome_unreadusually a real bug in the success path
Request fine, DOM fine, store staleUI-vs-state desync, invisible to any screenshotreticle_look { action: "state" } is the only witness; this is the highest-value read here
Click did nothing, no errorthe control is dead, occluded, or disabledreticle_look { action: "element" } returns occluded, box (0×0), styles.cursor, opacity
Element "not found" that you can seevirtualised list has not mounted itreticle_scroll_to. A query that misses is not evidence of absence
Looks logged in, behaves logged outthe token never persistedreticle_storage
Console error that predates your clicka pre-existing fault, not your bugcall it out before continuing

Get the file, not a theory

reticle_look({ action: "element", sessionId, ref })

Returns the component and source: { file, line } for the element you are looking at, plus whether it is occluded, sized, disabled or off-theme. That is the pointer to open. End the investigation with a location, not a hypothesis.

When the flow is long

Do not ping-pong act → snapshot → act → snapshot to find the failing step. Drive the journey with reticle_act { steps: [...] } and assert once; the first step whose consequence fails is the one to look at, and you paid a fraction of the calls to find it.

Before you say it is fixed

Re-run the reproduction as a verdict (reticle_act_and_wait with the consequence named up front) rather than eyeballing the page. A fix confirmed by looking at it is the failure mode that created this ticket.

And never weaken the check to make it pass.


Troubleshooting Reticle itself (as opposed to the app): curl https://docs.reticle.sh/troubleshooting.md. Everything else: curl https://docs.reticle.sh/llms.txt. If Reticle could not see something you needed, reticle_session { action: "feedback" } with kind: "gap".

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Test-driven development for behaviour a unit test cannot reach, by writing the expectation against the running app before writing the code. Declare the consequence first, watch it fail, implement, watch it pass. Use when building a user-facing feature, when the user asks for TDD on UI or full-stack work, when a unit test cannot express the outcome that matters, or when you want a red-green loop that runs against the real app instead of mocks.

中文简介正在准备中。当前显示原文说明。

reticlehq/reticle12652026年10月20日 更新

Sweep a whole running web app for what is broken, without writing a script or knowing the codebase. Clicks every reachable control and reports dead buttons, console errors, failed requests, and places where the API and the screen disagree. Use on an unfamiliar codebase, before a release, after a big merge or dependency bump, when the user asks for a smoke test or a health check, or when someone says "just check everything still works".

中文简介正在准备中。当前显示原文说明。

reticlehq/reticle12652026年10月20日 更新

Check that the UI you actually rendered uses the design system, by reading computed styles in the running app against the project's design tokens. Catches hardcoded hex colors, off-palette backgrounds, invisible or unusable controls, and animations that never ran. Use after building or restyling a component, when a design review is wanted, when a UI looks slightly off but nobody can say why, or when a design system exists and nothing checks whether the code follows it.

中文简介正在准备中。当前显示原文说明。

reticlehq/reticle12652026年10月20日 更新

Drive and verify an Electron or Tauri desktop app from the inside, including the main-process and Rust IPC calls a browser tool cannot see. Use when a desktop app needs testing, when a feature works in the browser but not in the packaged app, when an IPC or invoke call needs proving, when a desktop screenshot or visual diff is wanted, or when you need a headless run of a desktop UI in CI.

中文简介正在准备中。当前显示原文说明。

reticlehq/reticle12652026年10月20日 更新

Find out why the tests pass but the app is broken. Catches false greens: a green suite over a feature that does not work, a mocked API standing in for a real one, an assertion that holds no matter what the app does, a click handler wired to nothing. Use when the suite is green and the user says it is broken, when a test never fails, when coverage looks fine but bugs still ship, or before trusting a passing run you did not watch.

中文简介正在准备中。当前显示原文说明。

reticlehq/reticle12652026年10月20日 更新

Pick up the bugs a human flagged by pointing at them in the running app, each arriving with the element, the note they typed, and the source file and line. Use when the user says they marked or flagged something, when starting a session on an app someone has been clicking through, when a designer or PM has left feedback in the UI, or when the user describes a problem as "that button there" without saying which file.

中文简介正在准备中。当前显示原文说明。

reticlehq/reticle12652026年10月20日 更新

查看 reticlehq 的全部技能

报告此技能的问题