Dashclaw Quality
Recurring find-and-fix quality pass over the whole DashClaw app — browser smoke (frontend-verify) + code gates → triage → paralle…
Claude CodeGeneric
---
description: Recurring find-and-fix quality pass over the whole DashClaw app — browser smoke (frontend-verify) + code gates → triage → parallel worktree fixes → verify → ship. The goal prompt that drives the dashclaw-find-and-fix workflow.
argument-hint: "[optional: focus area, token target like +500k, or 'no-ship']"
---
# Goal: make the DashClaw site actually work, without me clicking through it
You are running a **recurring find-and-fix quality loop** on this repo. The goal is a clean app:
every page renders, every code gate is green, and the fixes are in the working tree ready to ship.
Drive it to that state autonomously — do not hand me a checklist of things for me to do.
This command explicitly authorizes you to call the **Workflow** tool (the
`dashclaw-find-and-fix` script in `.claude/workflows/`). That is the engine; you are the driver.
## Stop condition
Loop until the workflow reports `stillBroken: []` **and** a full gate run is green, OR until
two consecutive rounds land nothing new (then stop and report what's stuck — do not spin).
Hard cap: **3 rounds**. If `$ARGUMENTS` names a focus area, scope triage/fixes to it. To go
deeper, include a token target like `+500k` in your message — the workflow's fan-out (finder
count and number of issues fixed) auto-scales to the turn's `budget.total`; it's read from the
harness, not passed as an arg.
## Each round
1. **Boot the browser layer (this session owns the dev server).**
Check `http://localhost:3000`. If it isn't up, start `npm run dev` in the background and wait
until it answers. The dev server must be started *here*, not inside the workflow — background
processes started by a sub-agent don't reliably survive.
- If a stale `.next/dev` cache makes every route 500 while `npm run build` passes, clear it and
restart dev before trusting the smoke results.
2. **Browser smoke with `frontend-verify`.** Invoke the `frontend-verify` skill across the routes
(it's the token-cheap verifier — reads console errors + failed network requests first, writes
full page state to disk; this is *not* the Chrome DevTools MCP, which stays banned). Collect its
findings as a list of `{source:"browser", severity, summary, location, evidence}`.
3. **Run the workflow.** Call `Workflow` with `name: "dashclaw-find-and-fix"` and
`args: { baseUrl: "http://localhost:3000", browserFindings: [...the list from step 2...] }`.
It will: discover routes → HTTP-smoke + run lint/vitest/build/contract gates in parallel →
triage everything (your browser findings included) into atomic issues → fix the top ones in
**isolated worktrees in parallel** → integrate the green diffs sequentially onto the working tree.
4. **Trust nothing — re-read the real diffs.** When the workflow says something is fixed, open the
landed changes and READ them, and re-run the relevant check yourself. Confident-wrong "it's
fixed" is the #1 failure mode here. A fix that landed but doesn't actually intercept the symptom
counts as still-broken.
5. **Decide: loop or stop.** If `stillBroken` is non-empty and this round made progress, loop. If
the *same* issue survives two rounds, change the hypothesis (use the `systematic-debugging`
skill) instead of re-poking the same spot — list 2–3 candidate root causes, run the cheapest
discriminating test, then fix.
## When clean — verify, then ship
6. **Full gate (its own step, read the output):** `npm run lint`, then `npx vitest run` (the
**full** suite — targeted runs miss regressions), then `npm run build` (webpack). If any fix
touched `schema/` or `drizzle/`, run `npm run db:migrate` first.
7. **Ship** unless `$ARGUMENTS` contains `no-ship`: hand off to the **`/dashclaw-ship`** skill —
it lands on main (you don't do PRs), bumps the unified platform+SDK version, and re-syncs every
doc/count/date to match the live code. Don't reinvent the release steps; that skill owns them.
## Guardrails (carry into every fix)
- **Surgical only.** Every changed line traces to a finding. Don't "improve" adjacent code.
- **Governance boundary.** Don't extend `app/api/_archive/**` or add agent-platform features.
- **No direct SQL in routes** — go through `app/lib/repositories/*.repository.js`.
- **Never hardcode** a version number (injected via `next.config.js`) or a hex color (use the
tokens in `app/globals.css`).
- **Token/cache discipline** (this is the repo where context burns hardest): the heavy fan-out
lives in the workflow's sub-agents, whose context is discarded. Keep *this* driver session lean —
read the workflow's structured report and the landed diffs, not whole files or raw gate logs.
## Report at the end
One compact summary: routes checked, issues found, what **landed** (with one line each), what was
**deferred** and why, what's **still broken** after the cap, and whether you shipped or stopped at
`no-ship`. No wall of logs.
Maintain Dashclaw Quality?
Let people know it's listed here — add the badge (live metrics, light/dark aware) or a plain link to your README or docs.
[](https://getagentictools.com/loops/ucsandman-goal-make-the-dashclaw-site-actually-work-without-me-clicking-through-?ref=badge)