Verify

Use this skill to prove whether a claim, code change, bug fix, test result, workflow, product issue, or release/readiness assertion is actually correct. Quire is the independent read-only QA, verification, and triage agent for this workflow. Quire does not implement fixes. Quire reports pass, fail, blocked, or partial results honestly with evidence.

If your harness exposes a native subagent named quire, delegate the verification or reproduction brief to that subagent and wait for its terminal handoff. This is mandatory when available. Quire performs deep verification: a normal Run can easily exceed five minutes and may take considerably longer, so elapsed time or a short task/client timeout is not evidence of failure. The skill's job is to recognize that independent evidence is needed; the quire subagent's job is to run the Quire CLI, wait patiently to a terminal status, and return the evidence-backed handoff.

Use CLI fallback only when no native quire subagent is available. Do not run the Quire CLI directly from the parent session when a native quire subagent is available.

If the caller asks whether the Quire agent/subagent path was used, answer from your actual invocation path. If you used a native quire child task/subagent, report that the native Quire subagent path was used even when the returned run metadata describes an older internal harness such as pi, Codex, or another agent. Treat old run metadata as separate historical context, not as evidence that the current adapter path was not used.

When communicating Quire results to the user, use Quire's terminal handoff substantially intact as the primary body of the response rather than replacing it with a compact summary or excerpt. A short parent-facing header may add the run id, synced Quire run link, verdict, and counts, but retain the handoff's evidence references, blockers, known non-regressions, and next actions so the parent and user receive the context Quire produced.

Use this skill when the user asks to verify, QA, smoke test, validate, prove a fix, check a workflow, reproduce a visible product issue, ask Quire, run Quire, or get a Quire run id/verdict/handoff.

Also use Quire before declaring non-trivial coding work complete when independent verification would materially increase confidence, especially for UI/workflow changes, bug fixes, failing or flaky tests, auth, security, permissions, billing, data loss, migrations, concurrency, integrations, mobile behavior, or release-readiness work.

Do not use Quire for every tiny task. Usually skip independent verification for purely conversational answers, simple docs/formatting edits, trivial mechanical changes where local checks are enough, or repeated verification of the same unchanged diff. Exception: if the user explicitly asks for Quire or independent verification, use Quire anyway.

If the caller explicitly asks for Quire or independent verification, do not substitute your own direct checks, web fetches, curl commands, tests, browser checks, or manual reasoning and claim that is equivalent. You may do basic preparation, but Quire itself must be invoked.

When Quire owns reproduction or verification, avoid duplicating the same checks yourself while it is running. Do not run parallel curl/browser/source-tracing/build checks for the same claim just because Quire is still active. Wait for the handoff, then use your own commands only to implement the fix, handle a Quire-blocked gap, or do a final narrow packaging check the project requires.

• Claim/change/bug to verify:
• Target URL, command, app, route, screen, or environment:
• Relevant files/paths or PR context:
• Commands already run:
• Expected behavior:
• Known risks or edge cases:
• Evidence to capture: screenshots, browser console, network, CLI output, mobile state, logs, deterministic checks, or handoff summary.
• Constraints: read-only verification; do not edit code; production mutation safety.

Use CLI fallback only when the native quire subagent is unavailable.

For a new verification or reproduction run, invoke one attached Run and let it continue through the terminal handoff:

quire run --url "<url>" "<verification request>"

If there is no URL, omit --url and include target context in the natural-language request. Bare attached quire run prints the run id, streams progress, and finishes by printing the terminal handoff.

If the caller provides an existing Quire run id, or the attached output was interrupted after the run id was printed, do not start a new run and do not use quire status as the final result. Reattach to the same durable run:

quire watch "<run-id>"

Use the synced Quire run URL printed by quire run or quire watch as the shareable evidence URL when present.

Terminal statuses are completed, failed, canceled, and stale. Wait patiently: Quire is another agent doing deep QA work, can easily exceed five minutes, and may take considerably longer. A short task/client timeout or elapsed time is not evidence of failure. Keep the attached invocation running when possible; if it is interrupted, resume the same run with quire watch "<run-id>" rather than canceling it or starting a duplicate for the same claim.

If Quire reports EROFS, EACCES, or another write error under ~/.local/share/quire/runs, your agent sandbox likely made the default run store read-only. Retry with a temporary run store and reuse the same value when reconnecting:

quire_runs_dir=$(mktemp -d -t quire-runs-XXXXXX)
QUIRE_RUNS_DIR=$quire_runs_dir quire run --url "<url>" "<verification request>"
# If the attached output is later interrupted:
QUIRE_RUNS_DIR=$quire_runs_dir quire watch "<run-id>"

For user-reported bugs on real product surfaces, the ideal loop is:

1. Use Quire to reproduce the symptom and identify the failing surface, request, console/runtime error, command, or workflow boundary.
2. Wait for Quire's reproduction handoff before doing your own code tracing unless the user explicitly asks you to investigate in parallel or the run is blocked.
3. Make the smallest code/config/content fix informed by that evidence.
4. Use Quire again against the fixed local/preview target to verify the original symptom is gone. Treat unrelated warnings or secondary issues as follow-up notes unless they caused the reported bug or block verification.

• Native Quire adapter invocation: yes/no/unavailable, with evidence.
• Verdict: pass, fail, blocked, partial, or setup-blocked.
• Quire run id.
• Quire web URL when present.
• What Quire verified or reproduced, including checks run and pass/fail/blocked counts when available.
• Quire terminal handoff substantially intact, including its key evidence, artifacts, screenshots, recordings, traces, blockers, and known non-regressions.
• Follow-up actions from the handoff for the implementation agent.