Bug-fix pipeline, reproduce-first — the tester captures the bug as a failing test BEFORE the developer may touch production code, then verifies the fix and scans for sibling occurrences of the same defect. Accepts an informal report or a screenshot and clarifies interactively in the main session first; when the bug genuinely cannot be reproduced up front, falls back to writing the regression test right after the fix. Use when the user reports a bug, regression, or broken behavior and wants the team to fix it.
Behavior-preserving restructuring — the existing tests become the frozen invariant that must pass identically before and after, the developer restructures without touching them, and the auditor judges whether the new structure is actually better. Use when the user wants to refactor, restructure, extract, centralize, simplify, or pay down technical debt WITHOUT changing behavior.
Apply when a task changes a public API, endpoint signature or response shape, database schema, serialized or persisted format, event/message contract, or any interface other code or systems consume. Enforces closing the transition safely — consumer inventory, compatibility decision (compatible extension / expand–contract / explicit versioning), migration and backfill plan, deprecation path, and a test strategy covering old and new behavior while both live.
Delivery pipeline from a closed spec — validates the spec mechanically (verifiable acceptance criteria, explicit excluded scope), then runs UX (if user-facing) → developer → tester ∥ auditor → findings loop → documentator, verifying each acceptance criterion from the spec. Use when the user asks to build/implement a spec file, typically one produced by /squad:define.
Conversational spec mode — the main session interviews the user, round by round, until the product definition closes; then writes a spec file with verifiable acceptance criteria, ready for /squad:build. Use when the user wants to define, spec, or shape a feature or product, or when a request is too vague to build directly. Also resumes/revises an existing spec file.
Use before delivering ANY code change to choose and run final validation — the smallest set of build/test/lint targets that covers the real risk of the change, run at the end (not after every tiny edit), never running test commands in parallel, and reporting targets executed, results, and selection rationale.
Read-only team review of a diff, branch, or PR — the auditor (security, structure), tester (contract protection, coverage gaps), and ux (only if user-facing surfaces change) review in parallel; findings are merged, deduplicated, severity-ranked, and delivered with a verdict. Nothing is modified. Use when the user asks the team to review changes without implementing anything.
Apply when a task involves active/inactive states, archiving, visibility or lifecycle; lists reused between management and operational contexts; shared selectors (comboboxes, pickers, multi-selects); different rules for "can be viewed" vs "can be used"; write-path validations that depend on state; or operational filters reused across screens. Enforces closing the semantic architecture — shared base function, semantic wrappers, backend write guard, history handling — and forbids duplicated filtering logic.