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/tmchow/tmc-marketplace/implementingnpx skills add tmchow/tmc-marketplace --skill implementinggit clone --depth 1 https://github.com/tmchow/tmc-marketplaceWrote 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/tmchow/tmc-marketplace/implementing)<a href="https://agentmods.dev/skills/tmchow/tmc-marketplace/implementing"><img src="https://agentmods.dev/badge/skills/tmchow/tmc-marketplace/implementing.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.00046 | $0.03566 |
| Opus 5 | $0.00023 | $0.01783 |
| Sonnet 5 | $0.00009 | $0.00713 |
| Haiku 4.5 | $0.00005 | $0.00357 |
Grade A, and why
iterative:implementing 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 5d 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 — 241 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Executing Work
Read the plan critically, create tasks, and implement with TDD, code review, and continuous testing. The plan is your guide — it contains the decisions, patterns, and test scenarios that drive implementation.
When to Use
- After
iterative:tech-planningskill completes a plan - When a plan document exists and is ready to implement
- When tasks already exist from a prior session
- Can be invoked standalone with a plan document path
Key Principles
- The plan is your guide — Read referenced files and patterns, use the plan's decisions to drive implementation
- Clarify before building — Ask questions now, not after building the wrong thing
- Test as you go — Run tests after each change, not at the end
- Commit as you go — One commit per completed subtask, never batch commits at the end
- Review at the right scope — Section review after each plan section, final review of all branch changes, user chooses which severities to fix
- Stop when blocked — Ask for help rather than guessing
Workflow
Phase 0: Detect Resume
- Check for in-progress tasks related to this plan.
- If tasks exist and work is in progress: load the plan document, summarize current state, show completed vs remaining subtasks, continue from next incomplete subtask (skip to Phase 2).
- If no tasks exist: proceed to Phase 1 — even if you have prior conversation context. Having discussed the plan in a previous session is not the same as having set up tasks and workspace. Phase 1 setup (task creation, workspace isolation) must run before any implementation begins.
Phase 1: Understand and Setup
- Find and read the plan document completely. Check conversation context for referenced plans, scan
docs/plans/for recent plan files. If no plan found, ask user for path. If no plan exists, ask the user: A) Create a tech plan first (recommended), B) I'll provide the plan path. If tech plan: invokeiterative:tech-planningskill. - Review critically. If anything is unclear or ambiguous, ask now. Do not skip this — better to clarify now than build the wrong thing.
- Workspace isolation. See Workspace Setup section.
- Create tasks from the plan. See Task Creation section.
- Execution preference. Present an interactive choice to the user —
AskUserQuestion(Claude Code) orrequest_user_input(Codex): A) Execute all tasks, report when done (default), B) Pause after each plan section for feedback, C) Pause after each subtask for feedback.
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.
- 5d ago First seen · 241 lines · 46 tokens per session scan A 7385666264a2
iterative:implementing is a skill published in the GitHub repository tmchow/tmc-marketplace (22 stars, last pushed 6mo ago), licensed MIT. It adds 46 tokens to every session and 3,566 once invoked, about $0.0002 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
engram-testing-coverage
TDD and coverage standards for Engram. Trigger: When implementing behavior changes in any package.
nunit-testing
Use when writing or modifying tests in NUnit's own test projects, or when making a behavioral change to production code that needs test coverage. Covers test structure, attribute choice, helper visibility, platform guards, and which test projects are real.
tdd
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
strict-tdd
Strict RED->GREEN->REFACTOR test-driven development with enforcement. Never write production code before a failing test. Atomic commits per TDD cycle.
tdd
This skill should be used when the user wants to implement features or fix bugs using test-driven development. Enforces the RED-GREEN-REFACTOR cycle with vertical slicing, context isolation between test writing and implementation, human checkpoints, and auto-test feedback loops. Uses multi-agent orchestration with the…
conductor-implement
Execute tasks from a track's implementation plan following TDD workflow.