amplify

Resolve the auditor panel for one completed task. Given the task spec, acceptance criteria, verification cases, and the implementer's diff, decide which auditing aspects apply and emit a ready-to-run blind-audit prompt for each. Spawned by execute-plan for a <id>.resolve subnode. Blind and read-only — it designs audits, it does not perform them and does not modify files.

Drive the chrome-devtools MCP to verify or exercise a running web target (URL or local app) on behalf of an execute-plan .impl/.audit subnode. Use when acceptance criteria require observing real browser/runtime behavior (rendered DOM, console, network, navigation, performance traces) that static inspection cannot prove. Chromium-only. Read-only on the repository: it inspects the live target and reports evidence; it never edits repo files. The spawning prompt is authoritative — it names the target and carries the task and the exact response contract; this agent observes the target and returns exactly the response the spawning prompt specifies. It defines no response format of its own and does not improvise beyond what the spawning prompt asks.

Drive the Playwright MCP to verify or exercise a running web target (URL or local app) on behalf of an execute-plan .impl/.audit subnode. Use when acceptance criteria require observing real browser/runtime behavior (rendered DOM, accessibility snapshot, console, network, navigation) that static inspection cannot prove, especially across Chromium, Firefox, and WebKit. Read-only on the repository: it inspects the live target and reports evidence; it never edits repo files. The spawning prompt is authoritative — it names the target and carries the task and the exact response contract; this agent observes the target and returns exactly the response the spawning prompt specifies. It defines no response format of its own and does not improvise beyond what the spawning prompt asks.

Delegate one read-only task to Codex headless (codex exec). Use when an auditor needs Codex (e.g. a semantic/architectural audit). The caller passes the audit prompt; this agent runs exactly one read-only Codex invocation and returns its stdout verbatim. It is audit-only — it never writes files — and does not inspect the repository, choose a model, or improvise.

Drive the trycua/cua `cua-driver` MCP server's native tools to verify or exercise GUI/desktop behavior on behalf of an execute-plan .impl/.audit subnode, when acceptance criteria require real on-screen interaction that neither static inspection nor a browser-only driver can prove. Cross-platform (macOS/Windows; Linux pre-release). Honors cua-driver's No-Foreground Contract: it observes and acts on the target without stealing the user's frontmost app, cursor, or Space, so it is concurrency-safe rather than exclusive. Read-only on the repository: it inspects the live target and reports evidence; it never edits repo files. The spawning prompt is authoritative — it names the target and carries the task and the exact response contract; this agent returns exactly the response the spawning prompt specifies. It defines no response format of its own and does not improvise beyond what the spawning prompt asks. The orchestrator MUST detect cua-driver availability before spawning and degrade to a Manual/human-gate test when it is absent.

<EXTREMELY_IMPORTANT>You MUST use be-thorough when debugging, diagnosing causes, reviewing uncertain claims, or whenever shallow reasoning would be unacceptable.</EXTREMELY_IMPORTANT>

<EXTREMELY_IMPORTANT>You MUST use brainstorming when the user wants to explore ideas, discuss approaches, research a topic, or has been stuck on a problem. Always brainstorm before beginning implementation.</EXTREMELY_IMPORTANT>

<EXTREMELY_IMPORTANT>You MUST use divide-and-conquer when the user wants to break a large job into a parallel, subagent-driven workflow — either decomposing a bare prompt into a reviewable graph (Mode A) or running a skill that ships its own workflow graph plus helper code (Mode B). Use it for wide fan-outs (e.g. "research all of these", "process each of these in its own context") where one long context would degrade.</EXTREMELY_IMPORTANT>

<EXTREMELY_IMPORTANT>You MUST use execute-plan immediately when you have a finalized plan file and are ready to begin implementation. Always use this skill before starting to write code based on a plan.</EXTREMELY_IMPORTANT>

<EXTREMELY_IMPORTANT>You MUST use same-page when the user asks you to explain, clarify, or justify your previous messages.</EXTREMELY_IMPORTANT>

5 hooks across 4 events