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 prime-radiant-inc/greenfield --skill source-completenessgit clone --depth 1 https://github.com/prime-radiant-inc/greenfieldWrote 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/prime-radiant-inc/greenfield/source-completeness)<a href="https://agentmods.dev/skills/prime-radiant-inc/greenfield/source-completeness"><img src="https://agentmods.dev/badge/skills/prime-radiant-inc/greenfield/source-completeness.svg" alt="Measured on agentmods" 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.00060 | $0.01955 |
| Opus 5 | $0.00030 | $0.00978 |
| Sonnet 5 | $0.00012 | $0.00391 |
| Haiku 4.5 | $0.00006 | $0.00196 |
Grade A, and why
source-completeness 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 8d 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 — 188 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Source-to-Spec Completeness Validation
Why This Exists
The analysis pipeline (Layers 1-3) reads source code and produces behavioral specs. But it can miss things:
- Registered commands or tools defined in source but not in the tool catalog
- Environment variables read by the code but not documented
- CLI flags defined in the argument parser but not cataloged
- Subcommands registered dynamically or conditionally
- Config keys accessed in settings but not listed in the config spec
- Events dispatched but not inventoried
- Error categories defined but not documented
The fidelity validation (Layer 7) only checks raw→clean. This skill checks source→raw — it goes back to the actual source code and verifies that every discoverable user-facing surface was captured in the specs.
When to Run
Run AFTER Layer 3 deep documentation is complete, ideally as part of Gate 1 or as a pre-Gate-1 completeness check. If gaps are found, dispatch deep-dive agents to cover the missing areas before proceeding.
Also run AFTER Layer 7 fidelity validation to catch anything the fidelity check couldn't find (because it was never in the raw specs).
The Checks
Search patterns depend on target shape. For a single-file bundle, grep the bundle directly. For a source tree, grep recursively across the source root. Patterns also depend on the target language's idioms for registering each surface — the examples below give common patterns for several languages; adjust to the actual target.
Check 1: Tool / Command Registration Completeness
Applies to targets that expose a registered command, tool, or handler surface (CLIs with subcommands, plugin hosts, RPC servers with method registration).
Source extraction: grep for the registration pattern used by the target. Examples:
# Named-object pattern (common in JS/TS/Go handler registration)
grep -roE 'name:\s*"[A-Z][a-zA-Z]+"' <source-root> | sort -u
# Decorator-based registration (Python)
grep -roE '@(command|tool|handler|register)\(' <source-root>
# Macro-based registration (Rust)
grep -roE '#\[(command|tool|handler)' <source-root>
# Assigned-constant pattern (JS/TS)
grep -roE 'var [a-zA-Z0-9_]+="[A-Z][a-zA-Z]+"' <source-root> | grep -v 'Exception\|Error\|Element'
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.
- 8d ago First seen · 188 lines · 60 tokens per session scan A b19104e39053
source-completeness is a skill published in the GitHub repository prime-radiant-inc/greenfield (273 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 60 tokens to every session and 1,955 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
write-test-plans
Interactive workflow for writing new Speky test plans for requirements lacking coverage, guided by the Speky MCP server.
speky-workflow
Guidelines for working with Speky requirements and tests via the speky MCP server tools.
live-preview
Mid-build visual verification loop. Takes screenshots of components during construction, not just after. Catches visual regressions and invisible features before they compound. Requires Playwright or similar screenshot tool.
validate-album
Validates album directory structure, file locations, and content integrity. Use before release or whenever the user wants to check an album's structural health.
brooks-sweep
Full-sweep mode: runs a unified analysis across all quality dimensions — code decay, architecture, tech debt, and test quality — then applies fixes directly to the codebase. Safe changes are auto-applied; risky changes are confirmed before execution. Drawing on twelve classic engineering books. Triggers when: user…
test-review
Test coverage review via Codex exec. Use when: reviewing test sufficiency, identifying coverage gaps, test quality audit. Not for: generating tests (use codex-test-gen), code review (use codex-code-review). Output: coverage analysis + gap report.