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 agentmods add skills/outlinedriven/odin-claude-plugin/incremental-implementationnpx skills add OutlineDriven/odin-claude-plugin --skill incremental-implementationgit 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/incremental-implementation)<a href="https://agentmods.dev/skills/outlinedriven/odin-claude-plugin/incremental-implementation"><img src="https://agentmods.dev/badge/skills/outlinedriven/odin-claude-plugin/incremental-implementation.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 | $0.00058 | $0.00760 |
| Opus 5 | $0.00029 | $0.00380 |
| Sonnet 5 | $0.00012 | $0.00152 |
| Haiku 4.5 | $0.00006 | $0.00076 |
Grade A, and why
incremental-implementation 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 yesterday.
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 — 48 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Incremental implementation
Contract
| Field | Bound contract |
|---|---|
| Trigger | Implementing any multi-file change, building a new feature from a breakdown, refactoring, or when about to write more than a small amount of code at once. |
| Authority | Reversible local: write only named local artifacts; rollback via VCS revert of each slice commit. |
| Side effect | Sequence of tested, committed slices, possibly behind feature flags. |
| Done | Each slice was individually tested and committed, the full suite passes, the build is clean, and the feature works end-to-end without uncommitted changes. |
Inputs
- Plan or breakdown (required): ordered list of atomic changes that together deliver the feature or refactor. Each item must name the files it touches and the observable behavior it adds or changes.
- Existing test suite (required): the project's current test runner and passing baseline.
- Feature flag mechanism (optional): if the project uses feature flags, the flag name and gating surface for the new behavior.
Procedure
- Read the plan. Confirm each item is independently compilable and testable. If an item cannot be tested in isolation, split it further before proceeding.
- For each plan item, in order: a. Implement the change across the named files. Keep the slice as thin as possible: one behavior, one concern, one testable contract. b. If a feature flag is in scope, gate the new behavior behind it so the system remains correct with the flag off. c. Run the affected tests. If the project has a fast targeted test command, use it; otherwise run the full suite. d. Confirm the build is clean: no new warnings, no type errors, no lint regressions on touched files. e. Commit the slice with a message that names the behavior added or changed. Do not bundle unrelated changes.
- After all slices are committed, run the full test suite once more to confirm no cross-slice interaction introduced a regression.
- Verify end-to-end: exercise the feature or refactor path manually or via integration test to confirm the complete behavior works.
- If a feature flag was used, confirm the flag-on and flag-off paths both pass. Leave the flag in place unless the plan explicitly calls for its removal in a later slice.
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.
- yesterday First seen · 48 lines · 58 tokens per session scan A b91052e22be4
incremental-implementation is a skill published in the GitHub repository OutlineDriven/odin-claude-plugin (35 stars, last pushed yesterday), licensed Apache-2.0. It adds 58 tokens to every session and 760 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
java-commit
Generates a Conventional Commits message for staged Java changes. Use when user asks to "write a commit message", "help me commit", "what should my commit say", "summarize my changes", "draft a commit", or "create commit message".
claude-code-bash-patterns
Claude Code Bash tool patterns with hooks, automation, git workflows. Use for PreToolUse hooks, command chaining, CLI orchestration, custom commands, or encountering bash permissions, command failures, security guards, hook configurations.
slop-scan
Use when scanning tracked repository files for AI slop, verbosity, brittle references, or low-value contributions.
worktrees
Use when fanning several tickets into parallel branches and git worktrees, with related tickets grouped together.
weave-fix-review
Fix weave review findings — validate, add test coverage, fix, and commit each as atomic changes.
action
Use when screened review findings should be fixed on the current branch, usually as one verified commit per finding.