Pe Verify

Verify

Proof that behavior works. This spine routes; the report contract, the QA-list conventions, and the capture method live in references/ — load what the run needs.

Contract (both modes)

• Read-only toward product code. A failed check is reported, never fixed here; hand it to the pe-build skill by name. The only repo write this skill ever makes is the user's QA list, and only when the user asks to seed or edit it.
• Everything a run produces lands in a temp folder: pe-verify/<repo>/<YYYY-MM-DD-HHMM>/ under the system temp directory ($TMPDIR, else /tmp) — JSON, HTML, recordings, screenshots. Never inside the repo, never committed. Copy report.json into .product/runs/ only on an explicit request.
• One JSON file is the deliverable. Never write HTML. This skill's scripts/render-report.py turns report.json into report.html beside it; validate first, render, then open it (--open) and print the path. The contract is references/report-schema.md.
• Evidence or it is not a finding. Every fail and flag carries a file:line, a recording timestamp, or the command that showed it.
• A missing browser skips, never blocks. The orchestrator checks for a browser once, in Scope, and may offer the install there; workers never prompt. Browser items without a browser report skipped with the reason; code items still run.

Modes

A list run is selective or all, and the report says which (selection is required for list runs). Selective: the agent chooses the entries the change set can affect, names the basis (selection_basis), and reports every other entry as not-run with its reason. All: every entry runs. Precedence: "all", "everything", "every check" from the user → all; otherwise a named change set ("against this PR", "since v0.17") → selective; otherwise → all. Say which in the chat report, and switch when asked. An entry is never left out of the report.

A feature run is one item: the feature, with its checks as checkpoints (browser) and findings (code), and one verdict. When the derived checks need separate verdicts — three independent behaviors, each able to fail on its own — run a list-mode report with list_source: null and the feature as the title.

Classify every check

Decide per item, at run time. A list entry may carry a hint ("— browser"); most do not.

• code — read, trace, run tests or commands; no browser. "Bun is still pinned to 1.3.x", "no config-breaking changes in this release", "the install script still targets both paths".
• browser — Playwright drives the product and records it. "Annotating HTML works headlessly", "every toolbar button is present", "the diff loads on a 2MB file".
• mixed — both: a behavior in the browser plus the code path behind it.

In feature mode and when selecting, bias is liberal: run any check the change can plausibly affect. skipped means the check could not be run (no browser, no fixture, no access) and its summary says why; choosing not to run an entry is not-run, which exists only in selective runs.

Orchestrate with what exists

Use the running harness as it is: parallel subagents when they exist, a cheaper model for quick code checks and a stronger one for browser or multi-step checks where the choice exists, sequential execution when nothing else is available. Never require a specific harness, model, or workflow engine. Each worker returns its item as a JSON fragment shaped by the contract; the orchestrator assembles report.json, sets checked_by on each item, validates, renders.

Steps

1. Scope. Name the mode, the target (a feature, or the list and its path), the commit, and how the product will be reached (local server, built artifact, CLI). Check that Playwright has a browser; when it does not, offer npx playwright install chromium in one line and continue with whatever answer comes — no answer means browser items skip.
2. Classify each check as above.
3. Run. Browser items per references/evidence.md: a recording, three to six checkpoints with stills, one-line narration each. Code items: the command or the trace, captured as evidence.
4. Assemble report.json in the run folder, then, with <skill> as this skill's installed folder and <run> as the run folder: python3 <skill>/scripts/validate-report.py <run>/report.json — fix every listed problem — then python3 <skill>/scripts/render-report.py <run>/report.json --open.
5. Report in chat: the path, the selection and its basis for list runs, counts by status, and one line per fail or flag. Fails go to pe-build with their evidence.

Handoffs

Fixes → pe-build. Judgment of quality — does it look right, is the motion good, is it accessible — → pe-review. Whether the build matches the approved mock → pe-review, fidelity mode. Documenting the behavior that was verified → pe-product-description.