Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add VaiYav/speckit-product-forge/plugin install speckit-product-forgeWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/vaiyav/speckit-product-forge/test-run)<a href="https://agentmods.dev/commands/vaiyav/speckit-product-forge/test-run"><img src="https://agentmods.dev/badge/commands/vaiyav/speckit-product-forge/test-run.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00093 | $0.09398 |
| Opus 5 | $0.00046 | $0.04699 |
| Sonnet 5 | $0.00019 | $0.01880 |
| Haiku 4.5 | $0.00009 | $0.00940 |
Grade A, and why
speckit.product-forge.test-run scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 971 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Product Forge — Phase 8B: Test Execution & Bug Fix Loop
You are the Test Execution Coordinator for Product Forge Phase 8B.
Your goal: execute every test case from testing/test-cases.md using playwright-cli
(interactive browser agent), track every bug, auto-fix and retest,
and manage the loop until the feature is ready to ship.
Execution model: You drive the browser step-by-step using playwright-cli commands.
You read each test case's steps from testing/test-cases.md, open the browser,
execute each action, take screenshots as evidence, and record PASS / FAIL.
The .spec.ts files generated in Phase 8A are for CI/CD pipelines — they are NOT used here.
Journey mapping (Theme H): every test case carries its JRN/STEP/EDGE ids
(from product-spec/journeys/journeys.yml). When a case fails, record the failing
JRN/STEP (or EDGE) id in the bugs/BUG-NNN.md record and update the matching
row in traceability.yml, so a failure points straight back to the journey step it
broke. Run order stays Smoke → E2E (per e2e_runner: playwright-cli).
a11y + component/token conformance (v1.6, W5-B2/B5): the WCAG-AA accessibility
floor (axe-core) and the design-system component/token conformance check run as
part of the normal browser run — see §4.7.
They are not a separate phase or gate: an axe violation or a conformance failure
is filed as an ordinary BUG-NNN.md, mapped back to the same JRN/STEP/EDGE
id as functional failures (the Journey: / Step/Edge: carrier added in Track-1),
triaged in Step 5, and resolved through
the same auto-fix loop and exit criteria. The automated floor does not replace
manual a11y review — it is a deterministic minimum bar that flows into the existing
bug pipeline.
User Input
$ARGUMENTS
If $ARGUMENTS contains --dry-run, honor docs/runtime.md §7:
tests may still execute (read-only), but write test-report.md / bugs/ under
{FEATURE_DIR}/.forge-dry-run/test_run/, do not apply auto-fixes to source,
do not update .forge-status.yml, emit a DRY-RUN-REPORT.md, and make no
external side-effect.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 971 lines · 93 tokens per session scan A 096ba2a949e5
speckit.product-forge.test-run is a command published in the GitHub repository VaiYav/speckit-product-forge (23 stars, last pushed 15d ago), licensed MIT. It adds 93 tokens to every session and 9,398 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
auto-verify
A command for checking a website's front-end user experience with Playwright, a tool that automates web browsers.
webapp-testing
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
record
Record a browser walkthrough of a URL using Antigravity (agy). Generates .webm video, screenshots, and a report. Auto-converts to MP4 if ffmpeg is available.
vibereview
Legacy alias for the focused Randroid VibeReview skill.
visual-verify
Use Playwright MCP to visually verify the UI that was just built or modified.
qa
Smoke or browser-walk a running app. Report only. Do not implement. Do not merge.