# Verify Checklist

> Use after any implementation or change, before reporting it done, even without an explicit verification request.

- Skill: `blueclover22/verify-checklist` (Agent Skill)
- Install (CLI): `npx skillmds@latest add blueclover22/verify-checklist`
- Raw SKILL.md: https://api.skillmd.com/api/skills/blueclover22/verify-checklist/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: blueclover22 (https://skillmd.com/u/blueclover22)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/blueclover22/verify-checklist

---


# Post-Change Verification Checklist

After completing any implementation step, verify in the order below before reporting results.

---

## Verification Order

> **Priority rule**: if the project declares verification commands — a CLAUDE.md/README §Verification Commands section, package/task-runner scripts, or similar; an actually declared run command, not merely a config file's existence — use those first. The order and example commands below are defaults.

### ① Build / Type Check

Catch compile and type errors first. If this step fails, later steps are meaningless.

Examples:

```
pnpm tsc --noEmit          # TypeScript type check
pnpm build                 # bundle build
cargo build                # Rust build
go build ./...             # Go build
mvn compile                # Java/Maven compile
```

### ② Lint

Check code style and static-analysis errors.

Examples:

```
pnpm lint                  # ESLint (Node/TS)
cargo clippy               # Rust clippy
golangci-lint run          # Go lint
```

### ③ Unit Tests

Confirm the changed logic does not break existing contracts.

Examples:

```
pnpm test                  # Jest / Vitest etc.
cargo test                 # Rust tests
go test ./...              # Go tests
mvn test                   # Java/Maven tests
yarn test                  # Yarn projects
```

### ④ Format

Check formatting consistency. **Format only the files you changed** — project-wide reformatting inflates the diff and conflicts with the Precise Changes principle. Skippable if CI already enforces it.

Examples:

```
pnpm prettier --write <changed files>   # Prettier (JS/TS/MD)
cargo fmt -- <changed files>            # Rust format
gofmt -w <changed files>                # Go format
```

### ⑤ Manual Scenario (UI changes only)

Only applies when UI or user interaction changed.

- If manual verification is possible in this environment, run the scenario directly and report the result.
- If not possible (CI-only, remote build, etc.), report explicitly: **"Manual verification not possible — needs direct confirmation."** Never hide the inability to verify.

---

## On Failure

Numbers name the **check type**, not a row position. A project command that matches one of these types follows its row; one that matches none (a manifest validator, a security scan) follows the general rule — find the cause, fix within the changed files, re-run that check.

| Step | Action on failure |
| :--- | :--- |
| ① Build/type errors | Read the full error log, fix, re-run from ① |
| ② Lint errors | Run lint without auto-fix first to see the actual error set; then fix, scoped to the changed files only (auto-fix included), and re-run |
| ③ Test failures | Analyze the failing case and message; decide whether the implementation or the test is wrong, then fix |
| ④ Format errors | Run the format command, inspect changed files; report any unintended changes |
| ⑤ Manual scenario | Record the deviation concretely, fix, re-verify |

---

## Handoff

Verification never decides the next stage on its own — report the results and let the main thread route.

| Outcome | Next |
| :--- | :--- |
| A step failed | Fix and re-run from ①. If the fix is non-trivial and the `mak:coder` agent is in the available agent list, delegate it. If the failure exposes a design mismatch or a scope expansion, stop and report instead of fixing |
| All passed, slice/stage complete | Hand off to `mak:review-report` (or the `mak:reviewer` agent if it is in the available agent list) |
| All passed, work continues | Return to the main thread — it decides the next step. If `mak:coder` performed the change, route through `mak:review-report` first |

Never route into `mak:commit` from here. Committing requires the user's explicit request.

---

## Prohibited Commands / Cautions

> If the project CLAUDE.md defines allowed/denied command lists, those take precedence. Below are general principles.

- `npx <command>`, `npm run <script>` — if the project uses pnpm/yarn, use that package manager
- `node_modules/.bin/<tool>` — use package-manager scripts instead of direct paths
- Prefer platform-independent commands (package-manager scripts, task runners) over OS-specific shell invocations (`cmd.exe /c ...`, `powershell.exe -Command ...`). When an OS-specific command is unavoidable, note both platform forms (`cp` / `Copy-Item`, etc.)
- `git commit`, `git push` — only when the user explicitly says "commit"/"push". Otherwise the user runs these directly
- Never report "done" before confirming verification results

---

## Self-Check Before Reporting

Ask yourself the following before writing the verification report. Clean up simple items caused by your own change before reporting. Do not silently fix scope expansions, design mismatches, or items needing user decisions — report them to the main thread instead. The design doc referenced below is located per the `mak:design-doc-template` save-path rule, which also owns the §5.0 status-column rule.

- [ ] Does every changed line connect directly to the user's request? (Precise Changes)
- [ ] Did any unrequested "improvement" of adjacent code/comments/formatting slip in? (Precise Changes)
- [ ] Are all unused imports/variables/functions introduced by your change cleaned up? (Precise Changes)
- [ ] Were unrequested features / speculative flexibility / impossible-scenario error handling added? (Simplicity)
- [ ] Are all items in the design doc §5.0 success criteria or `Step → verify` table actually met? (Goal-driven)
- [ ] For each step whose verify criterion just passed, was its §5.0 `Status` cell updated? (Goal-driven)

## Report Format

After verification, report in this format (render headings in the user's language). The first table records **every check that applies and whether it ran** — when the project declares its own verification commands (§Verification Order priority rule), report those in place of the default rows. Drop a row only when that check does not exist for this project.

```
## Verification Results

| Step | Command | Result |
| :--- | :--- | :--- |
| ① Build/type check | `<command run>` | ✅ pass / ❌ fail / ⏭ not run |
| ② Lint | `<command run>` | ✅ pass / ❌ fail / ⏭ not run |
| ③ Unit tests | `<command run>` | ✅ pass / ❌ fail / ⏭ not run |
| ④ Format | `<command run>` | ✅ pass / ⏭ skipped |
| ⑤ Manual scenario | — | ✅ confirmed / ⚠️ not verifiable |

## Predefined Success Criteria vs Results

| # | Step (design doc §5.0) | Success criterion | Actual result |
| :- | :--- | :--- | :--- |
| 1 | <Step> | <verify> | ✅ met / ❌ not met |
| 2 | <Step> | <verify> | ✅ met / ❌ not met |
```

If the design doc has no `Step → verify` table, replace the second table with a one-line statement of whether the success criterion was met.

When all steps pass and all criteria are met: `✅ All verification steps and success criteria passed`