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/eveld/claude/write-plan-docnpx skills add eveld/claude --skill write-plan-docgit clone --depth 1 https://github.com/eveld/claudeWhat 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.00024 | $0.01022 |
| Opus 5 | $0.00012 | $0.00511 |
| Sonnet 5 | $0.00005 | $0.00204 |
| Haiku 4.5 | $0.00002 | $0.00102 |
Grade A, and why
write-plan-doc 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 2d 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 — 148 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Write Plan Document
Create structured implementation plans following project conventions.
Document Structure
Use the template from templates/plan-document.md:
- Overview - Brief description
- Current State Analysis - What exists now
- Desired End State - Specification and verification
- What We're NOT Doing - Explicit out-of-scope items
- Implementation Approach - High-level strategy
- Project References - Links to commands.md and testing.md
- Phases - Detailed implementation steps
- Changelog - Implementation tracking (created during implementation)
- Not created by plan command
- Implementation command creates and maintains it
- Used for auto-correction loop
- Testing Strategy - Unit, integration, manual
- References - Links to tickets, research
File Path and Naming
Determine feature slug first using determine-feature-slug skill:
- If implementing from existing research: Use same slug (same directory)
- If new feature: Auto-detect namespace and next number, suggest description from plan title
- Prompts user to accept or customize
Save to: thoughts/{namespace}/NNNN-description/plan.md
Example workflow:
- Planning from research doc
thoughts/erik/0005-authentication/research.md - Skill suggests:
erik/0005-authentication(same directory) - Document saved to:
thoughts/erik/0005-authentication/plan.md
Collaboration: Plans start in personal namespace. Use share-docs skill to promote to thoughts/shared/ when ready for team implementation.
Backward compatibility: Old path thoughts/shared/plans/YYYY-MM-DD-NN-description.md still recognized.
Phase Structure
Each phase must include:
Overview - What this phase accomplishes
Changes Required - Specific files and code changes
Success Criteria - Split into two sections:
- Automated Verification: Commands that can be run
- Manual Verification: Human testing needed
Milestone Structure
Group related phases into testable milestones:
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.
- 2d ago First seen · 148 lines · 24 tokens per session scan A e99847b99084
write-plan-doc is a skill published in the GitHub repository eveld/claude (10 stars, last pushed 6mo ago), licensed MIT. It adds 24 tokens to every session and 1,022 once invoked, about $0.0001 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
code-indexing-pipeline
How Infigraph turns source into a graph — adding a language (tree-sitter vs ANTLR grammar-plugin), cross-file call resolution, SCIP compiler-grade enrichment, and file-watch/reindex triage. Use when adding language support, debugging unresolved calls or SCIP import, or triaging stale index/watcher issues.
analysis-subsystems
How Infigraph's multi-repo/group mode and taint analysis work internally — HTTP contract extraction heuristics, cross-service edge linking, combined-graph merge, remote mode, plus taint's line-based tracking and sanitizer heuristic. Use when working on crates/infigraph-core/src/multi/ or src/taint/, or investigating…
review-pr-against-issue
Review one or more PRs against the GitHub issue(s) they claim to fix, including fetching PR branches directly when gh can't reach github.com (e.g. gh is authenticated to an enterprise host instead). Use whenever asked "does this PR fix issue.
opencli-sitemap-author
Use when creating or maintaining OpenCLI site sitemaps: agent-facing navigation, page-state, action, workflow, API-reference, pitfall, and fallback knowledge for a website. Use after browser exploration discovers durable site context, when a sitemap is stale, or when promoting local site knowledge into the repo.
golden-rss
Use when testing the rss golden build.
omh-code-review
This is a Hermes-native code-review workflow skill.