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 vibeeval/vibecosystem --skill completion-checkgit clone --depth 1 https://github.com/vibeeval/vibecosystemWrote 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/vibeeval/vibecosystem/completion-check)<a href="https://agentmods.dev/skills/vibeeval/vibecosystem/completion-check"><img src="https://agentmods.dev/badge/skills/vibeeval/vibecosystem/completion-check.svg" alt="Measured on agentmods" height="20"></a>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.00010 | $0.00693 |
| Opus 5 | $0.00005 | $0.00347 |
| Sonnet 5 | $0.00002 | $0.00139 |
| Haiku 4.5 | $0.00001 | $0.00069 |
Grade B, and why
completion-check scanned grade B with 1 finding 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 4d 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.
Reads agent configuration directoriesmediumAgent snooping
.claude/, .codex/, .gemini/ hold keys, settings and other credentials a mod has no legitimate need for.
grep "my-hook" .claude/settings.json This is a copy
100% identical to completion-check — 202 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 102 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Completion Check: Verify Infrastructure Is Wired
When building infrastructure, verify it's actually connected to the system before marking as complete.
Pattern
Infrastructure is not done when the code is written - it's done when it's wired into the system and actively used. Dead code (built but never called) is wasted effort.
DO
-
Trace the execution path - Follow from user intent to actual code execution:
# Example: Verify Task tool spawns correctly grep -r "claude -p" src/ grep -r "Task(" src/ -
Check hooks are registered, not just implemented:
# Hook exists? ls -la .claude/hooks/my-hook.sh # Hook registered in settings? grep "my-hook" .claude/settings.json -
Verify database connections - Ensure infrastructure uses the right backend:
# Check connection strings grep -r "postgresql://" src/ grep -r "sqlite:" src/ # Should NOT find if PostgreSQL expected -
Test end-to-end - Run the feature and verify infrastructure is invoked:
# Add debug logging echo "DEBUG: DAG spawn invoked" >> /tmp/debug.log # Trigger feature uv run python -m my_feature # Verify infrastructure was called cat /tmp/debug.log -
Search for orphaned implementations:
# Find functions defined but never called ast-grep --pattern 'async function $NAME() { $$$ }' | \ xargs -I {} grep -r "{}" src/
DON'T
- Mark infrastructure "complete" without testing execution path
- Assume code is wired just because it exists
- Build parallel systems (Task tool vs claude -p spawn)
- Use wrong backends (SQLite when PostgreSQL is architected)
- Skip end-to-end testing ("it compiles" ≠ "it runs")
Completion Checklist
Before declaring infrastructure complete:
- Traced execution path from entry point to infrastructure
- Verified hooks are registered in .claude/settings.json
- Confirmed correct database/backend in use
- Ran end-to-end test showing infrastructure invoked
- Searched for dead code or parallel implementations
- Checked configuration files match implementation
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.
- 4d ago First seen · 102 lines · 10 tokens per session scan B 84e0daf53138
completion-check is a skill published in the GitHub repository vibeeval/vibecosystem (530 stars, last pushed 1mo ago), licensed MIT. It adds 10 tokens to every session and 693 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it B with 1 finding (reads agent configuration directories). It is 100% identical to completion-check, differing in 202 lines, and is treated as a copy.
Other skills, from other repositories
test-reporting
Run the Level 2 dummy agent integration test suite and produce a detailed HTML report with per-test input → outcome analysis.
multi-agent-e2e-validation
Multi-agent parallel E2E validation for database refactors. TRIGGERS - E2E validation, schema migration testing, database refactor validation.
symmetric-dogfooding
Bidirectional integration validation where two repositories validate each other before release.
schema-e2e-validation
Earthly E2E validation for YAML schema contracts. TRIGGERS - schema validation, YAML schema, schema contracts, regenerate types.
merge-ready
Run all quality gates before merge — git hygiene, documentation completeness, code review, security audit, build, E2E, goal-backward verification, doc accuracy and UI/UX — then write the changelog entry.
dogfood
Systematic web app QA using Playwright browser automation. Tests across viewports, checks navigation flows, form submissions, error states, accessibility basics, and visual consistency. Produces a structured bug report. Triggers on: "dogfood", "QA", "find bugs", "test this app".