Comprehensive verification using parallel test agents for unit tests, integration tests, E2E validation, security scanning, and type checking. Runs coverage analysis, detects regressions, and validates against project conventions. Reports pass/fail with detailed findings and coverage deltas. Use when verifying implementations, validating changes after /ork:implement, or running pre-merge quality gates.
Commandhigh
Invoke
/ork:verify
Verify Comprehensive verification using parallel test agents for unit tests, integration tests, E2E validation, security scanning, and type checking. Runs coverage analysis, detects regressions, and validates against project conventions. Reports pass/fail with detailed findings and coverage deltas. Use when verifying implementations, validating changes after /ork:implement, or running pre-merge quality gates.
SCOPE = "$ARGUMENTS" # Full argument string, e.g., "authentication flow"SCOPE_TOKEN = "$ARGUMENTS[0]" # First token for flag detection (e.g., "--scope=backend")# $ARGUMENTS[0], $ARGUMENTS[1] etc. for indexed access (CC 2.1.59)# Model override detection (CC 2.1.72)MODEL_OVERRIDE = Nonefor token in "$ARGUMENTS".split(): if token.startswith("--model="): MODEL_OVERRIDE = token.split("=", 1)[1] # "opus", "sonnet", "haiku", "fable" SCOPE = SCOPE.replace(token, "").strip()# Streak gate detection (#2540) — consecutive-pass modeSTREAK_TARGET = Nonefor token in "$ARGUMENTS".split(): if token.startswith("--streak="): STREAK_TARGET = int(token.split("=", 1)[1]) # N consecutive READY verdicts required (N >= 2) SCOPE = SCOPE.replace(token, "").strip()# When set, apply the Streak Gate (see below). Full protocol: references/streak-gate.md
Pass MODEL_OVERRIDE to all Agent() calls via model=MODEL_OVERRIDE when set. Accepts symbolic names (opus, sonnet, haiku, fable on harnesses whose Agent tool lists it; note fable is premium API spend after 2026-07-12) or full IDs (claude-opus-4-8) per CC 2.1.74.
Opus 4.8: Agents use native adaptive thinking (no MCP sequential-thinking needed); defaults to high effort (CC 2.1.154+). Extended 128K output supports comprehensive verification reports.
Load details: Read("$\{CLAUDE_SKILL_DIR\}/references/orchestration-mode.md") for env var check logic, Agent Teams vs Task Tool comparison, and mode selection rules.
Choose Agent Teams (mesh -- verifiers share findings) or Task tool (star -- all report to lead) based on the orchestration mode reference.
# Guard: Skip cron in headless/CI (CLAUDE_CODE_DISABLE_CRON)# if env CLAUDE_CODE_DISABLE_CRON is set, run a single check insteadCronCreate( schedule="0 8 * * *", prompt="Daily regression check: npm test. If 7 consecutive passes → CronDelete. If failures → alert with details.")
Load details: Read("$\{CLAUDE_SKILL_DIR\}/references/verification-phases.md") for complete phase details, agent spawn definitions, Agent Teams alternative, and team teardown.
Output each agent's score as soon as it completes — don't wait for all 6-7 agents.
Focus mode (CC 2.1.101): In focus mode, include the full composite score, all dimension scores, and the verdict in your final message — the user didn't see the incremental outputs.
Security: 8.2/10 — No critical vulnerabilities foundCode Quality: 7.5/10 — 3 complexity hotspots identified[...remaining agents still running...]
This gives users real-time visibility into multi-agent verification. If any dimension scores below the security_minimum threshold (default 5.0), flag it as a blocker immediately — the user can terminate early without waiting for remaining agents.
Use Monitor for streaming test execution output from background scripts:
# Stream test output in real-time instead of waiting for completionBash(command="npm test 2>&1", run_in_background=true)Monitor(pid=test_task_id) # Each line → notification
Full pattern reference (when to use vs. TaskOutput, until-condition gates, anti-patterns): Read("$\{CLAUDE_PLUGIN_ROOT\}/skills/chain-patterns/references/monitor-patterns.md").
Partial results (CC 2.1.98): If a verification agent fails mid-analysis, synthesize partial scores rather than re-spawning:
for agent_result in verification_results: if "[PARTIAL RESULT]" in agent_result.output: # Extract whatever scores the agent produced before crashing partial_score = parse_score(agent_result.output) # May be incomplete scores[agent_result.dimension] = { "score": partial_score, "partial": True, "note": "Agent crashed — score based on partial analysis" } # A 4-dimension score is better than no score. Do NOT re-spawn.
Load details: Read("$\{CLAUDE_SKILL_DIR\}/references/visual-capture.md") for auto-detection, route discovery, screenshot capture, and AI vision evaluation.
Summary: Auto-detects project framework, starts dev server, discovers routes, uses agent-browser to screenshot each route, evaluates with Claude vision, generates self-contained gallery.html with base64-embedded images.
Output: verification-output/\{timestamp\}/gallery.html — open in browser to see all screenshots with AI evaluations, scores, and annotation diffs.
Graceful degradation: If no frontend detected or server won't start, skips visual capture with a warning — never blocks verification.
Load details: Read("$\{CLAUDE_SKILL_DIR\}/references/visual-capture.md") (Phase 8.5 section) for agentation loop workflow.
Trigger: Only when agentation MCP is configured. Offers user the choice to annotate the live UI. ui-feedback agent processes annotations, re-screenshots show before/after.
Composite is necessary but not sufficient — a strong composite can average away a critical dimension. In Phase 4 (Nuanced Grading), read per-dimension thresholds from $\{CLAUDE_SKILL_DIR\}/rubric.json (schema: $\{CLAUDE_PLUGIN_ROOT\}/skills/shared/rubric.schema.json): security min_blocker 4.0, compliance min_pass 6.0.
ANY dimension below its min_blocker → verdict is BLOCKED regardless of composite. Report it explicitly: Security 3.2/10 (CRITICAL BLOCKER — below min_blocker 4.0).
A dimension below its min_pass (but at/above min_blocker) caps the verdict at IMPROVEMENTS RECOMMENDED — it cannot grade READY FOR MERGE.
Blocked verdicts list every tripped dimension first, each with the fix needed to clear it.
A project .claude/policies/verification-policy.json (see Policy-as-Code) may tighten these thresholds, never loosen them below the rubric defaults.
Threshold bands and reporting format: references/grading-rubric.md ("Dimension-Level Blockers" section).
A single green is not proof — flaky and order-dependent suites pass once and fail the next run. With --streak=N, verify declares READY FOR MERGE only after N consecutive passing runs, resetting the count to 0 on any non-ready verdict. The count persists across independent runs in .claude/chain/verify-streak.json, keyed by scope.
--streak=N (N ≥ 2; 3 is the sensible default). Absent ⇒ today's single pass/fail behavior, unchanged. Target may also come from .claude/policies/verification-policy.json ("streak_target"); the flag wins.
The gate sits above the verdict — it never loosens a blocker, it only withholds "done" until the streak is met. Each run re-executes the actual tests (no cached passes — that independence is the whole point).
Reset rule: any non-READY FOR MERGE verdict (tripped blocker, failing test, or IMPROVEMENTS RECOMMENDED) zeroes the count. No partial credit.
The verdict surfaces the count: STREAK 2/3 — one more green to merge, or streak reset to 0/3 (security 3.2 < 4.0).
This is the native mechanism the prd-to-goal quality-streak recipe (#2539) leans on. Pair it with a /goal loop, but rm the ledger first — /goal reads until before the turn's verify, so a stale met:true exits with zero runs (see streak-gate.md "Stale-ledger guard").
Full protocol — ledger schema, run loop, /goal wiring, and /ork:cover reuse: Read("$\{CLAUDE_SKILL_DIR\}/references/streak-gate.md").
Load details: Read("$\{CLAUDE_SKILL_DIR\}/rules/evidence-collection.md") for git commands, test execution patterns, metrics tracking, and post-verification feedback.
Agent scores, tool summaries, and every "X is clean / passing / fixed" sentence are claims until the lead re-runs the proof. Before the verdict, build a Verification Manifest marking every load-bearing claim ✅ VERIFIED (lead ran it fresh — cites command · exit · key line), 🟡 CLAIMED (an agent/tool/doc asserted it, not re-run), ⬜ UNCHECKED, or ⚪ WAIVED (accepted non-blocking, with a reason). An agent's "PASS" copied into the report is still CLAIMED — VERIFIED means the lead ran it; a sub-agent's number (price, model-id, count) is CLAIMED until checked against source.
Verdict rule: any load-bearing claim still 🟡 CLAIMED or ⬜ UNCHECKED caps the verdict at IMPROVEMENTS RECOMMENDED (never READY FOR MERGE) until it is ✅ VERIFIED or ⚪ WAIVED — this stacks with the dimension-level blockers (both must clear), and under --streak=N it resets the streak.
Load details: Read("$\{CLAUDE_SKILL_DIR\}/references/report-template.md") for full format. Summary:
# Feature Verification Report**Composite Score: [N.N]/10** (Grade: [LETTER])## Verdict**[READY FOR MERGE | IMPROVEMENTS RECOMMENDED | BLOCKED]**[--streak=N mode only: **STREAK [current]/[target]** — READY FOR MERGE requires the full target; any non-ready run resets to 0.]## Verification Manifest[✅ VERIFIED · 🟡 CLAIMED · ⬜ UNCHECKED · ⚪ WAIVED — any load-bearing 🟡/⬜ caps the verdict below READY FOR MERGE]| # | Load-bearing claim | Asserted by | Provenance | Evidence (cmd · exit · key line) |
Push notifications (CC 2.1.110+): Verify runs for >5 min are common on complex changes. When the final verdict is ready, call PushNotification to alert the user — they likely walked away from the terminal. Requires Remote Control with "Push when Claude decides" config; fails silently for users without it.
Load Read("$\{CLAUDE_PLUGIN_ROOT\}/skills/shared/rules/verification-gate.md") — the minimum 5-step gate that applies to ALL completion claims across all skills. This is non-negotiable: NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.
Load Read("$\{CLAUDE_PLUGIN_ROOT\}/skills/shared/rules/anti-sycophancy.md") — all verification agents report findings directly without performative agreement. "Should be fine" is not evidence. "Tests pass (exit 0, 47/47)" is.
All verification agents MUST report using the standardized protocol: Read("$\{CLAUDE_PLUGIN_ROOT\}/agents/shared/status-protocol.md"). Never report DONE if concerns exist. Never silently produce work you're unsure about.
When a security agent finds a critical issue, share it with other verification agents:
SendMessage(to="test-generator", message="Security: SQL injection in user_service.py:88 — add parameterized query test")SendMessage(to="code-quality-reviewer", message="Security finding at user_service.py:88 — flag in review")
Session recovery (CC 2.1.108+): After idle periods or interruptions, use /recap to restore conversational context alongside checkpoint-resume state. Enabled by default since CC 2.1.110 (even with telemetry disabled).
ork:implement - Full implementation with verification
ork:review-pr - PR-specific verification
testing-unit / testing-integration / testing-e2e - Test execution patterns
ork:quality-gates - Quality gate patterns
browser-tools - Browser automation for visual capture
Version: 4.5.0 (July 2026) — Added the Verification Manifest (VERIFIED vs CLAIMED) — a load-bearing-claim provenance ledger that caps the verdict below READY FOR MERGE until unverified claims are re-run or waived
Version: 4.4.0 (June 2026) — Added --streak=N consecutive-pass gate (#2540)
git diff main --statgit log main..HEAD --onelinegit diff main --name-only | sort -u
Incorrect:
# Sequential — wastes time, no coverage datacd backend && pytest tests/cd frontend && npm test
Correct:
# Parallel with coverage — run both in ONE messagecd backend && poetry run pytest tests/ -v --cov=app --cov-report=jsoncd frontend && npm run test -- --coverage
Run in parallel with Phase 2 agents. Auto-detects frontend framework and captures screenshots.
Incorrect:
# Manual screenshots with no structureopen http://localhost:3000# Take manual screenshot...
Correct:
# Automated visual capture with AI evaluationAgent( subagent_type="general-purpose", prompt="Visual capture: detect framework, start server, screenshot routes via agent-browser, evaluate with Claude vision, generate gallery.html", run_in_background=True)
Output structure:
verification-output/{timestamp}/├── screenshots/ (PNGs per route, base64 in gallery)├── ai-evaluations/ (JSON per screenshot with score + issues)├── annotations/ (before/after if agentation used)│ ├── before/│ └── after/└── gallery.html (self-contained, open in browser)
Verification can be blocked by policy-as-code rules. See Policy-as-Code for configuration of composite minimums, dimension minimums, and blocking rules.
The composite table above is overridden by per-dimension floors. Thresholds live in ../rubric.json (min_blocker / min_pass fields; schema: ../../shared/rubric.schema.json) — they map to the 0-3 "Poor, blocks merge" band of each dimension rubric.
Dimension
Threshold
Effect when below
Security
min_blocker 4.0
Verdict BLOCKED regardless of composite
Compliance
min_pass 6.0
Verdict capped at IMPROVEMENTS RECOMMENDED
Reporting format — the tripped dimension leads the verdict, with the threshold named:
# Agent Teams is GA since CC 2.1.33import osforce_task_tool = os.environ.get("ORCHESTKIT_FORCE_TASK_TOOL") == "1"if force_task_tool: mode = "task_tool"else: # Teams available by default — use for full multi-dimensional work mode = "agent_teams" if scope == "full" else "task_tool"
If Agent Teams encounters issues mid-execution, fall back to Task tool for remaining work. This is safe because both modes produce the same output format (dimensional scores 0-10).
For full codebase work (>20 files), use the 1M context window to avoid agent context exhaustion. On 200K context, scope discovery should limit files to prevent overflow.
A single green is not proof. Flaky suites, race conditions, and order-dependent tests pass once and fail the next run. The streak gate makes /ork:verify declare a feature done only after N consecutive passing runs, resetting the count to zero on any failure. It is the flakiness defense that single-shot pass/fail can't give.
Loop-Library theme: Quality Streak ("fixes product failures until a defined streak of realistic tests passes"). This is the native ork mechanism the prd-to-goal quality-streak recipe leans on.
/ork:verify --streak=3 authentication flow # need 3 greens in a row/ork:verify --streak=3 # continues an existing streak for the same scope
--streak=N (N ≥ 2). When absent, verify behaves exactly as before (single pass/fail). The target may also come from the verify rubric's streak_target slot (src/skills/verify/rubric.json, an integer ≥ 2 validated by src/skills/shared/rubric.schema.json — a configured value is schema-checked, not silently ignored); the explicit flag always wins.
Parse it alongside the other flags in Argument Resolution:
STREAK_TARGET = Nonefor token in "$ARGUMENTS".split(): if token.startswith("--streak="): STREAK_TARGET = int(token.split("=", 1)[1]) # explicit override SCOPE = SCOPE.replace(token, "").strip()STREAK_TARGET = STREAK_TARGET or rubric.get("streak_target") # validated slot; may stay None
scope keys the streak — switching scope starts a fresh streak. current is the live consecutive-pass count; met is current >= target. last_run_ts is the timestamp of the run that last wrote the ledger — the freshness stamp a /goal loop checks so it never trusts a met:true it didn't just produce (see Stale-ledger guard).
Scope keying is normalized. The raw scope string is trimmed and its internal whitespace collapsed before it keys the streak, so "auth flow" and "auth flow" (or a trailing space) extend the same streak instead of silently starting fresh ones:
def streak_key(scope: str) -> str: return " ".join(scope.split()) # trim + collapse runs of whitespace
key = streak_key(SCOPE) # normalized: trim + collapse whitespaceledger = read(".claude/chain/verify-streak.json") or new_ledger(key, N)if ledger.scope != key or ledger.target != N: ledger = new_ledger(key, N) # scope/target change → fresh streakverdict = run_full_verification() # the normal 8-phase verify, UNCHANGEDif verdict == "READY FOR MERGE": ledger.current += 1 # extend the streakelse: if ledger.current > 0: ledger.reset_count += 1 ledger.current = 0 # ANY non-ready verdict breaks itledger.history.append({ts, verdict, composite, blocker?})ledger.met = ledger.current >= ledger.targetledger.last_run_ts = now_iso() # stamp THIS run — the freshness proofwrite_atomic(".claude/chain/verify-streak.json", ledger) # tmp + rename, never in-place
Atomic write (concurrency safety). The ledger is the counter, so a torn or last-writer-wins write corrupts the whole feature. Two verify runs on the same scope (e.g. parallel worktrees) must not race: write to verify-streak.json.tmp.<pid> then rename() over the target (an atomic filesystem op on POSIX). Never mutate the file in place. If two runs still interleave, rename-last-wins loses at most one increment — it never leaves a half-written ledger.
Reset rule: a streak breaks on any non-READY FOR MERGE verdict — a tripped dimension blocker, a failing test, or an IMPROVEMENTS-RECOMMENDED. One red zeroes the count. There is no partial credit.
Independence rule (the whole point): each run must re-execute the actual tests — no cached results, no "already passed last turn." A streak over cached runs proves nothing. If the suite is fast, run it fresh each turn; if it is slow, that cost is the price of trusting the green.
The streak gate sits above the normal verdict — it never loosens a blocker, it only withholds "done" until the streak is met:
Streak state
Reported verdict
this run not READY (blocker/fail)
the normal verdict (BLOCKED / IMPROVEMENTS RECOMMENDED) + streak reset to 0/N
READY but current < target
STREAK PROGRESS — current/target (not done; run again)
READY and current >= target
READY FOR MERGE (streak target/target met)
Always surface the count: STREAK 2/3 — one more green to merge or streak reset to 0/3 (security 3.2 < 4.0). The user must see how close (or how broken) the streak is.
The streak gate is what makes the quality-streak recipe converge. The until-clause reads the ledger; each loop turn runs verify:
# Stamp the loop start; honor met only for a ledger written AFTER it.LOOP_START="$(date -u +%Y-%m-%dT%H:%M:%SZ)"/goal until jq -e --arg t "$LOOP_START" '.met==true and .last_run_ts >= $t' .claude/chain/verify-streak.json/goal abort-if turns > 15 OR tokens > 150000 OR no_progress_for_4_turns
no_progress_for_4_turns is deliberately generous: a streak that keeps resetting is progress information (it's surfacing real flakiness), so give it room before aborting.
Stale-ledger guard (the first-run race)./goal evaluates the until-clause at the top of each turn — before that turn's verify runs. If a previous completed streak for the same scope left met:true in the ledger, a bare .met==true check exits on turn 1 having run zero fresh verifications. Defense (robust form): the until-clause compares last_run_ts against the loop-start timestamp, so met:true is honored only when the ledger was written this loop — you never trust a met you didn't just produce. This needs no rm and is safe even if a stale ledger exists (the old rm -f reset still works as a simpler fallback, but the timestamp guard is preferred because it also survives a mid-loop scope reuse). ISO-8601 UTC timestamps compare correctly as strings.
cover already auto-heals up to 3 iterations. The same ledger + reset protocol applies: after generating tests, require the suite to pass N times consecutively before declaring coverage done — this catches flaky generated tests before they land. Same verify-streak/1.0 ledger, keyed by the cover scope. (Cover wiring is a follow-up; the protocol here is the shared contract.)
The report's agent scores, tool summaries, and every "X is fixed / clean / passing"
sentence are claims until the lead independently re-runs the proof. The single
most common verification failure is relaying an agent's assertion as a fact — a
sub-agent reports "tsc clean", the lead copies that into the report, it ships, and it
does not work.
The Verification Manifest is a provenance ledger that closes that seam. For every
load-bearing claim in the run, the lead records whether it was independently
VERIFIED (with the exact command + output), merely CLAIMED (asserted by an
agent / tool / doc, never re-run), or UNCHECKED (assumed). It is the operational
form of the Verification Gate and
Anti-Sycophancy rules — turning "no completion
claims without fresh evidence" from a principle into a filled-in table.
Load-bearing claim — one where flipping it false would change the verdict, ship a
bug, or invalidate the merge. You do not manifest every trivial statement; you
manifest the claims the merge rests on. If in doubt, it's load-bearing.
Provenance states
State
Meaning
Row must include
✅ VERIFIED
The lead ran the proof fresh this session and read the output.
The command · exit code · the key output line
🟡 CLAIMED
A sub-agent, tool summary, doc, or memory asserted it — not independently re-run by the lead.
Who asserted it
⬜ UNCHECKED
Assumed true; nobody ran a proof (e.g. "no other caller depends on this" with no grep).
Why it was assumed
⚪ WAIVED
A CLAIMED/UNCHECKED item deliberately accepted as non-blocking.
A one-line reason + issue ref if deferred
An agent reporting "PASS" and the lead copying that into the manifest is still
🟡 CLAIMED — not ✅ VERIFIED. VERIFIED means the lead ran it. The distinction is the
whole point.
Any load-bearing claim that is 🟡 CLAIMED or ⬜ UNCHECKED caps the verdict at
IMPROVEMENTS RECOMMENDED — it cannot grade READY FOR MERGE — until it is ✅ VERIFIED
or explicitly ⚪ WAIVED with a reason.
This sits alongside the dimension-level blockers (see grading-rubric.md): a strong
composite score never launders an unverified load-bearing claim into "done." Both gates
must clear. Under --streak=N, a run carrying any load-bearing CLAIMED/UNCHECKED item is
not READY and therefore resets the streak to 0 (consistent with the existing reset
rule).
a. Agent output — every sub-agent approval / score / "PASS" / "clean" /
"no X found" is a CLAIM by default.
b. The working narrative — every "X is fixed / passing / done" sentence.
c. Premises the change rests on — facts pulled from a doc, memory, or prior
session ("the migration already ran", "the endpoint returns Y"). Docs and memory are
Tier 2–4 (see the context-precedence rule): CLAIMED until re-checked at HEAD.
For each, decide: can I cheaply run the proof now?
Yes → run it fresh, capture command · exit · key line → ✅ VERIFIED.
No → 🟡 CLAIMED / ⬜ UNCHECKED; if load-bearing, it caps the verdict (or ⚪ WAIVE it
with a reason).
Spend verification on the load-bearing few. You need not re-run everything — you
need to never present a CLAIMED item as VERIFIED.
Laundering — copying an agent's "PASS" into the table as ✅ VERIFIED without
re-running. That's CLAIMED. VERIFIED is the lead's fresh run.
Optimism-marking — flipping everything to ✅ to clear the gate. The manifest
measures honesty, not confidence. "Should be fine" is ⬜, not ✅.
Convenient omission — leaving a load-bearing claim off the table to dodge the
verdict cap. The omission is the bug the manifest exists to catch.
Trusting agent numbers — a price, model-id, cost, or count emitted by a sub-agent
is CLAIMED until checked against source. (Sub-agents have fabricated off-by-1000×
figures and retired model ids.) Central-verify before the row goes ✅.
Launch ALL agents in ONE message with run_in_background=True and max_turns=25. Pass model=MODEL_OVERRIDE when user specifies --model=opus (CC 2.1.72).
Agent
Focus
Output
code-quality-reviewer
Lint, types, patterns
Quality 0-10
security-auditor
OWASP, secrets, CVEs
Security 0-10
test-generator
Coverage, test quality
Coverage 0-10
backend-system-architect
API design, async
API 0-10
frontend-ui-developer
React 19, Zod, a11y
UI 0-10
python-performance-engineer
Latency, resources, scaling
Performance 0-10
Use python-performance-engineer for backend-focused verification or frontend-performance-engineer for frontend-focused verification. See Quality Model for Performance (0.11) and Scalability (0.09) weights.
Optionally add monitoring-engineer as a conditional observability verifier when the change touches services, handlers, background jobs, or infra (skip for pure UI/docs). It scores whether the new code is operable in production — structured logging on critical paths, metrics/SLIs, error/alert coverage — not just correct.
In Agent Teams mode, form a verification team where agents share findings and coordinate scoring:
# CC 2.1.178+: one implicit team per session — no TeamCreate.# Spawn teammates directly via Agent(name=...). Requires# CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 (set in ork.settings.json).Agent(subagent_type="ork:code-quality-reviewer", name="quality-verifier", team_name="verify-{feature}", model=MODEL_OVERRIDE, prompt="""# Cache-optimized: stable content first (CC 2.1.72) Verify code quality. Score 0-10. When you find patterns that affect security, message security-verifier. When you find untested code paths, message test-verifier. Share your quality score with all teammates for composite calculation. Feature: {feature}.""")Agent(subagent_type="ork:security-auditor", name="security-verifier", team_name="verify-{feature}", model=MODEL_OVERRIDE, prompt="""# Cache-optimized: stable content first (CC 2.1.72) Security verification. Score 0-10. When quality-verifier flags security-relevant patterns, investigate deeper. When you find vulnerabilities in API endpoints, message api-verifier. Share severity findings with test-verifier for test gap analysis. Feature: {feature}.""")Agent(subagent_type="ork:test-generator", name="test-verifier", team_name="verify-{feature}", model=MODEL_OVERRIDE, prompt="""# Cache-optimized: stable content first (CC 2.1.72) Verify test coverage. Score 0-10. When quality-verifier or security-verifier flag untested paths, quantify the gap. Run existing tests and report coverage metrics. Message the lead with coverage data for composite scoring. Feature: {feature}.""")Agent(subagent_type="ork:backend-system-architect", name="api-verifier", team_name="verify-{feature}", model=MODEL_OVERRIDE, prompt="""# Cache-optimized: stable content first (CC 2.1.72) Verify API design and backend patterns. Score 0-10. When security-verifier flags endpoint issues, validate and score. Share API compliance findings with ui-verifier for consistency check. Feature: {feature}.""")Agent(subagent_type="ork:frontend-ui-developer", name="ui-verifier", team_name="verify-{feature}", model=MODEL_OVERRIDE, prompt="""# Cache-optimized: stable content first (CC 2.1.72) Verify frontend implementation. Score 0-10. When api-verifier shares API patterns, verify frontend matches. Check React 19 patterns, accessibility, and loading states. Share findings with quality-verifier for overall assessment. Feature: {feature}.""")# Conditional 6th agent — use python-performance-engineer for backend,# frontend-performance-engineer for frontendAgent(subagent_type="ork:python-performance-engineer", name="perf-verifier", team_name="verify-{feature}", model=MODEL_OVERRIDE, prompt="""# Cache-optimized: stable content first (CC 2.1.72) Verify performance and scalability. Score 0-10. Assess latency, resource usage, caching, and scaling patterns. When security-verifier flags resource-intensive endpoints, profile them. Share performance findings with api-verifier and quality-verifier. Feature: {feature}.""")
Team teardown after report compilation:
# After composite grading and report generation# CC 2.1.178+: no TeamDelete — teammates wind down at turn end# (press Ctrl+F twice to stop lingering background teammates).# Worktree cleanup (CC 2.1.72)ExitWorktree(action="keep")
Fallback: If team formation fails, use standard Phase 2 Task spawns above.
Runs as a 7th parallel agent alongside the 6 verification agents. See Visual Capture for full details.
# Launch IN THE SAME MESSAGE as Phase 2 agentsAgent( subagent_type="general-purpose", description="Visual capture and AI evaluation", prompt="""Visual verification capture for: {feature} 1. Detect project type from package.json 2. Start dev server (auto-detect framework) 3. Discover routes (framework-aware scan) 4. Use agent-browser to screenshot each route (max 20) 5. Read each screenshot PNG for AI vision evaluation 6. Score layout, accessibility, content completeness (0-10 per route) 7. Read gallery template from ${CLAUDE_SKILL_DIR}/assets/gallery-template.html 8. Generate gallery.html with base64-embedded screenshots 9. Write to verification-output/{timestamp}/gallery.html 10. Kill dev server If no frontend detected, write skip notice and exit. If server fails to start, write warning and exit. Never block — graceful degradation only.""", run_in_background=True, max_turns=30)
Output: verification-output/\{timestamp\}/ folder with screenshots, AI evaluations (JSON), and gallery.html.
Bash( command=f"{start_command} &", description="Start dev server for visual capture", run_in_background=True)
Wait for server readiness:
Bash(command=f"for i in $(seq 1 30); do curl -s http://localhost:{port} > /dev/null && exit 0; sleep 1; done; exit 1", description="Wait for dev server to be ready (max 30s)")
If server fails to start: Skip visual capture with a warning in the report. Do NOT block verification.
Then evaluate using this prompt template (include it in the visual capture agent's instructions):
Evaluate this screenshot of route "{route_path}" against these 6 criteria.For EACH criterion, provide a severity (ok/warning/error) and specific observation.Do NOT use generic "looks good" — cite what you actually see.1. LAYOUT: Overflow, alignment, spacing, responsive grid. Check: content cut off? Overlapping elements? Scroll needed?2. NAVIGATION: Is nav present and functional? Sidebar, breadcrumbs, TOC visible? Active state correct?3. CONTENT: Text readable? Headings hierarchical? Data populated (not placeholder/loading)? Counts/numbers accurate?4. ACCESSIBILITY: Contrast sufficient? Focus indicators visible? Text size adequate? Color-only information?5. INTERACTIVITY: Buttons/links styled consistently? Hover/focus states? Forms labeled? CTAs discoverable?6. BRANDING: Consistent with site theme? Dark/light mode correct? Typography matches design system?Output as JSON array — exactly 6 items, one per criterion:[{"severity": "ok|warning|error", "message": "CRITERION: specific observation with evidence"}]Score 0-10 based on: 0 errors=9+, 1-2 warnings=7-8, errors=5-6, multiple errors=<5.
Per-route evaluation output (6+ items, never a single line):
{ "route": "/dashboard", "score": 7.5, "evaluation": [ {"severity": "ok", "message": "LAYOUT: Content within viewport, no horizontal overflow, grid columns align properly"}, {"severity": "ok", "message": "NAVIGATION: Sidebar present with 8 sections, 'Dashboard' correctly highlighted as active"}, {"severity": "warning", "message": "CONTENT: Stats show '79 skills' but should be '89 skills' — stale count detected"}, {"severity": "ok", "message": "ACCESSIBILITY: Body text ~16px on dark bg (#e6edf3 on #0d1117), contrast ratio ~13:1, passes WCAG AAA"}, {"severity": "warning", "message": "INTERACTIVITY: Code block copy buttons present but no visible hover state change"}, {"severity": "ok", "message": "BRANDING: Dark theme consistent, green accent (#3fb950) used for active states, monospace for code"} ]}
After evaluating all routes, synthesize a summary object for the gallery:
# Build summary from all per-route evaluationssummary = { "total_routes": len(routes), "avg_score": round(sum(r.score for r in routes) / len(routes), 1), "pass_count": len([r for r in routes if r.score >= 7]), "warn_count": len([r for r in routes if 5 <= r.score < 7]), "fail_count": len([r for r in routes if r.score < 5]), "common_issues": [ # Issues appearing on 2+ routes {"count": 3, "message": "Stale skill count (79 instead of 89) on 3/5 pages"}, {"count": 2, "message": "Code block copy buttons lack hover state feedback"} ], "strengths": [ # Positive patterns across routes "Consistent dark theme and typography across all pages", "Sidebar navigation present and correctly highlights active page" ]}
Include this summary in GALLERY_JSON alongside routes.
Trigger: Only when agentation MCP is configured in .mcp.json.
# Check if agentation is availableToolSearch(query="select:mcp__agentation__agentation_get_all_pending")
If available, offer the user:
AskUserQuestion(questions=[{ "question": "Agentation is configured. Want to annotate the UI before finalizing?", "header": "Visual Feedback Loop", "options": [ {"label": "Yes, let me annotate", "description": "I'll mark issues on the live UI, then ui-feedback agent fixes them"}, {"label": "Skip", "description": "Finalize gallery with current screenshots"} ]}])
If yes:
# 1. Watch for annotationsmcp__agentation__agentation_get_all_pending()# 2. For each annotation:mcp__agentation__agentation_acknowledge(annotationId=id)# 3. Dispatch ui-feedback agentAgent(subagent_type="ork:ui-feedback", prompt="Process agentation annotation: {annotation}. Fix the issue, then resolve.", run_in_background=True)# 4. After fixes, re-screenshot affected routes# 5. Save before/after pairs# 6. Update gallery with annotation diffs