Show the one-screen agenttalk overview - what needs attention, who is waiting for whom, and how each agent is doing. Read-only; use when asked how the team is doing.

Before major work starts, ask an independent agent whether it should be done at all. Send a blind brief (outcome, trigger, size - never the pitch), get a typed verdict (proceed / reshape / probe / replace / defer / stop / unassessed), and record what you did with it. Use before dispatching, proposing or starting major work, whoever asked for it.

Confer with a named agent BEFORE answering the user. Send your draft answer + uncertainty, wait for critique, then write a concise final answer that names where you agree/disagree and makes a recommendation. Use for high-impact ambiguous calls and explicit second-opinion requests.

Coordinate a named multi-agent team over agenttalk as a lead. Use when Codex should decompose work, dispatch to named agents or groups, track replies with threads, and report back without starting a teammate's assistant directly.

Send a concrete proposal to a named agent over agenttalk and wait for an accept, reject, or counter response. Use when Codex should propose a specific design, plan, scope, or decision for agreement before proceeding.

Send a single message to a named agent, or broadcast a note/question to a group, over agenttalk. Use when the request does not require waiting for a reply. Requires `python -m agenttalk init` in the project root.

Plan the QA strategy for a change: identify risk areas, recommend test levels and review lenses, state which checks are not needed and why, include cost notes, and identify required close evidence. Use when deciding which tests/checks/lenses are necessary before implementation, review, or release gating. Do NOT use for writing tests directly or replacing test-coverage.

A contract change is only safe when EVERY surface that depends on it moves in the same commit. Drift — code updated, docs/tests/migrations stale — is a confidently-wrong artifact that misleads users and breaks callers. Hunt the surfaces that did NOT change but should have.

Ordinary review asks "does the happy path work?". This asks "what happens when it DOESN'T?". Inject failures mentally (and with a repro where you can) and confirm the code degrades safely. Ground every finding in the actual code; never approve a failure path you only assumed.

A release is irreversible-ish and outward-facing. Decide HOLD or GO on evidence, not optimism. The strongest evidence is automation: prefer a CI-sourced gate over your own read. When unsure, HOLD.

A milestone review is wide: many surfaces, several specialist lenses, real remediation. Its job is to gather honest typed evidence under each required lens and converge on ONE auditable HOLD/GO via `agenttalk close` — not to re-judge code itself. Drive the existing flow; never invent a parallel wo

Produce executable documentation-check evidence by running docs examples, doctests, link checks, command snippets, generated-reference drift checks, and code-vs-doc assertions. Use when documentation needs QA evidence for commands or generated content actually executed. Do NOT use for writing docs (use write-docs), adversarial documentation accuracy, audience, or prose review (use review-docs), integrated code review, or green claims based only on reading documentation.

Produce executable security-testing and abuse-case evidence for a touched surface. Use when a change needs threat-model-backed tests or checks for authz, input validation, injection, path/env/command handling, unsafe deserialization, secrets/log hygiene, dependency or supply-chain exposure, or abuse cases. Do NOT use as a second review-code security pass, for general code review, for speculative vulnerability hunting without scoped tests, or for production fixes without an assigned implementation task.