Goal verifier

Skill arozumenko/wikis/.claude/skills/goal-verifier

Goal-backward verification — checks whether the desired outcome was achieved, not whether tasks were marked done. Use when the user asks to "verify", "did this actually work", "is X really done", or before closing an issue / merging a PR.From its SKILL.md

Install

npx -y skills add arozumenko/wikis --skill goal-verifier

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.7 KB, as published. Nobody here has run it

Goal Verifier

"Tasks completed" ≠ "goal achieved." Your job is to verify the outcome, ruthlessly and from evidence.

If the goal is fuzzy, ask for clarification before starting. Don't verify a moving target.

Five Checks

1. STATE the goal

Restate it as a concrete, testable outcome — not as a list of tasks. Write it at the top of the report verbatim.

2. What must be TRUE

List the logical conditions that must hold for the goal to be met. These are assertions about behavior, not about work performed.

✅ "API returns 200 for valid requests and 401 for missing tokens"
❌ "Endpoint was implemented"

3. What must EXIST

List concrete artifacts: files, endpoints, configs, migrations, tests, docs. For each, use Read / Glob / Grep to confirm it exists and contains the expected content. Existence alone isn't enough — empty stubs fail.

4. What must be CONNECTED

Things that exist but aren't wired up are useless. Verify:

Imports / exports
Route registrations, DI bindings, plugin lists
Config keys actually read by the code
Tests actually run by the test command (not orphaned files)
Migrations actually included in the migration manifest

Use Grep to trace from the artifact to its consumer. If you can't find the consumer, it isn't connected.

5. Where will this BREAK

Edge cases and error paths
Missing input validation
Hardcoded values that should be config / env vars
Missing or unhandled env vars (Grep for os.getenv / process.env without defaults)
Race conditions, timeouts, retries
Test coverage gaps for the new behavior

Output

## Verification: <goal verbatim>

### Verdict: PASS | PARTIAL | FAIL

### TRUE
- <verified condition> — <how you verified>
- ...

### EXISTS
- <artifact> — <path:line> — <what you confirmed>
- ...

### CONNECTED
- <integration point> — <evidence>
- ...

### RISKS
- <where this will break, and why>
- ...

### Summary
<1–2 sentences>

Rules

Cite file paths and line numbers for every claim. No hand-waving.
A check you can't perform is a FAIL for that check, not a pass-by-default.
PARTIAL is for "outcome works on the happy path but a listed risk is real and unaddressed." Don't use it as a polite FAIL.
Be honest. The point of this skill is to catch the things the implementer missed — flattery defeats the purpose.