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 OutlineDriven/odin-claude-plugin --skill to-greenfieldgit clone --depth 1 https://github.com/OutlineDriven/odin-claude-pluginWrote 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/outlinedriven/odin-claude-plugin/to-greenfield)<a href="https://agentmods.dev/skills/outlinedriven/odin-claude-plugin/to-greenfield"><img src="https://agentmods.dev/badge/skills/outlinedriven/odin-claude-plugin/to-greenfield/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/outlinedriven/odin-claude-plugin/to-greenfield"><img src="https://agentmods.dev/badge/skills/outlinedriven/odin-claude-plugin/to-greenfield.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.00051 | $0.01201 |
| Opus 5 | $0.00026 | $0.00600 |
| Sonnet 5 | $0.00010 | $0.00240 |
| Haiku 4.5 | $0.00005 | $0.00120 |
Grade A, and why
to-greenfield 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 6d 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 — 51 lines — stays where its author put it; the contents beside it link to each section on GitHub.
To greenfield
Contract
| Field | Bound contract |
|---|---|
| Trigger | User says 'greenfield this' or 'rescue this codebase', or names a field. |
| Authority | Reversible local: writes only named local artifacts for exactly one bounded first corrective action (read-only diagnosis first); rollback is stated before any mutation (version control or undo). No remote mutation. |
| Side effect | Field diagnosis and the first corrective action are reported in chat; durable effects are limited to the single bounded action this skill executes under its own authority. |
| Done | The field (dark, red, brown, or blue) is named with its one-fact evidence and the first corrective action has been executed. |
Inputs
- Target scope (required): one repository region or subsystem to diagnose. "Greenfield this" scopes to the subsystem the working session covers; a larger repository is diagnosed per subsystem, never as one undifferentiated whole.
- Field name (optional): a user-named field: dark, red, blue, or brown. It is a hypothesis, not authority: diagnosis must confirm or refute it with evidence before any action.
- Verifier command (optional): the project's check command for the scoped subsystem. When absent, read it from the project's own configuration or task runner; never invent one.
Refusals
- Will not widen scope beyond one subsystem: a second subsystem is a second invocation.
- Will not execute more than one corrective action per invocation.
- Will not invent evidence to support a field diagnosis.
- Will not swallow a failed first action or claim Done: revert and report non-converged.
Procedure
- Bound the scope. Name the subsystem under diagnosis and the paths it covers. Stop rather than widen scope; a second subsystem is a second invocation. Done when: the subsystem and its paths are named.
- Diagnose the field through read-only inspection, including verifier runs and path and symbol searches. Apply this precedence: red trumps all (a broken bluefield is redfield until green), then darkfield, then bluefield, then brownfield. Redfield: verifier fails, active regressions, red CI, or broken build. Darkfield: no tests and no docs; structure unclear; nobody can say what a change would break. Bluefield: two coexisting implementations of one concern: old/new directories, migration flags,
v2suffixes, TODO-migrate markers. Brownfield: green and working, but compat shims, legacy patterns, and dead weight. Done when: one field is selected with its evidence. - Cite exactly one fact as the field's evidence: verifier output for red, a missing-tests-and-docs observation for dark, a named dual-implementation pair for blue, or a shim and legacy-pattern list for brown. If the user-named field is refuted, report the refuting fact and proceed with the evidence-supported field. Done when: the one-fact evidence is cited.
- State the rollback path, then execute exactly one first corrective action for the diagnosed field. Redfield: fix the single highest-priority verifier failure with the smallest change that turns that check green; quarantine a flaky check by naming it in the report, never by deleting it. Darkfield: map the scoped subsystem (structure, entry points, dependencies) and write one newcomer doc as a local artifact. Bluefield: record the concern's canonical and legacy paths with their remaining callers in the chat report, then migrate the first remaining caller onto the canonical path. Brownfield: add one behavior-pinning characterization test where coverage is thinnest. Done when: the one corrective action is executed and its rollback path is stated.
- Verify the action. Red: rerun the single failing verifier and confirm green. Dark: every doc claim traces to a mapped path. Blue: the migrated caller resolves against the canonical path only. Brown: the new test passes as written; a failing one refutes the diagnosis. Done when: the action is verified.
- Report in chat. Field, one-fact evidence, action executed, files touched, rollback path, verification result, and the next action for that field. One diagnosis and one first action per invocation. Done when: the chat report is emitted with all seven elements.
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.
- 6d ago Changed · -4 tokens per session b4a88b47362b
- 8d ago First seen · 51 lines · 55 tokens per session scan A 9f03b429cc64
to-greenfield is a skill published in the GitHub repository OutlineDriven/odin-claude-plugin (36 stars, last pushed 3d ago), licensed Apache-2.0. It adds 51 tokens to every session and 1,201 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-09-04.
Other skills, from other repositories
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
local-ai-agents
Build local-first AI agents that run entirely on a developer workstation with Microsoft Foundry Local and Qwen function-calling models. Covers Small Language Models (SLMs), the OpenAI-compatible local endpoint, sandboxed local tools, local RAG with Chroma, local MCP servers, hybrid cloud/local routing, and the…
next-cache-components-adoption
Turn on Cache Components in a Next.js app and resolve the blocking routes it surfaces. Use when the user wants to enable, adopt, or migrate to Cache Components, flip the cacheComponents flag, work through a flood of blocking-prerender / instant validation errors, run the cache-components-instant-false codemod, or…
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…
insight-error-page
Write or audit an insight-kind error page for the Next.js dev overlay. Use when creating a new errors/ .mdx page, auditing an existing one, or checking that a page matches the framework fix cards. Covers page structure, title alignment, FixCard cards with Copy prompt button, code snippets, terminology verification…