Skip to main content
ClaudeWave
Skill417 estrellas del repoactualizado 3d ago

audit-my-app

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".

Instalar en Claude Code
Copiar
git clone --depth 1 https://github.com/reticlehq/reticle /tmp/audit-my-app && cp -r /tmp/audit-my-app/skills/audit-my-app ~/.claude/skills/audit-my-app
Después abre una sesión nueva de Claude Code; el skill carga automáticamente.

SKILL.md

# Sweep the whole app and report what is broken

You do not need to understand the codebase to check it. **Reticle** drives every reachable control in the running app and reports the anomalies. 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.

## 1. Ask the app what it can do

```
reticle_capabilities({ sessionId })
```

About 1 KB, and it is the app describing its own testable surface: every registered testid, every domain signal, the stores, and the saved flows with their steps. That beats snapshotting the DOM and inferring intent from element names, and it is the cheapest orientation available.

## 2. Click everything

```
reticle_run({ tool: "reticle_verify", sessionId, args: { action: "crawl", maxSteps: 25 } })
```

```json
{
  "interactiveFound": 3,
  "stepsRun": 3,
  "anomalies": [],
  "counts": { "consoleErrors": 0, "failedRequests": 0, "deadControls": 0, "contradictions": 0 },
  "visited": ["- textbox \"Email\"", "- button \"Sign in\""],
  "truncated": false
}
```

**`deadControls` and `contradictions` are the two counts that mean a real problem.** Console errors and failed requests are worth reading but a busy app produces both innocently. A dead control is a button wired to nothing; a contradiction is a channel disagreeing with what the screen showed.

It clicks **everything**, so point it at a dev environment. `maxSteps` bounds it and defaults to 25. Want a non-destructive pass first: what is reachable, without touching it? `reticle_run({ tool: "reticle_explore", sessionId })`.

Do not hand-roll this sweep. The obvious version (click each control, assert no console error) **passes on exactly the bug you are sweeping for**, because a dead button throws nothing.

## 3. Compare what the API said against what rendered

```
reticle_run({ tool: "reticle_reconcile", sessionId })
```

The API returned ten rows, the table shows nine, nothing errored. Neither the network log nor the DOM is wrong on its own. Only the comparison catches it, and nothing else you can run makes that comparison.

## 4. Find the parts nobody exercised

```
reticle_run({ tool: "reticle_verify", sessionId, args: { action: "coverage" } })   // { total, exercised, untouched }
```

And if the project already has saved flows, ask whether they prove anything:

```
reticle_run({ tool: "reticle_domain", sessionId })
// → { flowCount, coverage: { asserted, presenceOnly, assertionFree }, gaps: { declaredUntestedSignals, … } }
```

A suite of forty flows where thirty-one assert nothing is a suite that will stay green through any regression. That number is usually the most alarming thing in the whole audit, and nothing else reports it.

## 5. Report

Lead with the counts, then one line per real finding with its `file:line` from `reticle_inspect`. Separate:

- **Broken**: dead controls, contradictions, failed requests, errors thrown during the sweep.
- **Unverified**: `untouched` controls and `assertionFree` flows. Not known to be broken; known to be unchecked.
- **Pre-existing**: console errors that were already there before the sweep started. Say so, so nobody attributes them to today's change.

**Do not report a clean audit over a partial one.** If `truncated` is true or `maxSteps` cut the sweep short, say what was not reached. A silent cap reads as "everything is fine" when it means "I stopped".

---

Full capability reference: `curl https://docs.reticle.sh/capabilities.md`. Everything else: `curl https://docs.reticle.sh/llms.txt`.
SKILLSkill
reticleSkill

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.

agentic-tddSkill

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.

debug-broken-uiSkill

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.

design-system-complianceSkill

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-desktop-appSkill

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.

false-green-testsSkill

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.

fix-what-i-pointed-atSkill

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.