agent-debuggingUse when you are an engineer and a task's verification fails after your edit, to debug it alone, record each failed fix, and stop blocked at the third.
agents-assembleUse when starting, resuming, or continuing the mightymodels per-task work loop for a staged ticket (after game-plan or one-shot): engineer dispatch per task, a fact-checker dispatch to check it, the primary comparing the two reports and recording its verdict with `task_verify`, architect once on fai
ask-an-adultEscalate a stuck decision to the wingman advisor and act on what comes back. Builds the escalation packet, dispatches wingman, then puts wingman's questions to the user through `AskUserQuestion` before any work resumes. Not for retrieving facts (send a scout), not for work you can simply do, and not
baton-passHand the current session to the next one without losing what this session learned. Works from an active ticket (mid-sprint, or after stick-the-landing went green and review is next) or from a session with no ticket at all. Writes an objective snapshot from the recorded state first (the snapshot tool
becoming-merge-vaderThe merge-vader reviewer's doctrine: judge whether a branch or a codebase is safe to merge by reading the whole diff, sending code-scout, web-scout and qualitylens for the facts the diff cannot show, grading findings on a four-step severity ladder across security, SDLC regressions, quality, document
becoming-uncle-bobThe uncle-bob reviewer's doctrine: grade a branch or a codebase against Robert C. Martin's SOLID principles, Clean Code smells catalog and Clean Architecture component metrics, with findings tied to named principles, evidence divided between the reviewer's own read and code-scout and qualitylens, an
break-it-downSplit one mightymodels task that is too large into tasks of one reviewable unit of work each, and put the split to the user before anything changes. Size is guidance. Use when `task_start` warns that a task is large, when an engineer or architect returns `too-large` with its cuts, or when a plan tas
crashoutUse when the user explicitly invokes crashout to record dissatisfaction, diagnose the failure, and await approval before resuming work.
cross-examineInterview the user about a plan, design, or decision until a shared understanding exists, at a depth the user picks first (Skim, Standard, or Relentless). Works the design tree in rounds: each round asks every decision whose prerequisites are settled, via AskUserQuestion only, two to four concrete o
game-planLarge-scope ramp for a mightymodels ticket: read ticket.yml and the issue, verify the ticket's claims with scouts, run cross-examine so the user decides the design before drafting, interview the user (AskUserQuestion) on how each risk is handled, then write the ticket's plan.md as a compaction-safe
lets-investigateRun a chat-first investigation as a gated loop: frame one target, dispatch scouts for repository facts and documentation facts, fold every report into a restated in-chat ledger (knowns, open questions, decisions, resources), then stop at an AskUserQuestion gate where the user chooses to dig further,
one-shotFast ramp into the mightymodels work loop from whatever context exists: an active ticket, a pasted issue, or a task described in chat. One AskUserQuestion dialog covers the questions open-ticket would have asked and that the context has not already answered (slug, scope, branch, progress view), then
open-ticketTurn an understood problem into a staged unit of work: one AskUserQuestion interview (slug, tracker GitHub / Jira / both / none), then the ticket directory, a Findings rollup from the lets-investigate ledger or what-we-know, the GitHub issue and/or Jira ticket (a draft file when the CLI is absent) w
prompting-subagentsBuild, review, or repair the dispatch packet for a mightymodels worker: choose the right worker (code-scout, web-scout, qualitylens, fact-checker, engineer, architect, intern, merge-vader, uncle-bob, gitty-up, wingman, terry-toolchain), fill its role template, resolve its model from ticket.yml, and
prune-ticketClose out a finished mightymodels unit of work: close_check refuses while live work remains (unverified tasks, a live whats-broken.md, undecided or unfixed review findings, unpushed commits), compacts the ticket's recorded state into a 30-line archive at .mightymodels/archives/<slug>.md with a JSON
review-circusReview a diff, branch, ticket, or whole codebase with the mightymodels persona reviewers. One AskUserQuestion gate sets depth (quick runs its reviewers on sonnet, standard and deep on opus), persona emphasis, and scope; the `review_*` tools record the run, `review_metrics` and qualitylens's signals
stick-the-landingClose an mightymodels sprint: gate the push on `task_ready`, push, open the PR with a checked body, have gitty-up watch CI, and route each failing check as a recorded C task (mechanical fixes to an engineer residual, then architect once; non-obvious causes to whats-broken), treating CI as the hard g
what-we-knowConsolidate what is established about a problem, claim, behavior, or dependency into a knowns table with file:line or URL citations, an uncertainties list, and an analysis shaped by the question (causal chain for a behavior, verdict for a claim, fit for a dependency, SWOT for a proposed change), clo
whats-brokenUse when CI has a non-obvious failure, a test resists repair, or behavior contradicts expectations after repeated verification.