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 rfxlamia/pocketto --skill pocket-planninggit clone --depth 1 https://github.com/rfxlamia/pockettoWrote 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/rfxlamia/pocketto/pocket-planning)<a href="https://agentmods.dev/skills/rfxlamia/pocketto/pocket-planning"><img src="https://agentmods.dev/badge/skills/rfxlamia/pocketto/pocket-planning/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/rfxlamia/pocketto/pocket-planning"><img src="https://agentmods.dev/badge/skills/rfxlamia/pocketto/pocket-planning.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.00076 | $0.06134 |
| Opus 5.5 | $0.00030 | $0.02454 |
| Sonnet 5.5 | $0.00015 | $0.01227 |
| Haiku 4.5 | $0.00008 | $0.00613 |
Grade A, and why
pocket-planning 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 15d 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 — 484 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Pocket Planning
Bridges pocket-grinding spec and pocket-development execution. Scans codebase context, maps file structure, decomposes acceptance criteria into TDD-structured tasks, generates Pocket Packets with test-first steps and commits, then runs a spec reviewer subagent — plus a conditional test strategy audit when any Phase 6 trigger fires (cross-unit GWT scenario, ambiguous test level, persistence/concurrency/network/external-service behavior that materially changes how the task must be tested, or a [test-risk] task) — before handoff.
Core principle: Every task is red → green → refactor → commit. Steps live inside the task. Pocket enforces execution order and parallelism.
Test boundary: Planning owns test intent. Development owns test implementation. Packets carry test intent — never test source code (Phase 4).
When to Use
- pocket-grinding skill has invoked this with a spec path + acceptance criteria
- User says "create plan from spec", "build execution plan", "plan this"
- A spec exists in
docs/pocket/spec/and needs to become executable tasks
Do NOT use:
- Without a completed pocket-grinding spec (use pocket-grinding skill first)
- To re-plan a task already in execution (use pocket-development directly)
Operating Rules
- Start from the user's request. Use a clear handoff, correction, or approval already given. Do not ask the user to repeat a decision or choose a numbered option.
- Recover missing context first. Search the conversation and expected spec directory before reporting an input missing. Treat open questions as optional; record
none identifiedwhen there are none. - Preserve independent review with bounded recovery. A separate Spec Reviewer must review the plan, and a Test Strategy Audit must run when its triggers fire. After the initial review, allow at most two materially different correction/review or reviewer-recovery rounds for each review gate. At the cap, report
RECOVERY_CHECKPOINT, preserve findings, and wait for explicit user authorization before another bounded window. Never claim approval or hand off with unresolved blocking findings. - Use evidence for library decisions. Check the version in the lockfile or proposed dependency and query version-matched documentation. When a source is missing, try official documentation or release notes and record what remains unverified.
- Honor the authorized handoff. If the user clearly requested plan generation and structuring, that instruction authorizes the plan handoff once the required checks pass. Otherwise, present the completed plan and wait for approval before generating derived execution artifacts. This approval never authorizes implementation.
What ships with it
6 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 15d ago Changed · -7 lines 85f6f3a3d1af
- 17d ago Changed 9e739b24e7ac
- 1mo ago Changed · -123 lines 6e03e1ca94d3
- 1mo ago First seen · 614 lines · 76 tokens per session scan A 8456a539630c
pocket-planning is a skill published in the GitHub repository rfxlamia/pocketto (6 stars, last pushed 7d ago), licensed MIT. It adds 76 tokens to every session and 6,134 once invoked, about $0.0003 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
codex-ab
Run an A/B codex review experiment — holistic codex review vs 3 focused dimension passes (security, ecto, liveview) on the branch diff, classify findings, report a panel-value verdict. Use when the branch is fresh, before any codex review runs.
improve-code-quality
Guided journey from a working-but-untested vibe-coded prototype to a production-ready product with tests, clean structure, a business-rules boundary, and resilience at scale. Orchestrates nine skills phase by phase - working-with-legacy-code, clean-code, refactoring-patterns, software-design-philosophy…
codex-loop
Fix Elixir/Phoenix code until Codex CLI review comes back clean — bounded review, fix, verify loop before opening a PR. Use when codex is installed and you want an external cross-model critic on your changes before pushing.
test-strategy
Coverage-design method for qa-engineer — pyramid ratios per archetype, equivalence/boundary/property case selection, mutation score as the real coverage signal, and a flake-quarantine policy. Turns "coverage is 90%" (a number with no method) into a defensible test plan. Emits TEST-STRATEGY-{slug}.md, which the QA gate…
quant-validation
The methods a financial-ML result has to survive before it is evidence — purged cross-validation with an embargo, triple-barrier labelling, sample uniqueness under overlapping labels, fractional differentiation, meta-labelling, and multiple-testing correction. Written because the invariants were required of…
test-audit
Audit test suites for T1-T4 violations using AST analysis, mock detection, and multi-stage synthesis. Invoke when user asks to audit tests, check test quality, find mock violations, review test effectiveness, or inspect test suites for over-mocking. Triggers automatic rewrites when quality gates fail.