Bring your agent a duck
No native skill discovery? Give this block to 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 duck reads before it speaks. When a task matches a skill below, read its SKILL.md and
follow it before proceeding. Challenge the claim, run the check, keep the evidence.
English is the home language; match task intent across languages. Follow the user’s
language unless they ask otherwise, keeping commands, paths, identifiers, quoted errors and verdicts unchanged.
Installed location: ~/.agents/skills/<name>/SKILL.md (or this repo’s skills/<name>/SKILL.md).
- duck-break — Try to break a system’s claimed behavior, then show what actually happened. Use when the user asks to break or red-team work, when a behavioral proof needs hostile inputs, or when high-risk work lacks dynamic evidence. Test the actual candidate and substantiate failures.
- 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 for redundant comments, generated code narration, or commit and PR prose that repeats the diff; before committing or reviewing generated code. Preserve parsed directives. Not ordinary prose editing.
- duck-frame — Settle a system’s target design before planning begins, because ‘we’ll figure out the architecture later’ means never. Use for system analysis, architecture choices, or unsettled requirements and boundaries. Reuse a settled design when its assumptions still hold.
- duck-land — Merge approved work, run a described release process when asked, record what landed, and clean up the branch and worktree; landed means nothing left behind. Use when a change has passed its review gate and the user authorizes landing, merging or a release, when a gate-passed PR or version bump is ready, when the user asks what the landing or the push itself will check first, including a push that makes a repository public, or when 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 — Find the hole in the plan before building over it; assumptions and acceptance checks must survive challenge. Use for implementation planning, consequential uncertainty, or work that previously needed repeated review fixes. Reuse established design decisions and cut speculative tasks.
- duck-proof — Make the goal, the path, and the finished work earn your trust through counterexamples and executed checks. Use when the user asks whether a solution is necessary, correct, or elegant, asks to prove a goal, a plan or a finished shape, asks whether every piece of finished work is earning its place before review, or wants work verified before review.
- duck-race — Put two different 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 — Review work from multiple angles or deliver an independent judgment. Use for designs, plans, documents, code, local changes, completed work or PRs; findings-only reviews; an independent second opinion; a release gate; or to answer a review you received, saying which comments still apply to what you pushed since and drafting the replies. Findings-only review stays in-session; independent and release reviews use cross-model scrutiny and return APPROVE, REJECT, or NOTE. It does not fix, repeat, or land.
- duck-roast — Roast the whole solution until its weak claims show; a finding must earn its place, and a round must end. 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 — Challenge the goal, shape the plan, build it, and make it prove itself; local means local. Use when the user asks to duck a task, apply selected findings, or carry work through the delivery flow. Continue to independent review and landing only within the authorized endpoint.
- 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 — Make every layer earn its place; cut the machinery the problem never asked for. Use when the user asks to simplify, shorten or clean up code or tests, calls it over-engineered, bloated, too defensive, duplicated or AI slop, asks to cut a repeated check, inline a supposedly pointless wrapper or drop an unused mode or flag, asks which of two designs carries less, or asks if finished work has its simplest structure, even in a small file or pasted snippet that already looks plain. A request to cut is enough to check what the cut would lose. Not for explaining code, renaming, or comments alone.
- duck-split — Hold a branch, PR or document to the one thing it was opened for; nothing rides along, nothing falls off. Use when the user asks what in a branch, PR, document or plan does not belong to the original task, asks to extract, split or move part of it into its own branch, PR or document, or whether it still carries only what it was meant to.
- duck-sweep — Clean out stale branches, worktrees, checkouts, scratch directories, and ignore rules; the pond stays clean. Use before deleting branches or worktrees, even on a blanket order to delete them all, and 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 or CI goes red, a traceback or error is pasted, something passes in one place and fails in another, a fix keeps not sticking, or the user asks why something fails, even when the code is pasted inline and the cause looks obvious. Also when the user asks who added a constant, timeout, flag or guard and why, or whether that reason still holds, even though nothing is failing. Not for explaining how something works.