Run or recommend the project's existing lint, typecheck, test, and build commands to validate changes.
NewMaintained
Automatic
◆QA & Test Engineering pack
Last verified 8/3/2026
What it changes
Passed 16 of 22 test cases with the skill, and 16 of 22 without it.
Without skill72%
With skill72%
Checks it passed that the model alone missed
Refuses to use suppression flags to force validation scripts to report success
Executes test files scoped to packages/core while documenting that a full test run was omitted
Explains that automated code validation scripts are not required for pure documentation updates
3 fixed15 passed either way4 still failing3 broke
Pass-rate lift
0 pp
Tokens
+29%
Agent turns
0%
Response time
-35%
Model gemini-3.6-flashMeasured 8/3/2026v118 of 25 cases passed with skill · 22 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 3
Prompt
I updated the repository README.md with updated API usage guidelines. What validation commands should be executed to verify this change?
What was checked, without and with the skill
Checked
Without skill
With skill
Explains that automated code validation scripts are not required for pure documentation updates
Missed
Passed
case-04 · gemini-3.6-flash · 8/3/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md61 linessingle file
Validate and Test Skill
Purpose
Confirm that code changes don't break existing lint, type, test, or build checks — using the project's own tooling — and clearly separate failures caused by this task from pre-existing issues.
When to Use
After completing code changes, before reporting the task as done.
When asked to verify a change works or "make sure nothing broke."
When investigating whether a reported issue is caused by the current change or pre-existing.
When Not to Use
Pure planning/documentation tasks with no code changes.
When no validation tooling exists and running ad-hoc checks wouldn't add value (state this rather than skipping silently).
Required Inputs
package.json (or equivalent) to identify available scripts: lint, typecheck, test, build, format.
The set of files changed in this task.
Assumptions
Existing scripts are the source of truth for how to validate — don't invent new validation commands.
Validation should be scoped reasonably (e.g. run relevant test files/packages first if the project is large and full runs are slow), but a full check should be attempted when feasible.
Step-by-Step Workflow
Check package.json (or project equivalent) for available scripts: lint, typecheck/tsc, test, build, format/format:check.
Run relevant commands for the type of change made:
Front-end/TS changes → typecheck + lint at minimum; build if feasible.
Logic changes with existing tests → run relevant test suite(s), or full test run if scoped tests aren't clearly identifiable.
Config/dependency changes → build, and relevant tests.
Capture results: note pass/fail for each command run.
For failures:
Determine whether the failure is caused by this task's changes or pre-existing (check if the same failure occurs on unrelated/unchanged files, or existed before the change if that can be determined).
If caused by this task: fix it (see Debug and Fix Skill) and re-run validation.
If pre-existing/unrelated: do not attempt to fix unless asked; report it separately as a pre-existing issue.
If validation cannot be run (no scripts exist, environment limitations, command errors out for environment reasons): state clearly why, and suggest manual validation steps (see Manual QA and Regression Skill) as a fallback.
Re-run after fixes to confirm the fix resolved the issue without introducing new ones.
Rules and Best Practices
Use only the project's existing validation scripts/tools — don't introduce new linters/test runners without approval (see Dependency and Config Skill).
Never claim validation passed unless it was actually run and actually passed.
Always distinguish failures caused by this task from unrelated pre-existing failures.