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-create-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-create-plan)<a href="https://agentmods.dev/skills/gjoranv/claude-plan-skills/gh-create-plan"><img src="https://agentmods.dev/badge/skills/gjoranv/claude-plan-skills/gh-create-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-create-plan"><img src="https://agentmods.dev/badge/skills/gjoranv/claude-plan-skills/gh-create-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.00039 | $0.01206 |
| Opus 5 | $0.00019 | $0.00603 |
| Sonnet 5 | $0.00008 | $0.00241 |
| Haiku 4.5 | $0.00004 | $0.00121 |
Grade A, and why
gh-create-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 11d 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 — 56 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Never @mention other users in plan issues or comments.
Create a GitHub issue containing the detailed plan for the work in this conversation.
Plan location. Check ~/.claude/skills/plan-config.json for personalRepo and/or teamRepo (both optional). $ARGUMENTS can be personal, team (resolved from config; fail if the corresponding repo is not configured), or an owner/repo used directly. If no argument is given: use the only configured repo if there is exactly one; ask the user if both are configured; ask for a repo if neither is configured.
- Personal: the
personalRepofrom config. - Company-shareable (team plans and records): the
teamRepofrom config. A plan opened here distills into a team record on close.
Guard. Plan issues should only be created in private or internal repos.
Derive a concise issue title from the conversation context. Ask the user if unclear.
The GitHub issue should be self-contained so that a new conversation can pick up the work without needing additional context. Omit raw exploration and back-and-forth; only include the conclusions.
Think as a software architect first. Before writing steps, consider: What are the key abstractions? Where should boundaries be? What's the simplest design that solves the problem? What will be hard to change later? Let these decisions shape the plan structure.
When a design splits work across layers (e.g. "resolve X in layer A, resolve Y in layer B"), verify what context is available at each layer by reading the actual code. Do not assume context is unavailable without checking.
If a durable-memory CLI is configured, query it with the task's distinctive terms before writing the plan. See the memory tool's own integration doc for mechanics.
Before creating the plan, ask the user if there are related repos with similar implementations that should inform the approach. If so, review them to understand how the problem was solved there, and incorporate relevant patterns into the plan.
Issue body (should rarely need updating):
- What and Why: What problem is being solved and why it matters. Do not include the how/design.
- Prerequisites: List only non-obvious manual steps needed before implementation. Omit this section entirely if there are no real prerequisites.
After creating the issue body, add structural comments in the canonical order below. Each comment starts with a ## heading. These are permanent and must never be deleted (even by gh-close-plan). Session summary comments (added later by gh-update-plan) are non-structural and come after these.
- Steps: Group steps under numbered headings (
### Step 1: ...,### Step 2: ...). Each step contains checkboxes for its sub-tasks, followed by a one-line dependency note below the checkboxes:Depends on: 1, 2orIndependent. Always number the top-level steps explicitly. Steps with a child issue:- [ ] Child issue: owner/repo#N. Checkboxes and the dependency line only - no other prose or narrative. Context belongs in the Design comment. - Design: The chosen approach only. Technical approach, key abstractions, boundaries, trade-offs. Rejected alternatives belong in standalone comments (
## Considered: ...,## Decision: ...), not here. This is where the living design is tracked. - Diagram: Show the flow, structure, or relationships using Mermaid (not ASCII). Pick the right diagram type for the content:
- Temporal flow (request handling, build pipeline, event sequence):
sequenceDiagram. - Static structure (components, dependencies, what connects to what):
flowchartwithsubgraphfor grouping andclassDeffor color-coded categories. Short caption (three sentences max, no "Caption:" prefix).
- Temporal flow (request handling, build pipeline, event sequence):
- Links: Links to relevant documentation, code, resources, and related issues. Do not add PRs here.
- Useful commands: Added by
gh-update-planwhen useful commands are discovered. Not created bygh-create-plan. - Agent sessions: A table
| Session | Directory | Model | Last used | ID |with this session as the first row. Set Last used to today's date (YYYY-MM-DD). Use backtick code formatting for Directory and ID. Replace the user's home directory with~in the Directory column. - PRs: Added by
gh-update-plan. Table:| PR | What | Agent session |.
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.
- 11d ago First seen · 56 lines · 39 tokens per session scan A 38d089d1d960
gh-create-plan is a skill published in the GitHub repository gjoranv/claude-plan-skills (5 stars, last pushed 10d ago), licensed MIT. It adds 39 tokens to every session and 1,206 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
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.
triage
Apply a formal state machine to issues — assign category (bug/enhancement/question/spike) and state (needs-triage → needs-info → ready-for-agent → ready-for-human → wontfix). Issues marked ready-for-agent become inputs to supergraph:plan. Use when processing a backlog, reviewing new issues, or preparing work for…
issue-authoring
Draft or refine IDD-ready GitHub issues, roadmap issues, and sub-issues before the normal IDD execution loop begins. Use when a request is too large or ambiguous for one reviewable change, when work needs decomposition or dependency encoding, or when the user asks for issue drafting, roadmap planning, or…
prd-to-issues
A planning skill that turns an existing product requirements document, or PRD, into small GitHub Issues that developers can implement and verify. It groups work into complete user-facing slices instead of separate front-end, back-end, testing, and documentation tasks.
project-context-steward
A project-documentation skill that scans a new project or several related code repositories and records their shared context in a PROJECT_CONTEXT.md file. It captures the product, users, workflows, architecture, repository boundaries, terminology, entry points, and known pitfalls.
kelly-support
Personal App-in-Skill customer-support desk (help desk) that triages incoming support tickets from email, WhatsApp, web chat, contact forms, and WeChat, drafts KB-grounded replies, and proposes actions, then holds every send behind a human approval queue with a pre-send quality gate (support-qa) that outputs…