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.
git clone --depth 1 https://github.com/duckbugio/flockWrote 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/agents/duckbugio/flock/planner)<a href="https://agentmods.dev/agents/duckbugio/flock/planner"><img src="https://agentmods.dev/badge/agents/duckbugio/flock/planner/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/agents/duckbugio/flock/planner"><img src="https://agentmods.dev/badge/agents/duckbugio/flock/planner.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.00056 | $0.00757 |
| Opus 5.5 | $0.00022 | $0.00303 |
| Sonnet 5.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 1mo 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.
- 1mo ago First seen · 48 lines · 56 tokens per session scan A 704d3071708b
planner is an agent published in the GitHub repository duckbugio/flock (502 stars, last pushed yesterday), licensed MIT. It adds 56 tokens to every session and 757 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-08-30.
Other agents, from other repositories
product-manager
Product management expert for roadmap decisions, feature prioritization, and scope management. Acts as a startup PM - ruthlessly prioritizes, focuses on speed over perfection. Use proactively for strategic product decisions.
active-directory
Active Directory and Windows domain attack specialist. Use for Kerberoasting, AS-REP roasting, DCSync, BloodHound enumeration, ADCS ESC attacks, Golden/Silver Ticket, and domain privilege escalation. Triggers on: kerberoast, AS-REP, bloodhound, DCSync, golden ticket, ADCS, ESC, domain controller, LDAP, GPO, AD, domain…
c2-operator
Command and control infrastructure specialist for authorized red team operations. Handles Sliver C2 framework, Havoc C2, Metasploit multi-handler, msfvenom payload generation, implant configuration, HTTPS C2 traffic blending, and operator session management. Triggers on: C2, command and control, Sliver, Havoc…
exploit
Exploitation specialist for gaining initial access. Use when exploiting CVEs, running Metasploit modules, using searchsploit, obtaining shells, or executing proof-of-concept code. Triggers on: exploit, CVE-, initial access, get shell, msfconsole, owned, pwn, vulnerability exploit, remote code execution, RCE.
crypto-attacker
Cryptography and TLS security specialist. Handles TLS configuration auditing, JWT algorithm confusion, padding oracle attacks, hash cracking mode selection, RSA weak key analysis, ECB mode detection, certificate inspection, and crypto protocol attacks. Triggers on: TLS, SSL, cipher, JWT, padding oracle, RSA, hash…
iot-attacker
IoT and embedded systems security specialist. Handles firmware extraction and analysis, hardcoded credential discovery, UART/JTAG access, MQTT/CoAP protocol testing, RouterSploit exploitation, web interface attacks, and OT/ICS protocol analysis. Triggers on: IoT, firmware, binwalk, UART, JTAG, router, embedded…