verify

Estrelas8

Forks0

Atualizado21 de março de 2026 às 21:03

Use after making code changes, before committing, or before claiming work is done. Runs type-check → lint → test → build and fixes failures immediately.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Fonte

chinmaymk

chinmaymk/ra

Abrir repositório GitHub Ver repositórios do creator

Download

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·SOC 15-1253

SKILL.md

readonly

name	verify
description	Use after making code changes, before committing, or before claiming work is done. Runs type-check → lint → test → build and fixes failures immediately.

You verify your work before claiming it's done. Never say "the changes are complete" without evidence.

When to Verify

After every meaningful code change — run the relevant test suite
Before committing — type-check and lint
After fixing a bug — run the failing test, then the full suite
After refactoring — run the full suite to catch regressions

Verification Steps

Run these in order. Stop on first failure and fix before continuing.

1. Type Check (if applicable)

# TypeScript
bun tsc --noEmit
# or npx tsc --noEmit

# Python
mypy . || pyright .

2. Lint

# Check package.json scripts for lint command
# Common: bun run lint, npm run lint, cargo clippy, go vet

3. Tests

# Check package.json scripts for test command
# Common: bun test, npm test, cargo test, go test ./..., pytest

4. Build (if the project has a build step)

# Common: bun run build, npm run build, cargo build

Rules

Discover the right commands first. Read package.json, Makefile, Cargo.toml, etc. Don't guess.
Run the narrowest test first. If you changed foo.ts, run foo.test.ts before the full suite.
Read the full output. Don't just check exit code — read error messages, warnings, and failed test names.
Fix failures immediately. Don't report them to the user and wait. Fix them, then verify again.
"Almost passing" is not passing. 99/100 tests passing means it's broken.
Don't skip verification because "the change is small." Small changes cause big bugs.

When Verification is Blocked

If the project has no tests, no type-checker, and no linter:

Do a manual review — re-read your changes for obvious errors
Trace the logic mentally with example inputs
Tell the user verification is limited and suggest adding tests

Output

After verification, summarize briefly:

Type check: pass
Lint: pass
Tests: 42/42 passing

Or if something failed:

Tests: 41/42 passing — `test_auth_flow` failing (assertion error on line 58)
Fixing...

Mais deste repositório

mesmo repositório

architect

chinmaymk/ra

System design and architecture decisions. Use when planning new features, evaluating trade-offs, or designing how components should connect. Proposes 2-3 approaches and recommends one.

2026-04-068

commit

chinmaymk/ra

Smart commit workflow. Reviews staged changes, writes conventional commit messages, and catches issues before committing. Use when ready to commit work.

2026-04-068

critic

chinmaymk/ra

Quality review of completed work. Use after making changes and before claiming completion. Reviews code for correctness, edge cases, security, and maintainability.

2026-04-068

debugger

chinmaymk/ra

Systematic debugging workflow. Use when diagnosing bugs, test failures, or unexpected behavior. Follows a rigorous reproduce → isolate → hypothesize → fix → verify cycle.

2026-04-068

deep-research

chinmaymk/ra

Systematic multi-agent research. Use when you need to deeply investigate a topic, codebase, or question by spawning parallel research agents and synthesizing their findings.

2026-04-068

explain

chinmaymk/ra

Deep code explanation. Use when you need to understand or explain how a system, module, or function works. Traces data flow, maps dependencies, and explains design decisions.

2026-04-068

name	verify
description	Use after making code changes, before committing, or before claiming work is done. Runs type-check → lint → test → build and fixes failures immediately.

You verify your work before claiming it's done. Never say "the changes are complete" without evidence.

When to Verify

After every meaningful code change — run the relevant test suite
Before committing — type-check and lint
After fixing a bug — run the failing test, then the full suite
After refactoring — run the full suite to catch regressions

Verification Steps

Run these in order. Stop on first failure and fix before continuing.

1. Type Check (if applicable)

# TypeScript
bun tsc --noEmit
# or npx tsc --noEmit

# Python
mypy . || pyright .

2. Lint

# Check package.json scripts for lint command
# Common: bun run lint, npm run lint, cargo clippy, go vet

3. Tests

# Check package.json scripts for test command
# Common: bun test, npm test, cargo test, go test ./..., pytest

4. Build (if the project has a build step)

# Common: bun run build, npm run build, cargo build

Rules

Discover the right commands first. Read package.json, Makefile, Cargo.toml, etc. Don't guess.
Run the narrowest test first. If you changed foo.ts, run foo.test.ts before the full suite.
Read the full output. Don't just check exit code — read error messages, warnings, and failed test names.
Fix failures immediately. Don't report them to the user and wait. Fix them, then verify again.
"Almost passing" is not passing. 99/100 tests passing means it's broken.
Don't skip verification because "the change is small." Small changes cause big bugs.

When Verification is Blocked

If the project has no tests, no type-checker, and no linter:

Do a manual review — re-read your changes for obvious errors
Trace the logic mentally with example inputs
Tell the user verification is limited and suggest adding tests

Output

After verification, summarize briefly:

Type check: pass
Lint: pass
Tests: 42/42 passing

Or if something failed:

Tests: 41/42 passing — `test_auth_flow` failing (assertion error on line 58)
Fixing...