Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add arozumenko/sdlc-skills --skill verifying-outcomesgit clone --depth 1 https://github.com/arozumenko/sdlc-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/arozumenko/sdlc-skills/verifying-outcomes)<a href="https://agentmods.dev/skills/arozumenko/sdlc-skills/verifying-outcomes"><img src="https://agentmods.dev/badge/skills/arozumenko/sdlc-skills/verifying-outcomes/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/arozumenko/sdlc-skills/verifying-outcomes"><img src="https://agentmods.dev/badge/skills/arozumenko/sdlc-skills/verifying-outcomes.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00065 | $0.00713 |
| Opus 5 | $0.00032 | $0.00357 |
| Sonnet 5 | $0.00013 | $0.00143 |
| Haiku 4.5 | $0.00006 | $0.00071 |
Grade A, and why
verifying-outcomes scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 82 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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 (
Grepforos.getenv/process.envwithout 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.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 82 lines · 65 tokens per session scan A 7fd31b4ef7d1
verifying-outcomes is a skill published in the GitHub repository arozumenko/sdlc-skills (20 stars, last pushed yesterday), licensed MIT. It adds 65 tokens to every session and 713 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
research-engineer
An uncompromising Academic Research Engineer. Operates with absolute scientific rigor, objective criticism, and zero flair. Focuses on theoretical correctness, formal verification, and optimal implementation across any required technology.
tika-eval-compare
Compare extracts from two Tika builds over a corpus to detect regressions in content, encoding, exceptions, and embedded-document handling. Use for "compare before/after extracts", "eval this change against the corpus".
neuron-evaluation-engineer
Create and run AI evaluations with datasets, assertions, and output drivers in Neuron AI. Use this skill whenever the user mentions evaluation, testing AI systems, creating evaluators, dataset-driven testing, assertion-based validation, or wants to measure AI system performance. Also trigger for tasks involving…
jetson-validate-image
Use after jetson-flash-image to run static BSP checks, on-target smoke/regression tests on a flashed DUT, or both. Not for build or flash steps. Triggers: validate bsp, on-target validation.
atmos-validation
Validate Atmos projects, components, arbitrary JSON Schema inputs, EditorConfig, and GitHub Actions; use affected-file selection and native CI annotations.
skill-benchmark
Benchmark AI skill effectiveness by measuring implementation quality against legacy constraints.