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 validate-plangit 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/validate-plan)<a href="https://agentmods.dev/skills/rfxlamia/pocketto/validate-plan"><img src="https://agentmods.dev/badge/skills/rfxlamia/pocketto/validate-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/rfxlamia/pocketto/validate-plan"><img src="https://agentmods.dev/badge/skills/rfxlamia/pocketto/validate-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.00047 | $0.03198 |
| Opus 5.5 | $0.00019 | $0.01279 |
| Sonnet 5.5 | $0.00009 | $0.00640 |
| Haiku 4.5 | $0.00005 | $0.00320 |
Grade A, and why
validate-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 7d 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 — 447 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Validate Plan
Overview
Comprehensive validation workflow for development implementation plans. This skill systematically analyzes plans against DRY (Don't Repeat Yourself), YAGNI (You Aren't Gonna Need It), and TDD (Test-Driven Development) principles while performing codebase-aware gap analysis to prevent implementation disasters.
Use when:
- Reviewing implementation plans created by the Pocket planning workflow or another source
- Validating development plans before execution
- Checking plans for DRY/YAGNI/TDD compliance
- Preventing over-engineering and scope creep
- Ensuring test-first approach in development workflow
Triggers: /validate-plan or "Validate this implementation plan"
Validation Workflow
Step 1: Plan Discovery
Accept either a plan file path or plan text supplied directly in the request. When invoked as a non-interactive reviewer (including the hotfix reviewer dispatch), use the supplied inline plan and do not ask questions or request a file path. If neither a path nor plan text is available in an interactive session, ask the user which plan to review.
For a file path:
- Load plan file
- Extract metadata: feature name, tech stack, hypothesis
- Identify all tasks and their structure
For inline plan text, perform the same analysis from the supplied content without looking for or editing a plan file.
Step 2: Codebase Analysis
Scan existing codebase for:
- Existing implementations of similar functionality
- Reusable components, utilities, patterns
- Project structure and conventions
- Test patterns and frameworks
- Previous implementations that could be referenced
Key questions:
- What functionality already exists that could be reused?
- What patterns are established in the codebase?
- Where should new files be placed?
- What testing approach is already used?
Step 3: DRY Validation
Checklist for Don't Repeat Yourself:
| Check | Description | Finding Level |
|---|---|---|
| Functionality Check | Does the plan propose implementing functionality that already exists? | CRITICAL |
| Code Reuse | Are there existing utilities/components that could be reused? | CRITICAL |
| Abstraction | Does the plan duplicate similar patterns without abstraction? | WARNING |
| Library Choice | Is the plan using the same libraries already in the project? | INFO |
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.
- 7d ago First seen · 447 lines · 47 tokens per session scan A 2c6cd065a429
validate-plan is a skill published in the GitHub repository rfxlamia/pocketto (5 stars, last pushed today), licensed MIT. It adds 47 tokens to every session and 3,198 once invoked, about $0.0002 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-10-10.
Other skills, from other repositories
x-qdev
A compact development workflow for a small, clearly defined code change. It keeps the requirement, initially failing tests, implementation, and real verification results in one task document, following TDD, or test-driven development.
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.
uw-code-review
Pre-commit code quality review for Unity C# code. Checks against Rules, CODINGSTANDARDS.md, NAMINGCONVENTIONS.md, and GDD Gherkin test coverage. Use when code has been written and tests are passing but before committing. Runs automatically at Step 8.5 of /uw-cmd-implement-feature. Triggers on "review this code"…
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…
orchestrated-execution
Execute work units through the rigorous 4-phase Metaswarm cycle (Implement -> Validate -> Adversarial Review -> Commit) with independent quality gate enforcement.