Skills catalog
Paste-ready block for any agent that reads AGENTS.md (Cursor, Antigravity, Codex, Copilot, …)
but lacks native Agent Skills discovery. Regenerate with python3 scripts/render-catalog.py.
Skills
The following skills provide specialized instructions for specific tasks. When a task matches a
skill’s description, read the SKILL.md at the listed path and follow it before proceeding.
Installed location: ~/.agents/skills/<name>/SKILL.md (or this repo’s skills/<name>/SKILL.md).
- duck-break — Attack a ‘finished’ build to find out how finished it actually is. Use when a build claims completion, security-, privacy-, or data-sensitive work lacks dynamic evidence, only a green test suite supports the claim, or the user asks to “try to break it”, “red team it”, or “duck break”.
- duck-campaign — Carve a grand vision into independent workstreams that ship without waiting on each other. Use when the user asks to start a campaign, execute all plannable work, turn a vision, a backlog, or competitor gaps into parallel builds, or provides a broad directive spanning many work items without an existing campaign structure.
- duck-cut — Shrink a backlog the honest way — obsolete work out, duplicates merged, viable items unblocked. Use when the user asks to cut or clean a backlog, critique open or blocked backlog items, autonomously close, cut, merge, or unblock every item that does not need the owner, or when open, blocked, and deferred work keeps accumulating.
- duck-decide — Walk the owner through the decisions they have been ducking, one at a time. Use when open decisions, blocked obligations, or approvals need the owner’s answer, the user asks to walk through decisions or options, or several owner decisions are pending.
- duck-diet — Put agent context, memory, and token costs on a diet without starving the essential guidance. Use when the user asks for minimum tokens, a session-cost analysis, an agent setup health check, or trimming of CLAUDE.md, AGENTS.md, or memory, when picking which model tier or agent type a stage runs on, or before a long campaign or multi-agent run.
- duck-dry — Strip comments, docstrings, commit messages, and PR descriptions until only unobvious decisions, contracts, and traps survive. Use when generated code or tests carry narration, storytelling, or change history in comments, when a comment restates the line under it, when a commit message or PR description narrates instead of carrying what the diff cannot, before committing or reviewing generated code, or the user asks to dry, prune, or de-slop comments or commit prose.
- duck-frame — Settle a system’s target design before planning begins, because ‘we’ll figure out the architecture later’ means never. Use when the user asks for system analysis, system design, architecture options, or requirements and constraints before planning, when implementation is about to start against an architecture nobody wrote down, or when a change is large, architectural, security-, privacy-, or data-sensitive.
- duck-land — Merge approved work, update project records, and clean up the branch and worktree; landed means nothing left behind. Use when a change has passed its review gate, the user says to land, merge, push, or ship, a gate-passed PR is ready, or merged work was never recorded in status or outcome documentation.
- duck-learn — Turn session and delivery evidence into reusable lessons, so each mistake is only paid for once. Use when the user asks for a retrospective, wants to mine sessions or outcomes, asks what should become a skill or where tokens were wasted, or after a campaign, incident, or review gate needed many rounds.
- duck-plan — Catch architectural and implementation risks before the code catches them for you. Use when planning or implementing large, architectural, security-, privacy-, or data-sensitive work, including when implementation is about to start against no plan at all, when a plan needs decorrelated co-authorship rather than a same-family draft, or when similar work previously failed several review rounds.
- duck-proof — Give ‘completed’ work a skeptical second pass before anyone trusts it; ‘it should work’ is not evidence. Use when an implementation claims completion, the evidence is mostly “it should work”, the user asks to verify or prove the work, or before handing a change to an independent review gate.
- duck-race — Put two decorrelated model families on the same problem and let executed evidence pick the result. Use when the user says “race it”, “duck race”, or “ping-pong”, wants two models tackling one problem, a task has several plausible implementations worth comparing, generated tests keep passing without catching real defects, single-attempt builds of similar work kept failing review, or a review-fix loop keeps faulting the fixes instead of the original change.
- duck-review — Run one independent cross-model superreview and deliver an evidence-backed APPROVE, REJECT, or NOTE; no participation trophies. Use when a PR or diff is ready to review, a security-, privacy-, or data-sensitive change reaches its release gate, the user says “gate it” or asks for an independent second opinion. It reviews and judges; it does not fix, repeat, or land.
- duck-roast — Roast an entire product, solution, or architecture from every angle until only the defensible parts remain. Use when the user asks for a roast or repeated full critique of the standing solution, wants a codebase audited for over-engineering, bloat, or what could be deleted repo-wide, or wants a milestone-level adversarial assessment rather than a change review or backlog sweep.
- duck-run — Deliver a high-risk change end to end without trusting any stage of it. Use when the user requests end-to-end delivery with adversarial plan critique, says “duck it” or “ground, plan, critique, execute on green, verify, gate”, or asks for a duck run.
- duck-scan — Find ready, blocked, and remaining work without changing anything; looking is free. Use when the user asks what is next, open, ready, left, or available to pick up, requests status, or asks whether a named work item is ready.
- duck-shape — Shape code as it is written so the next reader holds as little as possible; the unit is concepts, not lines. Use when writing or restructuring code, when one edit needs five files opened first, when a layer or a name hides where the work happens, when a hand-rolled helper or one-call dependency costs readers more than it saves, when comments pile up around one function, or when the user asks for a duck simplification or to cut something over-engineered down to what a reader can hold.
- duck-sweep — Clean out stale branches, worktrees, checkouts, scratch directories, and ignore rules; the pond stays clean. Use when the user asks for repository cleanup across one or more repos, or when stale worktrees and temporary artifacts have accumulated after merged work.
- duck-why — Name the cause of a failure before anyone writes a fix, because the symptom is not the defect. Use when a test fails, a bug is reported, a build breaks, something behaves differently than expected, a fix keeps not sticking, or the user asks why something is broken.