Frontier-grade engineering rigor for any model, in three layers: always-on discipline skills (claims, scope, native code, reporting, context), phased process for analysis and delivery (multi-agent deep-analysis audits, disciplined implementation, deep-work orchestration, adversarial verification, a risk-sized route…
Use this agent to execute ONE well-scoped implementation task end-to-end (a feature slice, bugfix, refactor step, or test batch) after the scope is already clear. Ideal for parallelizing independent slices of a larger build. Do NOT use it for ambiguous asks that still need owner decisions — clarify in the main…
Show one feature's whole journey across the suite — idea → PRD → design → tasks → verified → regression-clean → shipped — by composing the existing per-plugin views (read-only; no new store).
Prove a change didn't break existing work — run the suite + a bounded refute-first blast-radius probe vs docs/architecture/ contracts + honest coverage — and emit a structured regression verdict that taskmanager's done-gate enforces.
Route a request to the right top-level pipeline by scope and risk — name the ordered sequence of existing entry points (analysis / trivial change / bug fix / feature-high-risk / health), advisory, then hand control back.
Runs when you submit a prompt, before the agent sees it, executing self_challenge_gate.sh, asset_inventory_gate.sh, ls_real_preflight.sh and session_retro.sh via bash (4 commands). From mwguerra/plugins.
Runs before the agent uses a tool for Bash and Bash tool calls, executing verify_before_commit.sh and verify_commit_gate.sh via bash (2 commands). From mwguerra/plugins.
Take a conclusion, code, fix, or design you just produced and spawn an independent agent to adversarially re-check it — assuming it likely missed something, with the job of finding holes rather than affirming. Trigger: you just reached an important conclusion/fix/design and want to confirm before delivering, or you…
Use at the start of any multi-step task and during exploration — before reading files, searching, or re-checking completed work, especially when tempted to read whole files, re-verify known facts, or run independent lookups one at a time.
Stay focused on the project with the task in hand; recall another project's knowledge ONLY when the task actually needs it. When a task requires changing a shared dependency you own (a local composer/npm package in another repo), make the change IN that owning repo — commit, push, retag — then update and re-verify the…
Use when asked for a deep audit, deep analysis, production-readiness review, architecture assessment, or prioritized recommendations across a whole codebase or subsystem — orchestrates parallel reader agents with adversarial verification and publishes findings to docs/deep-analysis/.
Run a large, multi-place, uncertain task to completion via "plan → adversarial review → serial execute → synthesize & verify." Trigger: cross-file refactor, data migration, large feature build, system audit, deep research — tasks that can't be done in one pass and touch many places. Manual invocation: /deep-work.
Use before ending any turn that used tools or produced a deliverable — when tempted to ask "Want me to…?", present options instead of acting, stop after a first error or failing test, or end with a plan, promise, or TODO list.
Use when asked to implement, build, add, fix, refactor, or change anything non-trivial in a codebase — especially vague asks ("do that", "make it work") that need clarification, planning, and verified delivery with tests and commits.
Use when writing or editing code in an existing codebase — before adding comments, docstrings, try/catch blocks, validation, logging, or TODOs the surrounding file doesn't have, and before explaining your style choices in the reply.
Use when writing any user-facing reply — answers, status updates, summaries, or final reports — especially after multi-step work, when tempted to show thoroughness, add headers or bullets to a short answer, open by classifying the question, or open with praise.
Use before claiming anything works, is fixed, is done, or passes; before status updates on changes you haven't run; before agreeing with someone else's claim about your work; and before state-changing commands like restarts, deletes, or config edits.
The discipline behind maestro:regression — prove a change didn't break existing work by running the suite, an adversarial bounded blast-radius probe against documented architecture contracts, and honest coverage, then emit a verdict taskmanager's done-gate enforces. Trigger: a change is about to be marked done /…