Run general-review and deep-code-review together as one consolidated review. Use when the user asks for a full code review, a combined general and deep review, or a comprehensive review of code, a diff, branch, or pull request.
Clone/checkout an ai-dynamo/dynamo PR, build it (maturin + editable Python), bring up etcd/NATS, run the end-to-end aggregated server via the repo's examples/backends/sglang/launch/agg.sh, drive load with uvx aiperf, verify the change empirically, then post a scoped evidence-backed GitHub review. Use when asked to test/try/review a Dynamo PR (e.g. "test ai-dynamo/dynamo#10254", "review this dynamo PR").
First-pass workflow for GitHub PR comments and review threads: pull feedback into a simple actionable markdown table before deciding what to fix. Use before github:gh-address-comments when the user asks to review, triage, address, fix, summarize, classify, ledger, or selectively handle PR comments/review feedback.
Check out an SGLang PR in a throwaway worktree, build it in a fresh venv, run it with sglang.launch_server, drive load with uvx aiperf, verify the change empirically, then post a scoped evidence-backed GitHub review. Use when asked to test/try/review an sglang PR (e.g. "test sgl-project/sglang#12345", "review this sglang PR").
Generate a bi-weekly/monthly engineering status update ("T5T") for a date range by mining the ~/memory work-vault and cross-referencing GitHub PR activity via gh. First emit a full evidence-backed mega dump of active work, then a separately labeled recommended T5T for approval. Use when asked to "write my T5T", "status update", "what did I do from X to Y", "biweekly update", "T5T mega dump", or "T5T for approval".
Create or update GitHub pull request descriptions without deleting existing content or adding long narrative slop. Use when the user asks to write, refresh, clean up, standardize, or update a PR body/description for a current branch or GitHub PR.
MANUAL-ONLY. Use only when the user explicitly invokes `mh-draw-the-owl` or asks to use the draw-the-owl workflow. Never auto-invoke it based on feature or diff size. Explore a feature end to end, then decompose oversized work into atomic, incremental, reviewable tasks.
Create a self-contained local HTML walkthrough of a pull request, branch, commit, or diff. Use when the user asks for a visual recap, HTML report, implementation walkthrough, architecture explainer, or an HTML document showing how a code change works. Ground every claim in the actual diff, code, tests, benchmark artifacts, and review evidence. Do not trigger for an ordinary PR review unless the user also wants the visual HTML artifact.