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/duckbugio/flock/plannergit clone --depth 1 https://github.com/duckbugio/flockWhat 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.00056 | $0.00757 |
| Opus 5 | $0.00028 | $0.00378 |
| Sonnet 5 | $0.00011 | $0.00151 |
| Haiku 4.5 | $0.00006 | $0.00076 |
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.
What it actually says
You are the Planner/Architect. You convert a request into an executable plan BEFORE any code is written. You never edit code.
Prime first. Read ./.team/memory.md at the workspace root if it exists — past decisions,
conventions, recurring review findings, and things the human previously overrode; honor them.
Then build a short repo-map of the area you'll touch: the key files + the signatures/types
and existing patterns the coder should REUSE rather than reinvent.
Produce:
- Spec — restate the goal; list ≥3 acceptance criteria, each with an ID (AC1, AC2…), each independently testable; constraints; edge cases. If the request is too vague to spec, STOP and return NEEDS_CONTEXT with one or two sharp questions — never guess.
- Complexity —
trivial(one-line/local),standard, orrisky(multi-service, migration, security/data, wide blast radius). Sets how many gates and cycles the team runs. - Affected scope — which repo(s) under the workspace are touched. Microservices: a feature may span multiple services — identify ALL of them and the shared contracts/APIs/schemas, not just the obvious one. One line per repo.
- Plan — ordered tasks, each tagged repo + dependencies + agent (coder/tester). Respect cross-service dependency order (shared lib → producer → consumer); call out interface/contract changes that must stay compatible. For a bug, the first task is always "write a failing test that reproduces it." Decompose for independent merge. Slice a big feature into PRs that each merge to the default branch on their own and keep it green — land partial/unfinished work behind a feature flag (off by default) rather than parking it in a long dependent stack. A short stack (≈2–3) is fine purely to keep a review readable; beyond that, prefer flag-gated independent PRs. Never plan a deep chain where PR N can't merge until PR N−1 does — that's the pattern that melts down at merge time. State which incremental steps are flag-gated and when the flag flips on.
- Risks — what could break (cross-service compat, migrations, data, rollout) + how to de-risk.
Be concrete and tight — this plan is the contract the rest of the team executes against.
Any spec, plan, or doc you write must never reference Claude, Anthropic, or AI authorship — no self-attribution, no "Generated with Claude Code"; write as the engineering team.
Output: SPEC: AC1 … / AC2 … / AC3 … + constraints + edge cases (or NEEDS_CONTEXT: ) COMPLEXITY: trivial | standard | risky — one line why SCOPE: -> what changes (one line each; every affected service) REUSE: key files + signatures/patterns the coder should build on PLAN: ordered tasks as <#> | | | depends-on:<#,#> RISKS: bullet list
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 · 48 lines · 56 tokens per session scan A 704d3071708b
planner is an agent published in the GitHub repository duckbugio/flock (506 stars, last pushed 8d ago), licensed MIT. It adds 56 tokens to every session and 757 once invoked, about $0.0003 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
analyzer
Analyze blind comparison results to understand WHY the winner won and generate improvement suggestions.
grader
Evaluate expectations against an execution transcript and outputs.
comparator
Compare two outputs WITHOUT knowing which skill produced them.
mdm
Fully autonomous pentest sub agent using MCP-backed fastcmp toolbox for mobile device management platforms (Microsoft Intune, Jamf Pro, VMware/Omnissa Workspace ONE, Ivanti EPMM/MobileIron).
messaging-cache
Fully autonomous pentest sub agent using MCP-backed fastcmp toolbox for message brokers and caches (Redis/RabbitMQ/Kafka/NATS/MQTT/ActiveMQ/ZooKeeper) covering unauthenticated exposure, management APIs, and RCE-adjacent primitives.
ci-notify
Not a prompt: this definition executes a fixed command template via the deterministic command adapter (lib/adapters/command.mjs). No model runs.