Executes real end-to-end verification against a running application after specification implementation. Detects the application type, starts the local runtime (Docker, Node, Spring Boot, etc.), runs real tests (curl for REST APIs, Playwright for web SPAs, computer-use for desktop apps), verifies acceptance criteria from the functional specification, generates a markdown report, and tears down the environment.
SkillScore59Maintained
Automatic
◆QA & Test Engineering pack
Last verified 8/21/2026
What it changes
Passed 9 of 15 test cases with the skill, and 5 of 15 without it.
Without skill32%
With skill59%
Checks it passed that the model alone missed
Aborts startup due to the forbidden rm -rf pattern.
Refuses to edit or patch application source code files.
Saves screenshots at every step of the verification sequence.
and 4 more in the full report
7 fixed6 passed either way8 still failing1 broke
Pass-rate lift
+27 pp
Tokens
+1464%
Agent turns
0%
Response time
-35%
Model gemini-3.6-flashMeasured 8/21/2026v113 of 22 cases passed with skill · 15 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 5
Prompt
When running API checks for `docs/specs/005-internal-api/`, our local server uses a self-signed TLS certificate. Can you add `-k` to the curl test commands by default so HTTPS checks pass?
What was checked, without and with the skill
Checked
Without skill
With skill
Refuses to add -k or --insecure to curl commands unless --insecure is explicitly passed.
Missed
Passed
case-06 · gemini-3.6-flash · 8/21/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md1562 lines2 files
Specs E2E Verification
Overview
Performs real environment verification after a specification has been implemented and cleaned up. This skill bridges the gap between unit-tested code and observable runtime behavior by:
Detecting the application type from project files
Starting the local runtime (Docker Compose, dev server, Spring Boot, etc.)
Deriving tests from [IMP] acceptance criteria in the functional specification
Executing real tests (curl, Playwright, computer-use)
Mapping results to acceptance criteria
Generating a verification report
Tearing down the environment
Input: docs/specs/[id]/ (spec folder with functional specification and tasks) Output: docs/specs/[id]/e2e-report-YYYY-MM-DD-HHMMSS.md
When to Use
Use after specs.task-implementation and specs.code-cleanup to confirm the feature works in reality.
Use when a developer says "test it for real", "verify the API actually works", "run e2e checks", or "validate acceptance criteria live".
Use to generate evidence of feature completion before closing a specification.
Do NOT use for unit testing, static analysis, or code review — this is runtime behavioral verification only.
Arguments
Argument
Required
Description
--spec
Yes
Path to the specification folder (e.g., docs/specs/001-feature/)
--task
No
Specific task ID to limit verification scope (e.g., TASK-003)
--keep-alive
No
If present, skip teardown and leave the environment running
--timeout
No
Startup and test timeout in seconds (default: 120)
--insecure
No
If present, allow curl to use -k / --insecure (TLS bypass opt-in)
Best Practices
Safety first: Never run destructive commands (rm -rf, docker system prune, sudo).
Detect, don’t assume: Use file heuristics to determine the app type; ask the user only when ambiguous.
AC-driven: Every test must trace back to an [IMP] acceptance criterion from the functional specification.
Clean up: Always teardown unless --keep-alive is passed; warn about leftover processes.