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 lacerbi/dotclaude --skill plangit clone --depth 1 https://github.com/lacerbi/dotclaudeWrote 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/lacerbi/dotclaude/plan)<a href="https://agentmods.dev/skills/lacerbi/dotclaude/plan"><img src="https://agentmods.dev/badge/skills/lacerbi/dotclaude/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/lacerbi/dotclaude/plan"><img src="https://agentmods.dev/badge/skills/lacerbi/dotclaude/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.00010 | $0.02502 |
| Opus 5.5 | $0.00004 | $0.01001 |
| Sonnet 5.5 | $0.00002 | $0.00500 |
| Haiku 4.5 | $0.00001 | $0.00250 |
Grade A, and why
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 — 215 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are planning, not executing. Explore and analyze first; probing is part of that — run scripts, tests, or quick experiments where they resolve a real uncertainty about the task. Don't start on the task itself until the user confirms the plan.
Phase 1: Task Understanding
State your understanding of the task: $ARGUMENTS
If unclear, use AskUserQuestion to clarify before proceeding.
Assess complexity to calibrate planning depth:
- Simple: Single-focus task, few components → lighter exploration, concise plan
- Moderate: Multiple components or unknowns → targeted exploration, structured plan
- Complex: Cross-cutting concerns, many dependencies → thorough exploration, detailed plan
Phase 2: Exploration
Explore the project to understand what exists and what the task involves. Scale exploration to task complexity.
For simple tasks: You may explore directly without subagents.
For moderate/complex tasks: Spawn Explore agents in parallel (Agent tool, subagent_type='Explore'), each focused on a relevant aspect:
- Structure Explorer: Project organization, key components, how things connect
- Prior Work Explorer: Existing similar work, patterns, or approaches to build on
- Context Explorer: Related materials, dependencies, constraints
- Domain Explorer: Subject matter, conventions, standards relevant to the task
- Docs Explorer: Documentation (READMEs, guides, API docs, comments) — what exists in or adjacent to the task area, what will need updating, and what doesn't exist yet but should
(For code-heavy tasks: Architecture, Feature, Dependency, Test explorers may be more appropriate)
Explore agents run as Opus (see Agent Selection in the global CLAUDE.md). Instruct them to:
- Return hypotheses, not conclusions
- Provide full file paths for relevant files
- Identify locations, not deep analysis
- Be thorough but efficient - scouts, not implementers
Phase 3: Synthesis
After exploration:
- Read/verify key files and materials identified — verify, don't assume
- Confirm or refute hypotheses
- Build a mental model of the current state and what the task requires
- Identify existing documentation that must be updated, and whether any new document has a distinct durable purpose
- Decide the execution shape — what you will do yourself and what you will delegate to Opus sub-agents (see Phase 4) — and record it per phase when writing the plan
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 Changed · -1 lines a3da8a79d730
- 1mo ago Changed · +29 lines 709be6b71d8b
- 1mo ago First seen · 187 lines · 10 tokens per session scan A cc10ec73b247
plan is a skill published in the GitHub repository lacerbi/dotclaude (2 stars, last pushed yesterday), licensed MIT. It adds 10 tokens to every session and 2,502 once invoked, about $0.0000 per session on Opus 5.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
bet-on-it
Use when debugging or changing behavior based on an uncertain causal hypothesis that the next action can test.
prove-me-wrong
Use when a leading diagnosis or nontrivial fix has initial support and needs one adversarial counterexample before acceptance.
archaeologist
Use when changing unusual or defensive code, mature APIs, dependencies, or architecture, or estimating a migration where Git history may reveal hidden constraints.
no-vibes
Use when completion depends on an end-to-end outcome across components, environments, or external systems.
red-button
Use when an action could cause material, hard-to-reverse harm to production, data, security, finances, users, or external systems.
organizing-files
Organizes macOS files across Desktop, Documents, Downloads, and iCloud Drive into a consistent structure. Use when the user asks to organize files, clean up folders, sort downloads, declutter desktop, tidy up documents, or structure their filesystem. Triggers on "organize", "clean up", "sort files", "declutter", "file…