Skill v1.0.0

version: "1.0.0" name: fleet-verify description: Use after a UI or user-visible change and before you claim it works — it spawns ONE CCC verification lane that drives a real browser (gstack browse, or CCC's puppeteer snapshot as fallback) against the running app, checks the specific thing you changed, and reports a visual/behavioral verdict with a screenshot. Independent of your context; catches what a diff read and a unit test cannot. allowed-tools: Bash

/code-review reads the diff. pair-verify runs a bug at two refs. Neither opens the app and looks. Fleet-verify spawns one CCC lane that drives a headless browser against the running dashboard (or your app), verifies the exact change you describe, captures a screenshot as evidence, and reports a verdict. It pairs CCC's spawn/report_to mechanics (ccc-orchestration) with gstack browse (headless Chromium QA).

Cost

1 spawned session. A real billed session on the kanban — state the count before spawning. Skip it for pure backend/logic changes with no rendered surface (there is nothing to look at); use a test or pair-verify instead.

Preconditions — gather these BEFORE spawning

The lane can only check what you can point it at. Have all three:

• (a) A running, reachable app + URL. For CCC itself that is

http://127.0.0.1:8090. For another app, its dev-server URL. If nothing is running, start it first (or say so in the prompt so the lane starts it).

• (b) The exact thing to verify — "the skills chip shows a count and the

status rail lists each subagent", not "check the UI". Name the selector, text, or state you expect.

• (c) The repo path.

Setup

CCC_URL="$(cat ~/.claude/command-center/port.txt 2>/dev/null || echo "${CCC_URL:-http://127.0.0.1:8090}")"
curl -sf --max-time 2 "$CCC_URL/api/version" >/dev/null 2>&1 || CCC_URL="http://127.0.0.1:8090"
curl -sf --max-time 2 "$CCC_URL/api/version" >/dev/null 2>&1 || CCC_DOWN=1

• Run every CCC curl with the network sandbox disabled (loopback is blocked

in the Bash sandbox and fails spuriously even when CCC is up).

• URL-encode `repo_path` in query strings.

Spawning the verifier

curl -s -X POST "$CCC_URL/api/sessions/spawn" -H "Content-Type: application/json" -d @- <<'JSON'
{
  "prompt": "Independent visual verification. Drive a headless browser and confirm a specific change. 1) Use gstack browse (the `browse` skill): `$B goto <url>`, then `$B text`, `$B js \"<expr>\"`, `$B is visible @<ref>` to check state, and `$B screenshot /tmp/fleet-verify-<slug>.png` for evidence. If gstack browse is unavailable, run CCC's `node snapshot.js` first (it writes snapshot.png). Do not substitute chrome-devtools: only use chrome-devtools after `curl -fsS --max-time 2 http://127.0.0.1:<debug-port>/json/version` returns Chrome JSON. 2) Verify EXACTLY this: <the specific thing — selector/text/state you expect>. 3) Report VERDICT (VERIFIED / NOT-VISIBLE / WRONG-STATE / APP-DOWN), the commands you ran, and the screenshot path as evidence. Be literal: report what you actually see, not what the change intended.",
  "repo_path": "/abs/path/to/repo",
  "report_to": "<your-session-id>"
}
JSON

• Omit "model" and "reasoning_effort" to use the server spawn defaults; if

you pass either, pass "engine" too (both are validated per engine, and the effort ladder differs by engine: see ccc-orchestration § 2).

• CCC appends the return-address footer (report_to), so the verdict injects

back to you when the lane finishes.

Waiting for the report

After spawning, end your turn. Tell the user a lane is verifying and give its session id. The verdict arrives by injection — do not poll or sleep-loop. If it never arrives, check GET /api/sessions/spawned for whether the lane is alive.

Interpreting the verdict

• VERIFIED — the change renders/behaves as described, with a screenshot to

prove it. Ship it.

• NOT-VISIBLE — the lane could not find what you described. Either the change

did not take, or you pointed it at the wrong place. Investigate before claiming.

• WRONG-STATE — it rendered, but not as you expected. Read the evidence.
• APP-DOWN — nothing was running to verify. Start the app and re-run.

Dry run

If the arguments contain dry-run, print the exact payload — session count (1), the filled-in verifier prompt with URL and the specific check, and the target repo — and POST nothing.

Honest fallbacks

• CCC down (`CCC_DOWN=1`): run gstack browse (or node snapshot.js)

yourself against the running app, and in your claim say verification was self-run — you know what the change was meant to do, so you are a weaker skeptic than a fresh lane. Never pretend the spawn ran.

• No browser tooling at all: say so plainly and fall back to a functional

check (curl the endpoint, assert the JSON/DOM string). A string assertion is not the same as seeing it render — flag the gap.