Sapere-IASapere-IA/sdd-onboarding-kit/skills/optional/run-and-verify/SKILL.md

run-and-verify

Skill19 starsChanged 38 days agoMITView on GitHub

Run the project and verify behavior using its real commands. Use when validating an implementation, reproducing a bug, or confirming acceptance criteria before review.

In this repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- broSkill
- closingSkill
- context-auditSkill
- decision-logSkill
- dependency-freshnessSkill
- documentation-updateSkill
- failure-learningSkill
- git-disciplineSkill
- goblin-modeSkill
- project-mapSkill
- spec-from-screenshotSkill
- ui-qaSkill
- sdd-updateSkill
- sdd-workflowSkill

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 9 are distinctive, and 1 is very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Run, inspect, and verify the target project using its actual commands and services, so implementation claims ("it works") are backed by …
line 10
Distinctive:
Before marking an implementation task ready for review.
line 27
Distinctive:
When the reviewer validates an implementation against its spec.
line 28
Distinctive:
When required services or credentials are unavailable — record a TODO and say verification was not performed, rather than faking it.
line 35
Distinctive:
Run it; capture actual output.
line 50
Distinctive:
Run the broader applicable checks (tests, lint, typecheck) the project defines.
line 51
Very specific:
Never invent commands; unknown commands are TODO: ask the developer.
line 64
Distinctive:
Do not run destructive operations (migrations, data deletion, deploys) without explicit approval.
line 65
Distinctive:
Never store secrets in this skill, specs, or evidence.
line 67
Distinctive:
Prefer local/test environments.
line 69

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Run and verify

Purpose

Run, inspect, and verify the target project using its actual commands and services, so implementation claims ("it works") are backed by observed behavior instead of assumptions.

This pack is generated, not copied. When selected, the installed skill is produced from templates/run-and-verify.md.template, filled with the target project's real commands: dev server, test (all and targeted), lint, typecheck, build, required services, environment variable names (never values), and UI/API verification steps. Sources: the Phase 1 repository inspection first, then the questions in questions.md §15 for whatever could not be inferred. Unknown commands stay as TODO: ask the developer. This file documents the pack and the generic procedure; the generated file is the one the agent uses in the target project.

When to use

Before marking an implementation task ready for review.
When the reviewer validates an implementation against its spec.
Reproducing a reported bug before fixing it.
Confirming acceptance criteria that describe runtime behavior.

When not to use

Pure documentation or comment changes with no runtime effect.
When required services or credentials are unavailable — record a TODO and say verification was not performed, rather than faking it.

Required inputs

Project commands (from AGENTS.md / the project map): dev server, test, lint, typecheck, build.
Required services and environment variables (names only — values come from the developer's environment, never from this file).
The acceptance criteria or expected behavior being verified.

Procedure

Identify the narrowest check that exercises the change (targeted test, single route, one CLI invocation).
Run it; capture actual output.
Run the broader applicable checks (tests, lint, typecheck) the project defines.
Compare observed behavior against the spec's acceptance criteria.
Report honestly: what ran, what passed, what failed (with output), what could not be verified and why.

Output artifact

Verification evidence in the task's review notes (review.md) or the implementation summary: commands run, results, and unverified items.

Safety constraints

Never invent commands; unknown commands are TODO: ask the developer.
Do not run destructive operations (migrations, data deletion, deploys) without explicit approval.
Never store secrets in this skill, specs, or evidence; reference variable names only.
Prefer local/test environments; never verify against production without explicit instruction.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free