How do I install the Evidence Driven Testing skill?

Run npx skillmds@latest add the-utopia-studio/evidence-driven-testing in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Evidence Driven Testing safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Evidence Driven Testing?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Evidence Driven Testing free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Evidence Driven Testing?

The-Utopia-Studio (@the-utopia-studio) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Evidence Driven Testing by the-utopia-studio

Name: Evidence Driven Testing
Author: The-Utopia-Studio

Evidence Driven Testing

Records visual proof while testing UI behavior — screen recording with structured test/assertion annotations — then posts the video and a results summary to the PR and tracker issue. Use whenever a UI change needs verifiable evidence that it works, instead of prose claims.

File contents

Evidence-Driven Testing

Record annotated screen-recording proof of UI behavior, then attach it to the PR and tracker issue.

Inputs

Test targets (required): The behaviors/flows to verify, phrased as testable statements.
PR / issue (optional): Where to post the evidence. If omitted, deliver to the requester only.

Instructions

1. Prepare the screen

Maximize the browser/app window; close popups, notifications, and extra panels.
Navigate to the starting state (logged in, correct page) BEFORE recording, unless setup itself is under test.

2. Start recording

Begin the screen recording before the first meaningful action.
Add a setup annotation describing the starting context, e.g. "Logged in, navigating to connectors page".

3. Annotate as you test

At each named test's start, add a test_start annotation in Jest style: It should execute the tool directly when permission is 'always'.
After each check, add an assertion annotation with result passed, failed, or untested.
Rules for assertions:
- One assertion per meaningful state change — consolidate, don't annotate per UI label.
- Use "Precondition: ..." assertions to establish starting state.
- Keep under ~80 characters, high-signal.
- If a test cannot run (missing prerequisite, expired auth window), mark it untested with the reason — never skip silently.

4. Stop and review

Stop recording after the final assertion.
Confirm the recording captured the key moments before sharing.

5. Post the evidence

Write a short report: what was tested, environment + exact commit, pass/fail per test, caveats.
Post the video + summary as a PR comment (embed in the PR description if it's your PR).
Attach the same video to the tracker issue (Linear/Jira) with a one-line result.
Send the report + recording to the requester.

Guardrails

Never record a half-covered or tiled window — maximize first.
When verifying a fix, show or reference the old failure alongside the new success.
Always state the exact commit/branch/deployment tested against.

---name: evidence-driven-testingdescription: Records visual proof while testing UI behavior — screen recording with structured test/assertion annotations — then posts the video and a results summary to the PR and tracker issue. Use whenever a UI change needs verifiable evidence that it works, instead of prose claims.---# Evidence-Driven TestingRecord annotated screen-recording proof of UI behavior, then attach it to the PR and tracker issue.## Inputs- **Test targets** (required): The behaviors/flows to verify, phrased as testable statements.- **PR / issue** (optional): Where to post the evidence. If omitted, deliver to the requester only.## Instructions### 1. Prepare the screen- Maximize the browser/app window; close popups, notifications, and extra panels.- Navigate to the starting state (logged in, correct page) BEFORE recording, unless setup itself is under test.### 2. Start recording- Begin the screen recording before the first meaningful action.- Add a `setup` annotation describing the starting context, e.g. "Logged in, navigating to connectors page".### 3. Annotate as you test- At each named test's start, add a `test_start` annotation in Jest style: `It should execute the tool directly when permission is 'always'`.- After each check, add an `assertion` annotation with result `passed`, `failed`, or `untested`.- Rules for assertions: - One assertion per meaningful state change — consolidate, don't annotate per UI label. - Use "Precondition: ..." assertions to establish starting state. - Keep under ~80 characters, high-signal. - If a test cannot run (missing prerequisite, expired auth window), mark it `untested` with the reason — never skip silently.### 4. Stop and review- Stop recording after the final assertion.- Confirm the recording captured the key moments before sharing.### 5. Post the evidence- Write a short report: what was tested, environment + exact commit, pass/fail per test, caveats.- Post the video + summary as a PR comment (embed in the PR description if it's your PR).- Attach the same video to the tracker issue (Linear/Jira) with a one-line result.- Send the report + recording to the requester.## Guardrails- Never record a half-covered or tiled window — maximize first.- When verifying a fix, show or reference the old failure alongside the new success.- Always state the exact commit/branch/deployment tested against.

Frequently asked questions