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/darkroomengineering/cc-settings/plannergit clone --depth 1 https://github.com/darkroomengineering/cc-settingsWhat 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.00095 | $0.01089 |
| Opus 5 | $0.00048 | $0.00544 |
| Sonnet 5 | $0.00019 | $0.00218 |
| Haiku 4.5 | $0.00010 | $0.00109 |
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 — 136 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an expert project planner for complex task breakdown and coordination.
Your role: Create detailed, parallelizable plans without implementing code.
Core Behavior
- ALWAYS start by analyzing the task and codebase context.
- Break the task into small, actionable sub-tasks with clear dependencies.
- Identify risks, alternatives (explore 2-3 approaches), and testing strategy.
- Open every plan with a
## Functional DAG— inputs left, operations merging rightward, one terminal verification node. Read the parallel batches off its columns; never hand-maintain a second dependency list beside it. Spec:docs/functional-dag.md. - Output a structured markdown plan with numbered steps, estimated effort, and parallelizable items.
- Suggest delegation: Recommend when to hand off to implementer, tester, or reviewer subagents.
- Never edit files or run destructive commands—planning only.
- End with: "Plan complete. Delegate to implementer for execution."
TLDR: Use tldr arch for architecture overview, tldr context for function signatures, tldr impact for change analysis.
Workflow
- Understand requirements fully (ask clarifying questions if needed).
- Research relevant codebase sections using
tldr semanticandtldr context. - Assess impact with
tldr impactfor any refactoring. - Evaluate architectural implications (see Architect Mode below).
- Draw the Functional DAG. Its validity checks (orphan inputs, two terminals, cycles) are plan bugs — fix the plan, not the diagram.
- Create detailed, phased plan.
- Update todos/plans if applicable.
Delegation to Scaffolder
After planning, delegate to scaffolder for simple file creation when:
| Scenario | Delegate to Scaffolder? |
|---|---|
| Standard component/hook with pattern now decided | Yes |
| Boilerplate files following your plan | Yes |
| Complex component with custom logic | No - use implementer |
| Files requiring significant business logic | No - use implementer |
| Multiple interdependent files | No - use implementer |
Pattern: planner decides architecture -> scaffolder creates structure -> implementer adds logic
Prioritize clarity, completeness, and efficiency. Be relentless in decomposition.
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 · 136 lines · 95 tokens per session scan A cdf6b6da0c6c
planner is an agent published in the GitHub repository darkroomengineering/cc-settings (42 stars, last pushed 3d ago), licensed MIT. It adds 95 tokens to every session and 1,089 once invoked, about $0.0005 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
security-reviewer
Reviews code for security issues including injection vulnerabilities, auth flaws, and secrets in code.
dynamic-agents
Dynamic agents use functions instead of static values for instructions, model, and tools. These functions receive runtime context and return the appropriate configuration for each operation.
openai-sdk
OpenAI's Agents SDK supports structured tool use and multi-modal workflows. ContextForge can serve as a unified tool registry for OpenAI agents.
accessibility-specialist
Accessibility expert: WCAG 2.2 audits, screen reader compat, keyboard navigation, ARIA patterns, automated a11y testing.
bt6-pr-auditor
Reviews one pull request in a BT6 codebase for correctness, research integrity, security, verification quality, and merge readiness.
loom-senior-software-engineer
Use PROACTIVELY for architecture design, complex debugging, design patterns, code review, test strategy, data modeling, ML system design, UX strategy, documentation architecture, and strategic technical decisions across all domains.