fix-what-i-pointed-at
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.
git clone --depth 1 https://github.com/reticlehq/reticle /tmp/fix-what-i-pointed-at && cp -r /tmp/fix-what-i-pointed-at/skills/fix-what-i-pointed-at ~/.claude/skills/fix-what-i-pointed-atSKILL.md
# The human pointed at the bug. Go fix it.
"The spacing on that card is wrong" is unactionable in chat and precise in the app. **Reticle**'s running app has a **Flag a bug** control: the human clicks it, points at an element, and types what is wrong. Each flag becomes a mark carrying the element, the note, and the `file:line`, so the round trip that usually costs a screenshot, a description, and two clarifying questions costs one call.
Not installed? `RETICLE_INSTALL_SOURCE=npx_skill npx @reticlehq/server@latest init`, then the [`install-and-verify`](https://github.com/reticlehq/reticle/blob/main/skills/install-and-verify/SKILL.md) skill.
## Drain the marks
```
reticle_session({ action: "review", sessionId })
```
```json
{
"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
}
```
**Check this at the start of a session**, and again whenever the human has been in the app. Reading never consumes a mark, so list → fix → verify → resolve is safe to run in any order.
## The loop
1. **Read** the marks. Group them if several point at the same file: one edit often answers three.
2. **Open** `source.file` at `source.line`. This is the whole point: no hunting for which component rendered that button.
3. **Fix** what the `note` asks for. If the note is ambiguous, the element label and its source usually disambiguate it. Ask the human only when they genuinely do not.
4. **Verify in the app**, do not eyeball it. Re-drive the affected control with `reticle_act_and_wait` and name the consequence, or `reticle_inspect` the element for a layout or theme complaint. A visual fix confirmed by looking at it is how the mark gets reopened.
5. **Resolve** it:
```
reticle_session({ action: "review", sessionId, resolve: "m1" })
```
Resolve only after the fix is verified. A resolved mark is a promise to the human that the thing they pointed at is done.
## When you cannot fix one
Say so against that mark and leave it unresolved. A mark silently dropped is worse than an open one: the human believes it was handled and finds out later. If the note describes intended behaviour rather than a bug, say that too, and let them decide.
## Report back in their vocabulary
They pointed at "that button". Report on "the Pay button on checkout", with what you changed and the evidence it now works. Marks come from people who are looking at the screen, not at the repo, so a report full of file paths and no user-facing language answers the wrong question.
---
Everything else: `curl https://docs.reticle.sh/llms.txt`. If a mark arrived without a usable source pointer, that is worth a `reticle_feedback` with `kind: "gap"`.Install, instrument and verify this running web app from the inside (DOM, network, routing, console and framework state) instead of screenshots or guessing. Drives one real flow end to end and returns a verdict with the file:line to fix. Use when the user asks to set up or install Reticle, when a user-facing change needs proving before you call it done, when a test passes but the UI is broken, or when the user types /reticle.
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.
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".
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.
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.
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.
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.