alawein

check-intent

Use right after implementation is done and before code-review, to reconcile the diff against the plan or the stated ask. Catches a dropped plan item, an unrelated file change, or a silent switch to a different approach before either ships unnoticed.

code-review

Use on a diff or a branch before a PR. A structured correctness-and-standards review that catches the expensive-to-fix issues and gives one honest verdict.

converge

Use when you want to drive an artifact to clean, where clean means zero blockers and zero majors after a full check run. Fix and re-run until clean or a round cap, then report honestly, confirmed minors included. A fix-until-clean loop over lint, tests, review, and scrutiny.

debt-log

Use when recording a deliberate shortcut or a known limitation so it is tracked, not silently accrued. Writes one entry with the reason, the cost, and the trigger to revisit.

panel

Use when a decision or design benefits from several independent expert perspectives. Convenes distinct expert lenses that each judge the decision on its own, then synthesizes agreements, disagreements, and one recommendation. Distinct from prove and grill.

prove

Use when numbers go to stakeholders, a finding is contested, or a claim must survive scrutiny. Proves or refutes many claims by recomputing each from the source of truth and attacking the survivors, then tags every claim with a confidence verdict. The heavier sibling of grill.

repo-hygiene-sweep

Use when several repositories need a read-only hygiene sweep before any repair work begins. Inventories the fleet, proves each finding from its source, and routes safe work without mutating protected targets.

repo-review

Use when a whole repo needs a health audit before you trust or own it. Judges structure, docs truth, test coverage, dead code, and drift between docs and code, then emits findings shaped for triage. An opt-in ownership lens hunts single-owner assumptions when a one-person repo becomes a team surface. Distinct from orient-repo, which maps a repo without judging it.

simplify

Use when changed code works but carries duplication, needless indirection, or waste. Finds and applies reuse, simplification, and efficiency cleanups that preserve behavior. It does not hunt bugs (code-review does) and it is not a planned reshape (refactor-safely is).

split-change

Use when a change has grown to do more than one thing. Detects the separable concerns and splits them into focused commits or PRs, so each is small, reviewable, and revertible on its own.

triage

Use when a findings list (from repo-review, code-review, or a teammate) needs ranking before action. Confirms or doubts each finding against the code, ranks severity, and routes each to fix now, defer, or reject, with a reason. The bridge between finding problems and acting on them.

Data & Documents Listed

write-doc

Use when writing a named coding artifact (a README, a findings note, a report) in the house voice from a supplied template. Produces a findings-first document with the right structure for its kind, plain words, and no padding.

cross-doc-check

Use when two docs are each supposed to state the same policy or rule, to check whether they actually agree. Flags a real contradiction or an unexplained scope gap, never a wording difference where the substance already agrees. Distinct from doc_truth, which checks that a named reference resolves, not whether two docs agree with each other.

debug-failure

Use when a test fails or an error is unclear. A hypothesis-first loop that reproduces the failure, finds the root cause, fixes it, and pins it with a regression test.

grill

Use when a design, plan, or diff needs hostile scrutiny before it is trusted or shipped. It tries to break the design, plan, diff, or claim rather than confirm it, then gives one verdict. Distinct from code-review, which checks correctness.

handoff-session

Use when wrapping a work session or passing work to another agent, or to re-ground a drifting long task mid-flight. Produces a short handoff so the next session resumes with no context loss.

implement-change

Use when executing an approved plan. Makes the smallest correct edits in order, follows the repo's existing patterns, and keeps the tree runnable at each step.

interrogate

Use when a request is vague and you are about to build. Show the hidden assumptions and the success test with sharp questions before any code, so the change is not scoped wrong from the start.

orient-repo

Use on first contact with an unfamiliar repo, before planning a change. Builds a read-only map of how the project is built, tested, and laid out, so the first plan rests on facts, not guesses.

plan-change

Use before writing code for any non-trivial change. Turns a request into a short, concrete plan grounded in the actual repo, so the edit is scoped before a line is touched.

premortem

Use before committing to a plan that is expensive to reverse. Assume it already failed, work backward to the likely causes, and turn the top ones into preventive actions to take now.

prepare-pr

Use when a branch is ready for review. Drafts the commit, the PR title and body, the testing notes, and the risks from the diff, and runs the pre-merge checks.

record-decision

Use when recording an architecture or structural decision. Captures the context, the decision, and the consequences as a short, append-only record so the why survives.

refactor-safely

Use when restructuring code for clarity without changing behavior. Names the before and after and proves the same tests pass before and after the change.

respond-to-review

Use when acting on review feedback on your change. Triages each comment, fixes or pushes back with a reason, and replies so the loop closes before merge. Distinct from code-review, which gives the review.

self-refute

Use right after you produce an answer, plan, or design that matters, to attack your own output before presenting it. A reflexive red-team that hardens the result instead of defending it.

write-tests

Use when adding coverage for new or uncovered code. Generates tests that assert the behavior and the contract, not implementation detail, and that actually run.