본문으로 건너뛰기
cccskills
무료GitHub에 공개

verify-ui-change

Check that a change to a web app actually works in the running app before calling it done. Drives the real page and returns a pass/fail verdict with the request that fired, the state that moved, and the file:line to fix. Use after editing a component, a form, a route, or an API call; when you have said "fixed" but have not opened the app; when the user asks "does it actually work?"; or when a change looks right on screen and you cannot prove it.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(1)

  • SKILL.md5.2 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Verify the change in the running app

You edited something a user can see. Nothing is proven until the real app has done it and something other than the DOM agrees.

This uses Reticle, which embeds a dev-only SDK in the user's running app and exposes it as reticle_* MCP tools. No screenshots, no browser download for the verify loop, no dev server of its own.

1. Are the tools here?

reticle_session({ action: "list" })
  • A session comes back → go to step 2.
  • Tools do not exist → Reticle is not installed. Run RETICLE_INSTALL_SOURCE=npx_skill npx @reticlehq/server@latest init, then keep going without the tools: fix every ⚠ it printed, start the project's own dev script in the background if nothing is serving the app, and open it with npx @reticlehq/server open <the url the dev server is serving>. Only once the app is running and connected, ask for the one thing you cannot do yourself: a client restart, so it picks up the MCP server. Stopping at the init command leaves the user with config files and an uninstrumented page. Full setup is in the install-and-verify skill.
  • Tools exist, list is empty → read the why field on the response. It distinguishes "no app running" from "an app is running that never dialled this daemon" from "a tab was here and closed", and each has a different fix. If no app is running, start the project's own dev script from package.json in the background yourself and tell the user in one line that it is running and how to stop it: never a second one, never a guessed command, never kill anything, and the permission prompt is your host's. If one IS running, the app is not the missing piece and the SDK is; do not send the user to start what they already started.

2. Name the consequence BEFORE you act

This is the whole method. An expectation written after you see the result can be talked into agreeing with whatever happened; one written before cannot.

reticle_look({ action: "page", sessionId, mode: "interactive" })   // controls only, with refs

reticle_act_and_wait({ sessionId, ref, action: "click", until: { kind: "allOf", predicates: [
  { kind: "net",     method: "POST", urlContains: "/api/...", status: 200 },
  { kind: "element", query: { testid: "..." } },
  { kind: "console", level: "error", absent: true },
]}})

Multi-step journey? Drive it in one call with reticle_act { steps: [...] }, then assert the outcome once. Do not act → snapshot → act → snapshot: it proves the same thing at several times the cost.

Verdicts come from reticle_act_and_wait, reticle_assert, and reticle_act { steps } when a step declares expect. A bare reticle_act, look, navigate and observe move or read the app and prove nothing. A drive that ends without a verdict has no result, however many calls it made.

3. Read the verdict honestly

verifiedmeansdo
yesthe consequence you named happenedreport it, with the evidence
noit did not happen, or a channel contradicted the UIa real finding: report it with because
unknownReticle drove the app and could not tellnot a pass. Say unknown and say why

On unknown / unsettled, re-assert rather than re-driving: reticle_assert({ predicate, since, timeout_ms: 8000 }) using the since from the act result. Re-driving repeats a side effect that already happened.

Never weaken a check to turn a verdict green. An assertion edited until it passes proves nothing.

4. Check what you did not touch

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

If untouched still holds controls your change affects, the drive is unfinished. One call, and it is the cheapest guard against reporting a pass over the half you never opened.

5. Report

State what you drove, what the verdict was, and the evidence: the request and status, the state that changed, the app's own signal. If something failed, reticle_look({ action: "element", sessionId, ref }) on the failing element gives the file:line: put it in the report.

Then reticle_session({ action: "yield", mode: "waiting" }) so the human's panel stops reading "live".


More detail, fetchable one page at a time: curl https://docs.reticle.sh/llms.txt for the index, then the single page you need (https://docs.reticle.sh/tools/act-and-wait.md, https://docs.reticle.sh/predicates.md, https://docs.reticle.sh/troubleshooting.md). If Reticle itself misbehaves, file it with reticle_session { action: "feedback" }: one call, then carry on.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 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/reticle1.3천2026년 10월 21일 업데이트

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/reticle1.3천2026년 10월 21일 업데이트

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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

reticlehq/reticle1.3천2026년 10월 21일 업데이트

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/reticle1.3천2026년 10월 21일 업데이트

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/reticle1.3천2026년 10월 21일 업데이트

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/reticle1.3천2026년 10월 21일 업데이트

reticlehq의 스킬 모두 보기

이 스킬의 문제 신고