sdd-verify

Runs dev servers, test suites, and browser scenarios to produce runtime verification evidence.

1|Updated Jul 26, 2026
One-click install
npx skills add https://github.com/AngeloResplandes/harness-sdd --skill sdd-verify-angeloresplandes
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sdd-verify
Source: https://github.com/AngeloResplandes/harness-sdd/tree/main/sdd-verify
Command: npx skills add https://github.com/AngeloResplandes/harness-sdd --skill sdd-verify-angeloresplandes

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) and assets (resource) components.

What problem does it solve? Code that was written is not code that runs. This Skill closes the gap between "implementation complete" and "actually works" by starting the dev server, running the test suite, exercising each scenario in a real browser, and recording per-scenario evidence in a verification.md file — without ever fixing what it finds. ## Core Features & Use Cases - Runtime command resolution: Discovers how to start the server and run tests from plan.md, spec/architecture.md, or the project manifest (package.json, pyproject.toml, Makefile, Cargo.toml, and more), never guessing commands. - Test suite execution with honest reporting: Records the exact command, real failure output, passed/failed/skipped totals, and duration; names skipped tests individually and maps each scenario to the test that actually covers it. - Browser scenario verification: Drives scenarios from scenarios.feature via Playwright, Cypress, a browser MCP, or a scripted manual pass, capturing screenshots and console errors. - Strict no-fix invariants: Never edits code, never writes inside spec/, and never installs browser automation stacks — failures are recorded and handed back to the implementation phase. - Use Case: After a cycle's tasks are checked off, ask it to verify the cycle; it starts the server, runs the tests, exercises each scenario, and writes verification.md as evidence for the validation phase. ## Quick Start Verify the latest cycle by running the dev server, executing the test suite, and exercising each scenario in the browser, then write the results to verification.md.

Frequently Asked Questions about sdd-verify

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify that implemented code actually works before delivery?

Run the test suite first, then start the dev server and exercise each planned scenario in a real browser using Playwright, Cypress, or a manual scripted pass. Record per-scenario observed results, console errors, and test totals in a verification report rather than relying on code reading.

How to run a dev server and test it in a browser with Playwright?

First check whether playwright.config already defines a webServer block — if so, let the runner manage the server lifecycle. Otherwise start the server detached with output redirected to a log file, poll the log for the bound URL, then drive each scenario and capture screenshots.

Why does Playwright fail with 'port is already used' during E2E tests?

This happens when you start a dev server that the Playwright webServer config also manages, especially with reuseExistingServer set to false. Kill your manually started server and let the test runner own the server lifecycle instead.

Why does Vitest report Playwright E2E test files as failed?

Vitest's default glob picks up Playwright specs it cannot execute, producing 'Playwright Test did not expect test() to be called here' errors. Check the Tests count rather than Test Files — the fix is an exclude entry in the Vitest config, not a code change.

Can this skill fix failing tests or install Playwright automatically?

No. It never edits code, writes inside spec/, or installs browser automation stacks, because a verification phase that repairs what it finds is measuring its own repairs. Failures are recorded with real output and handed back to the implementation phase.

What should I do when a scenario cannot be tested in my environment?

Mark it as NÃO VERIFICADO with the reason, such as needing production data or a third-party account. An honest unverified result is a legitimate outcome; inferring success from code reading is not acceptable evidence.