Test

Name: Test
Author: owainlewis

ASecurity

Proves that a code change meets its acceptance criteria. Uses focused automated checks and a real browser for browser-facing work. Use to test or verify a diff, branch, PR, URL, or user flow.

412 stars

0 votes

0 copies

0 views

Added 10/6/2026

development

Security Analysis

A100/100

Scanned 10/6/2026

$npx -y skills add owainlewis/blueprint --skill test --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Test?

Add the live security badge to your README — it updates automatically with every re-scan.

[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/owainlewis-test/badge)](https://www.skillsdirectory.com/skills/owainlewis-test)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro

Files

SKILL.md

---
name: test
description: "Proves that a code change meets its acceptance criteria. Uses focused automated checks and a real browser for browser-facing work. Use to test or verify a diff, branch, PR, URL, or user flow."
user-invocable: true
argument-hint: "<task, acceptance criteria, diff, branch, PR, URL, or flow>"
---

# Test

Prove the behavior that matters. A passing build or a source-code reading can support the proof, but neither proves a user-visible flow.

## Process

1. Read the task, its source spec when present, changed code, existing tests, and repository instructions. Acceptance criteria come from the task or reviewed spec. Preserve their wording and `AC-n`, `REQ-n`, or `INV-n` IDs. Never rewrite criteria to match the code.
2. Map every acceptance criterion, cited invariant, and affected failure path to proof by ID. Test changed behavior and behavior a refactor must preserve.
3. If automated tests cannot exercise the affected behavior, explain why and give other evidence.
4. Add or update focused tests where proof is missing. Assertions should fail when the changed behavior breaks.
5. Assert behavior a user or caller can observe unless the test targets a documented internal contract. Keep setup and assertions no more complex than the scenario.
6. Run the narrowest checks that exercise the changed behavior and affected interfaces. Run wider checks when shared behavior or interfaces changed.
7. When browser-rendered behavior changes, start the documented app and check the required flows and affected failures in a real browser.
   - Check desktop and mobile when layout or responsive styles changed.
   - Check keyboard use when interactions changed.
   - Check console errors and failed requests during every flow.
   - Capture evidence. Reading source is not browser proof.
8. Report each `AC-n`, `REQ-n`, `INV-n`, or task criterion as pass, fail, or unverified. Include the command, browser flow, or other evidence.

## Return

Report each criterion in this shape:

```text
Criterion: <ID or exact wording>
Result: Pass / Fail / Unverified
Evidence: <command, browser flow, or artifact>
Gap: <what remains unknown, or None>
```

Lead with failures and unverified criteria. Do not hide them below passing checks.

## Boundaries

- Do not weaken assertions to make a change pass.
- Do not fix unrelated failures.
- If required browser tooling is unavailable, report the check as blocked unless the user explicitly accepts a manual exception.

Attribution

owainlewis

View source See grades on GitHub More from owainlewis →

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

--- name: test description: "Proves that a code change meets its acceptance criteria. Uses focused automated checks and a real browser for browser-facing work. Use to test or verify a diff, branch, PR, URL, or user flow." user-invocable: true argument-hint: "<task, acceptance criteria, diff, branch, PR, URL, or flow>" --- # Test Prove the behavior that matters. A passing build or a source-code reading can support the proof, but neither proves a user-visible flow. ## Process 1. Read the task, its source spec when present, changed code, existing tests, and repository instructions. Acceptance criteria come from the task or reviewed spec. Preserve their wording and `AC-n`, `REQ-n`, or `INV-n` IDs. Never rewrite criteria to match the code. 2. Map every acceptance criterion, cited invariant, and affected failure path to proof by ID. Test changed behavior and behavior a refactor must preserve. 3. If automated tests cannot exercise the affected behavior, explain why and give other evidence. 4. Add or update focused tests where proof is missing. Assertions should fail when the changed behavior breaks. 5. Assert behavior a user or caller can observe unless the test targets a documented internal contract. Keep setup and assertions no more complex than the scenario. 6. Run the narrowest checks that exercise the changed behavior and affected interfaces. Run wider checks when shared behavior or interfaces changed. 7. When browser-rendered behavior changes, start the documented app and check the required flows and affected failures in a real browser. - Check desktop and mobile when layout or responsive styles changed. - Check keyboard use when interactions changed. - Check console errors and failed requests during every flow. - Capture evidence. Reading source is not browser proof. 8. Report each `AC-n`, `REQ-n`, `INV-n`, or task criterion as pass, fail, or unverified. Include the command, browser flow, or other evidence. ## Return Report each criterion in this shape: ```text Criterion: <ID or exact wording> Result: Pass / Fail / Unverified Evidence: <command, browser flow, or artifact> Gap: <what remains unknown, or None> ``` Lead with failures and unverified criteria. Do not hide them below passing checks. ## Boundaries - Do not weaken assertions to make a change pass. - Do not fix unrelated failures. - If required browser tooling is unavailable, report the check as blocked unless the user explicitly accepts a manual exception.