copilot-setting: Skill for Claude Code

Verify — Workflow

Close-the-loop verification: derive what must be true, bind each to a runnable check, execute, and gate. The gate is a separate pass from authoring — derive the expected behaviour from the requirement, never from the code under test, or the gate just rubber-stamps whatever the code does. Framework rules for any run command or test code referenced here: instructions/testing.instructions.md.

Phase 0 — Load canonical rules

MANDATORY pre-load gate — do NOT derive or run checks until you have opened the instruction files for the layers under verification. Your training data defaults to modern Java/Spring; these files are the version lock for Java 8 / Spring 3.2 / Hibernate 4.2. Open them first, every time. Read-back receipt: NAME each file you opened and QUOTE its single most load-bearing rule for this change — a generic restatement you could have written from memory means you skipped the file.

Open instructions/testing.instructions.md — JUnit 4 / Mockito / Spring Test 3.2, and every run command or test you write must match this stack, not JUnit 5 / Spring Boot Test — plus the layer instruction(s) for the feature under verification (e.g. instructions/sql.instructions.md, instructions/security.instructions.md), whose version-lock and hard-boundary rules are the negative cases Phase 1 must cover.

Phase 1 — Derive the checks

Work from the requirement / plan.md acceptance criteria (AC-NNN), NOT from the code under test — independent derivation is the whole point of a gate.

• Boundaries — input (min, max, empty, null, overflow), state (initial, in-progress, done, error), integration (external call, DB, file I/O)
• Categories — tag each check: Happy path, Boundary, Error / Exception, Security, Concurrency, Performance
• Coverage — every AC maps to ≥1 check; every public method has ≥1 happy + ≥1 error; boundary values for all numeric/string inputs; SQL paths checked for injection and empty results

Phase 2 — Bind each check to a runnable command