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/redhuntlabs/wizard/writing-an-implementation-plannpx skills add redhuntlabs/wizard --skill writing-an-implementation-plangit clone --depth 1 https://github.com/redhuntlabs/wizardWrote 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/redhuntlabs/wizard/writing-an-implementation-plan)<a href="https://agentmods.dev/skills/redhuntlabs/wizard/writing-an-implementation-plan"><img src="https://agentmods.dev/badge/skills/redhuntlabs/wizard/writing-an-implementation-plan.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.1 | $0.00030 | $0.01195 |
| Opus 5 | $0.00015 | $0.00598 |
| Sonnet 5 | $0.00006 | $0.00239 |
| Haiku 4.5 | $0.00003 | $0.00120 |
Grade A, and why
writing-an-implementation-plan 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 — 137 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Writing an Implementation Plan
What this does
Turns a feature spec (output of brainstorming-a-feature, or a written PRD) into an executable implementation plan: file-level changes, ordering, checkpoints, risks, and rollback. Designed so a different person — or future-you in a different session — could execute it without asking clarifying questions.
When to use
- After a feature has been brainstormed and an approach chosen
- Before starting to code any non-trivial feature
- When handing implementation to someone else
- When the work spans multiple sessions and needs continuity
What you bring (Inputs)
- The chosen approach (from brainstorming-a-feature or a PRD)
- Read access to the codebase
- The acceptance criteria (how will we know it's done)
What you get (Output)
A plan document with: scope, file-level changes (paths + what changes), ordering with dependencies, per-step verification, risks and rollback, and the acceptance criteria.
How it works (Steps)
This is a workflow.
Stages
Stage 1: Restate scope
In one paragraph, restate what's being built and what's explicitly out of scope. Out-of-scope is critical — it prevents drift mid-implementation.
Stage 2: Inventory file-level changes
Walk the codebase and list every file that needs to change. For each: full path + 1-3 line description of what changes there.
If you're adding new files, list them too.
If you're not sure which files need to change for a given concern, that's a discovery task — note it explicitly.
Stage 3: Order the steps
Order is important. Rules of thumb:
- Foundations first (data model → API → UI)
- Each step should leave the system in a working state if possible
- Risky steps early (so you discover unknowns before you've sunk cost)
- Steps should be independently verifiable
Stage 4: Define per-step verification
For each step: how will you know it worked? Examples:
- Unit test passes
- Curl a specific endpoint and see expected response
- Open the page and see the new component
- Migration runs without error and rollback also works
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 First seen · 137 lines · 30 tokens per session scan A b723096daa0d
writing-an-implementation-plan is a skill published in the GitHub repository redhuntlabs/wizard (9 stars, last pushed 4mo ago), licensed MIT. It adds 30 tokens to every session and 1,195 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-31.
Other skills, from other repositories
fastapi
FastAPI - 高性能 Python Web API 框架.
lazydocker
本技能帮助用户通过 lazydocker 的终端 UI 界面管理 Docker 容器、镜像、卷和网络，支持以下场景：.
fzf
Skill "fzf" from CN-big-cabbage/github-skill-distiller, covering fzf 通用命令行模糊查找器, 技能概述, 使用流程, 关键章节导航 and ai 助手能力.
glances
Skill "glances" from CN-big-cabbage/github-skill-distiller, covering glances 跨平台系统监控工具, 技能概述, 使用流程, 关键章节导航 and ai 助手能力.
paper-checking
论文查重系统 - 一亿字次级论文库秒级查重，支持纵向查重和横向查重.
you-get
网页媒体下载助手 - 从YouTube、Bilibili等网站下载视频、音频、图片.