fix-what-i-pointed-at

Solid

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.

AI & Automation 326 stars 69 forks Updated today NOASSERTION

Install

View on GitHub

Quality Score: 79/100

Stars 20%
84
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# 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 a...

Details

Author
reticlehq
Repository
reticlehq/reticle
Created
2 months ago
Last Updated
today
Language
TypeScript
License
NOASSERTION

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Solid

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.

326 Updated today
reticlehq
AI & Automation Listed

bugfix

Lightweight bug-fixing loop — reproduce → root-cause → fix test-first → verify — deliberately separate from the heavyweight feature workflow so small fixes don't drag a spec-and-plan process behind them. Demands a deterministic reproduction before any code changes, a stated root-cause hypothesis confirmed with evidence (never a shotgun fix), a failing test that captures the bug, and the original repro re-run as proof. Keeps a one-line-per-bug log in out/dev/bugfix-log.md and checks it first, so recurring bugs get recognized instead of re-diagnosed. Use when the user reports something broken, failing, throwing, or flaky, or asks to fix a bug — e.g. "/bugfix login 500s on empty password", "fix this error", "this test is flaky", "why is X crashing". If the fix turns out to need real design work, hand off to feature; the shipping gate is done.

9 Updated 3 days ago
duthaho
Data & Documents Listed

file-bug

Turn a user's report of something going wrong into a well-formed GitHub issue in the repo Claude is running in. Invoke explicitly as `$file-bug` or `/file-bug`, or when the user describes a defect, regression, broken behavior, confusing UX, error message, or a product idea and wants it captured as an issue/ticket — phrases like "file a bug", "open an issue for this", "log a ticket", "something's broken, write it up", or "track this idea". This skill investigates and writes the issue so the next person can understand AND reproduce the problem; it does NOT fix the bug or propose a fix.

0 Updated 3 weeks ago
comment-hq