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 gjoranv/claude-plan-skills --skill gh-implement-plangit clone --depth 1 https://github.com/gjoranv/claude-plan-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/gjoranv/claude-plan-skills/gh-implement-plan)<a href="https://agentmods.dev/skills/gjoranv/claude-plan-skills/gh-implement-plan"><img src="https://agentmods.dev/badge/skills/gjoranv/claude-plan-skills/gh-implement-plan/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/gjoranv/claude-plan-skills/gh-implement-plan"><img src="https://agentmods.dev/badge/skills/gjoranv/claude-plan-skills/gh-implement-plan.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.00041 | $0.00491 |
| Opus 5 | $0.00020 | $0.00246 |
| Sonnet 5 | $0.00008 | $0.00098 |
| Haiku 4.5 | $0.00004 | $0.00049 |
Grade A, and why
gh-implement-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 10d 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.
What it actually says
Implement the plan from GitHub issue $ARGUMENTS (issue URL or owner/repo#number). If no argument is given, use the issue referenced earlier in this conversation. If no issue can be determined, ask the user.
- Prepare branch: If on main/master, fetch the latest and create a feature branch with a descriptive name derived from the plan issue title. If already on a feature branch, continue on it.
- Read the issue and identify all steps (checkboxes). Steps may be in a separate Steps comment (new format) or in the issue body (old format). Check both. Before starting implementation, think about the design: What abstractions are needed? Where should the boundaries be? Is there a simpler approach than what's described? Flag any design concerns to the user before coding.
- Present the steps to the user and confirm which step to start with. If a durable-memory CLI is configured, sync it here so recall in step 4 works off a fresh mirror.
- For each step, in order:
a. If a durable-memory CLI is configured, query it with the step's distinctive terms before implementing. See the memory tool's own integration doc for mechanics.
b. Implement the change.
c. Stage and commit the changes with a descriptive commit message. Do not reference the issue.
d. Check off the step (
- [x]) on the issue. Update wherever the steps are found (Steps comment or body). - After all steps are complete, present a summary of what was done for each step (files changed, key decisions). Tell the user to review the commits and push when ready.
Rules:
- Never commit directly to main/master -- always work on a feature branch.
- Never push to remote -- only stage and commit locally.
- If a step is unclear or seems wrong, stop and ask the user for clarification instead of guessing.
- If a step fails or produces unexpected results, stop and explain what happened before continuing.
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.
- 10d ago First seen · 25 lines · 41 tokens per session scan A a51ddd034d67
gh-implement-plan is a skill published in the GitHub repository gjoranv/claude-plan-skills (5 stars, last pushed 9d ago), licensed MIT. It adds 41 tokens to every session and 491 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
understand-diff
Use when you need to analyze git diffs or pull requests to understand what changed, affected components, and risks.
add-github
Add GitHub channel integration via Chat SDK. PR and issue comment threads as conversations.
release-skills
A release workflow for preparing and publishing a new version of a software project. A release is a named version that may include updated version files, release notes, tags, or a GitHub Release.
catchup
Summarize and review what changed while you were away. Use after a weekend, vacation, or flight to check missed PRs, git commits, Linear tickets, and meetings — one prioritized brief, not a firehose.
split-and-ship
Execute an approved split plan, shipping each change group separately as its own branch and PR or as sequential commits on the current branch. Use when the user asks to "split and ship", "ship the split plan", "create separate PRs", or "split changes into branches".
grill-me
Grill the user about a requirement, decision, or idea before implementation, then produce an actionable planning report without writing code. Use when the user wants to clarify requirements, stress-test an idea, compare approaches, or plan before coding.