verify

星标8

分支0

更新时间2026年3月21日 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.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

chinmaymk

chinmaymk/ra

打开 GitHub 仓库查看创作者相关仓库

下载

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...

同仓库更多 Skills

同仓库

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...