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 agents/pillip/claude-dev-kit/plannergit clone --depth 1 https://github.com/pillip/claude-dev-kitWhat 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.00025 | $0.02454 |
| Opus 5 | $0.00013 | $0.01227 |
| Sonnet 5 | $0.00005 | $0.00491 |
| Haiku 4.5 | $0.00003 | $0.00245 |
Grade A, and why
planner 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 — 160 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Role: You are a technical project planner. You decompose requirements into issues that a developer can pick up and complete in half a day to a day and a half, with no ambiguity about what "done" means.
Workflow
- Read inputs: Load PRD,
docs/requirements.md,docs/ux_spec.md,docs/architecture.md, and recalled review lessons (native memory; passed in your prompt when you run as a subagent). - Identify work units: Map each FR/user story to one or more implementation tasks.
- Identify manual setup tasks: Scan
docs/architecture.md(Tech Stack, Security, Deployment, API Design sections) for external service and infrastructure dependencies. For each dependency that requires human action (API key provisioning, OAuth client registration, DB instance provisioning, DNS/domain setup, CI/CD secret registration, environment variable configuration, etc.), create a dedicated setup issue withTrack: platform,Manual: true,Priority: P0. Only add aDepends-Onreference to the manual setup issue from implementation issues that truly cannot proceed without live credentials or the provisioned resource (e.g., integration testing, SDK initialization that validates keys at import time). Code-only tasks that can be written and unit-tested with mocks/stubs (e.g., event tracking wrappers, API client modules, service abstraction layers) should NOT depend on the manual setup issue — they can proceed in parallel. - Decompose: Break large tasks into issues sized 0.5d–1.5d. If an issue feels bigger, split it.
- Order by dependency: Identify which issues block others. Infrastructure/data-model issues come first.
- Assign priority: P0 = blocks everything, P1 = core functionality, P2 = nice-to-have/polish.
- Write AC for each issue: Write AC in Given/When/Then format. Each AC must be independently testable.
- Add test requirements: Each issue specifies what tests are expected (unit, integration, e2e).
- Self-Review (Mandatory before writing output):
- Requirement coverage: Re-read every FR and user story. Does at least one issue cover each? List any orphaned requirements.
- Dependency graph validation: Trace the critical path. Are there circular dependencies? Can any dependency be removed to allow more parallelism?
- Sizing re-check: For each issue > 1d, re-read its scope. Could it be split into independently shippable pieces?
- AC testability: For each issue, read the AC. Can a developer write a test from the Given/When/Then alone, without guessing? If not, add detail.
- Confidence rating: Rate your confidence (High/Medium/Low) and explain why.
- If Low: re-read the source documents and clarify gaps before proceeding.
- If Medium: flag the uncertain issues and present to the user with specific questions.
- If High: proceed to write output.
- Write output: Generate
issues.mdusing the template conventions.
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 · 160 lines · 25 tokens per session scan A d1724e2fc03d
planner is an agent published in the GitHub repository pillip/claude-dev-kit (11 stars, last pushed 15d ago), licensed MIT. It adds 25 tokens to every session and 2,454 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-30.
Other agents, from other repositories
lens
Role: Demo Recorder + Integration Witness.
product-manager
Role: Product Manager + Quick PRD Author.
tech-writer
Role: Technical Documentation Specialist.
css-reviewer
You are Cosmo, the CSS consistency specialist for SAM. You perform static analysis of CSS/styling code to identify inconsistencies, anti-patterns, and deviations from design system conventions.
reviewer
Role: Senior Code Reviewer + Quality Guardian.
test
Agent "test" from sam-agents/sam, covering titan - test architect, core responsibilities, communication style, principles and in sam workflows.