
Fix What I Pointed At
Pick up the bugs a human flagged by pointing at them in the running app, each arriving...
Install
npx skills add reticlehq/reticle --skill fix-what-i-pointed-at -g -a claude-code -y- Repository
- reticlehq/reticle1.3k
- Category
- Design
- Updated
- 3d ago
- License
- Apache-2.0
- Context cost
- Lightabout 732 tokens
- Runs scripts
- No, instructions only
What it does
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.
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. The Reticle HUD in the running app has a Notes panel. The human clicks Add notes, points at an element, and types what is wrong. Each note 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 set up? Follow the reticle skill: it installs Reticle, asks the user before init changes the app's files, and proves one flow.
Drain the marks
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
}
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
- Read the marks. Group them if several point at the same file: one edit often answers three.
- Open
source.fileatsource.line. This is the whole point: no hunting for which component rendered that button. - Fix what the
noteasks for. If the note is ambiguous, the element label and its source usually disambiguate it. Ask the human only when they genuinely do not. - Verify in the app, do not eyeball it. Re-drive the affected control with
reticle_act_and_waitand name the consequence, orreticle_look { action: "element" }on the element for a layout or theme complaint. A visual fix confirmed by looking at it is how the mark gets reopened. - Resolve it:


