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 aneja5/forge-skills --skill incremental-implementationgit clone --depth 1 https://github.com/aneja5/forge-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/aneja5/forge-skills/incremental-implementation)<a href="https://agentmods.dev/skills/aneja5/forge-skills/incremental-implementation"><img src="https://agentmods.dev/badge/skills/aneja5/forge-skills/incremental-implementation/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/aneja5/forge-skills/incremental-implementation"><img src="https://agentmods.dev/badge/skills/aneja5/forge-skills/incremental-implementation.svg" alt="Reviewed on agentmods" width="80" 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.00056 | $0.01598 |
| Opus 5.5 | $0.00022 | $0.00639 |
| Sonnet 5.5 | $0.00011 | $0.00320 |
| Haiku 4.5 | $0.00006 | $0.00160 |
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 1mo 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 — 132 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Incremental Implementation
Overview
Pick the next ready task from .forge/tasks.yaml, load its contracts from .forge/contracts/, implement using tdd discipline (red-green-refactor), verify against acceptance criteria, commit, and mark done. Repeat until all tasks are complete.
When to Use
.forge/tasks.yamlexists with at least one unstarted task- Dependencies for the next task are complete
- Ready to write code (not planning, not designing)
When NOT to Use
- No task plan exists — run
planning-and-task-breakdownfirst - Architecture is unclear — run
architecture-and-contractsfirst - Task is XL and not decomposed — spike first, then plan
Common Rationalizations
| Thought | Reality |
|---|---|
| "I'll implement a few tasks together to go faster" | Mixing tasks blurs acceptance criteria and commit history |
| "I don't need to read the contract — I know the interface" | Contracts encode invariants and error types you'll miss |
| "I'll write tests after the implementation is working" | Then you're testing implementation, not behavior |
| "This small extra thing is obviously correct to add" | Scope creep is always "obviously correct" in the moment |
| "I'll commit everything at the end" | Atomic commits per task make revert and review tractable |
Red Flags
- Implementing a task that has unsatisfied dependencies in
tasks.yaml - Writing code that touches modules not listed in the task's
files_likely_affected - Skipping the contract read — implementing to an assumed interface
- Committing with a message that doesn't reference the task ID
- Acceptance criteria not verifiable after implementation
- Task marked done before verification step passes
.forge/tasks.yamlnot updated mid-flight when a task is split or blocked (the plan diverges silently)- Editing
.forge/contracts/<X>.mdinline when build reveals the contract is wrong (file/feedbackinstead) - Skipping
skills:tag reads — implementing UI without loadingdesign-system, writing migrations without loadingdatabase-design
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.
- 1mo ago First seen · 132 lines · 56 tokens per session scan A 4324675d4258
incremental-implementation is a skill published in the GitHub repository aneja5/forge-skills (3 stars, last pushed 5mo ago), licensed MIT. It adds 56 tokens to every session and 1,598 once invoked, about $0.0002 per session on Opus 5.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-03.
Other skills, from other repositories
tdd
Use when implementing features or bug fixes test-first.
auto-loop
TDD-based autonomous development loop with checkpoint recovery and observability changelog.
workflow
Run the complete 5-step development workflow: focus problem → prevent over-development → test-first (TDD) → document → smart commit. Use when starting a new feature, or when the user runs /workflow or asks for the full development flow.
test-audit
Audit test suites for T1-T4 violations using AST analysis, mock detection, and multi-stage synthesis. Invoke when user asks to audit tests, check test quality, find mock violations, review test effectiveness, or inspect test suites for over-mocking. Triggers automatic rewrites when quality gates fail.
test-first
Drive one feature through a strict TDD Red-Green-Refactor cycle with checklists for each phase. Use when implementing new functionality test-first, or when the user runs /test-first.
feature-dev
Take one new feature slice from idea to reviewed, committed code in a single guided pass — scope it into the smallest shippable slice, build it test-first with strict TDD, review and fix the diff, then commit it. Chains slice → test-driven-development → the built-in /code-review → git-commit. Not for reviewing an…