AgentStack
Sign in Publish
MCP servers Skills Toolkits Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Verifying Outcomes

skill-arozumenko-sdlc-skills-verifying-outcomes · by arozumenko

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 you claim a task is complete and before closing an issue / merging a PR.

↗ Repository
— No reviews yet
0 installs
15 views
0.0% view→install

Install

$ agentstack add skill-arozumenko-sdlc-skills-verifying-outcomes

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • ✓ Prompt-injection patterns
  • ✓ Secret / credential exfiltration
  • ✓ Dangerous shell & filesystem operations
  • ✓ Untrusted network calls
  • ✓ Known-malicious package signatures

What it can access

  • ✓ Network access No
  • ✓ Filesystem access No
  • ✓ Shell / process execution No
  • ● Environment & secrets Used
  • ✓ Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Verifying Outcomes? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Verifying Outcomes

"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: 

### Verdict: PASS | PARTIAL | FAIL

### TRUE
-  — 
- ...

### EXISTS
-  —  — 
- ...

### CONNECTED
-  — 
- ...

### RISKS
- 
- ...

### Summary

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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Write a review

Versions

  • v0.1.0 Imported from the upstream source.

More in Agent Skills