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.06747 |
| Opus 5 | $0.00038 | $0.03374 |
| Sonnet 5 | $0.00015 | $0.01349 |
| Haiku 4.5 | $0.00008 | $0.00675 |
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 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.
How it starts
The opening of the file, as written. The whole thing — 614 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)
Hard Gates
GATE 0: POCKET-GRINDING HANDOFF VERIFICATION.
Before doing ANYTHING else, verify you have ALL of these:
- [ ] Spec file path (e.g., docs/pocket/spec/YYYY-MM-DD-slug/topic.md)
- [ ] Acceptance criteria (full GWT list)
- [ ] Architecture constraints
- [ ] Design decision
- [ ] Open questions / assumptions
If ANY is missing → STOP. "HANDOFF_INCOMPLETE: Missing [list missing items].
Return to pocket-grinding or provide manually."
Do NOT proceed to Phase 0 until all inputs are verified.
GATE 1: Spec must exist and be readable. Missing → ask user for correct path.
GATE 2: Acceptance criteria must be present and usable.
Rules with GWT → use directly.
Rules without GWT → derive behavioral assertions, mark [derived].
No acceptance criteria at all → STOP. Return to pocket-grinding.
GATE 3: Design Decision section must be present in spec.
Missing → STOP. "Design Decision not found. Return to pocket-grinding
or provide the decision manually." Do not proceed to Phase 2.
GATE 4: Spec Reviewer must APPROVE before the plan is presented at the Phase 7
approval gate.
Issues Found → fix plan, re-run reviewer. Do not skip.
(Phase 6 is conditional — an APPROVE is required whether or not it runs.
If Phase 6 changes the plan, it is re-reviewed before Phase 7.)
GATE 5: User must approve the final plan before ANY downstream handoff.
All plans hand off to pocket-structuring (which generates the execution-plan/ index and task files).
Running `structure --dry-run` is validation only and never authorizes a handoff.
Do not invoke pocket-structuring before the user explicitly approves.
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.
- 10d ago First seen · 614 lines · 76 tokens per session scan A 8456a539630c
pocket-planning is a skill published in the GitHub repository rfxlamia/pocketto (5 stars, last pushed 18d ago), licensed MIT. It adds 76 tokens to every session and 6,747 once invoked, about $0.0004 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
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.
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.
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…
independent-review-loop
Independent review loop run before delivery in code work. An independent reviewer (Codex, or fresh Codex-style subagents) reads the whole PR against the approved outcome; the lead fixes in-scope functional findings and re-reviews until none remain. Its differentiator is independence and exhaustiveness — a reviewer…
fec-component-testing
A guide for writing and reviewing front-end unit, component, and lightweight integration tests. These tests check small pieces of code and UI behavior without running a full browser journey.