anhminhnguyenhoang/mstack

Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', or non-trivial work where jumping to code would lock in the wrong shape.

Spawn N parallel candidates at the same task, pick a base, graft the strongest parts of the losers into it. Use for /arena, 'arena this', 'throw it in the arena', or when one attempt at a non-trivial artifact would lock in the wrong shape.

Guides users through mstack setup, /ateam-mode, and picking the skill, playbook, or principle for a task. Type /ateam-help with a question.

The ateam agent style for AMD GPU kernel and Jira ticket work, with concise replies, deliberate subagents, unslopped prose, simple code, and verified work. Use for /ateam-mode or requests to work in this style.

Use for "automate me", "create/update/refresh my -mode skill", "turn/capture my preferences or working style into a skill", or wanting agents to follow how the user works. Drafts or revises a personal -mode skill via create-skill + unslop, optionally pulling fresh evidence from recent transcripts.

Vet a perf measurement (limiter, tuning, limits, errors, repeatability, relevance, and whether the work happened) before you report or act on it. Use when you run a benchmark or report a speedup or regression you measured.

Find what a change could break somewhere else before it ships, beyond the diff, and prove the one fact it's safe because of by running real code instead of writing it up. Use for 'blast radius of X', 'what could this break', or reviewing a small diff you don't trust.

Translate the kernel and ROCm jargon in the last message into plain words for a reader who does not write GPU kernels. Use for /bro, 'say that in plain words', 'what is a VGPR, LDS, or MFMA', 'what does occupancy mean', 'I do not know these terms'.

Find the mistakes agents keep repeating in this repo and make each one impossible. Try architecture first, then types, then a lint whose error names the fix, then a test, and write docs last. Prove each check fails on a real past mistake. Repeat this each time the operator corrects you. Use for /correct.

Generate a repo-local verification skill for a GPU kernel library such as an aiter or FlyDSL checkout: one feature file per op family for the correctness gate, the frozen perf harness, and the ISA resource check, all driven on one locked GPU. Use for /create-verification-skill, 'make a verify skill for aiter or FlyDSL', 'map the op tests of this repo', or when a kernel library has no scripted way to prove correctness, perf, and resources.

Design an auditable playbook when no narrower one fits: a large migration, an ambitious multi-part change, or work a human reviews after stepping away. Scales rigor to the task, runs a hypothesis loop, and logs decisions. Use for /figure-it-out or 'figure it out'.

Use for "how does X work", code walkthroughs before changing something, and placement / ownership / layering questions ("where should this live", "which package owns this", "is this the right layer"). Explains subsystem architecture, runtime flow, onboarding mental models. Use why for motivation.

Use for "interrogate", "adversarial review", "multi-model review", "challenge this", "stress test this code", "find blind spots", or "tear this apart". Multiple LLM reviewers challenge changes from independent angles.

Catch the user up on everything in this chat since their last message, in plain words. Give each action item an executive summary with enough context to make the call. Use for /ketchup.

Periodic pass that keeps the verification skill of a kernel library current: detect new or renamed op tests, removed shapes, changed tolerances, new gfx942 or gfx950 gates, stale reference baselines, and harness drift, then re-prove each feature on one locked GPU and report drift per op family. Use for /maintain-verification-skill, 'audit the verify skill', 'did the op tests change', 'is the aiter or FlyDSL verify map stale'.

Spawn Comment Sicko, fix accepted findings, and offer encodings for claimed constraints.

Apply when two or more fixes that share one premise have failed the same gate. Take a census of which actors hold the imbalance before the next fix, then question the premise instead of writing another fix that assumes it.

Apply to any non-trivial work, not just bulk work: edits, migrations, analyses, checks. Build the tool that does it or proves it (codemod, script, generator, or a skill your subagents follow) instead of working by hand. The tool is the artifact a reviewer can rerun.

Apply before you time, report, or keep any kernel change. A perf number counts only after an allclose check and a NaN count pass on the same run.

Apply when you catch yourself writing the same instruction a second time, or notice a recurring correction. Encode the rule as a lint, metadata flag, runtime check, or script instead of more text.

Apply when facing a novel UI interaction or architectural decision with no precedent in the codebase. Build 2 or 3 competing prototypes and compare side by side before committing.

Apply before you trust, report, or act on a number you measured: a speedup, a regression, a throughput, a latency, or an eval result. Find what limits it, state a GPU kernel number as a percent of peak with the peak's source, and rule out that it measured something other than the work you think.

Apply when debugging. Trace each symptom to its root cause and fix it there; reproduce first, ask why until you reach it, resist nil-check guards that silence crashes.

Apply when context is filling up: large outputs, long files, repeated reads, fan-out planning. Route bulk to subagents; keep summaries in the main thread, not raw payloads.

Apply when introducing a new internal API while old callers still exist. Migrate callers and delete the old API in the same wave instead of preserving compatibility layers.

Apply when reviewing or shaping code that's hard to trace. Count layers between question and answer, and hidden state in the reader's head; collapse one-caller wrappers and shrink mutable scope.

Apply when writing stateful logic, or when code branches a lot or repeats a shape assumption across files.

Apply when tempted to ask 'should I do X?' on reversible work.

Apply during planned rewrites and migrations with explicit phase boundaries. Converge on the target architecture; don't preserve smooth intermediate states with throwaway compatibility code.

Apply when you change a compile hint, flag, attribute, or kernel structure and want credit for a result. A knob is real only if the ISA or IR changed.

Apply after completing a task, before declaring done. Verify against the real artifact (run the feature, read the actual value, inspect the diff), not a proxy, self-report, or 'it compiles.'

Apply when integrating a new requirement into an existing design, or before writing logic: choosing core types and data structures, sequencing scaffold-vs-feature work, asking what concurrent actors share.

Apply when concurrent actors might write to the same file, branch, key, or state object. Eliminate the sharing first; serialize structurally only when one shared writer is a real invariant.

Apply to multi-step work (sweeps, migrations, runs of similar edits) and to how you stack commits and PRs. Break work into small units that each end in a verifiable state, check each before the next, and order delivery so the sequence proves itself to a reviewer.

Apply when sequencing an addition, refactor, or rewrite, when tempted to add an abstraction, layer, or flag, or when sizing a diff. Remove dead code, redundant validators, and stub references first, make the smallest change, then build on the simpler base.

Apply when you write, change, or keep a test. Call the code as its users do and assert the exact result they see. Rewrite or delete a test that would pass if every imported function returned undefined.

Reconstruct your recent working context from your own chat history, live state, and the shared record (user reports, prior fixes, incidents), then hand back a tight current-state brief. Use for 'recall my work on X', 'catch me up', 'what have I been working on', 'where did I leave off', before starting or resuming work.

Spawn three parallel review subagents over the active transcript, list learnings, and route each to a concrete edit on an existing skill. Use when the user says reflect.

Configure mstack for this user and this machine. Part A sets the model per role and the reasoning budget. Part B detects the GPU hosts, containers, PR tool, Jira sites, and GPU lock, asks the user for each local resource (repos, skills, refs, tickets) and each optional module (kb, wavescope) instead of guessing names or locations, maps the knowledge base's folders to roles, and writes the machine-local env file every kernel skill reads. Use for /setup-mstack, /setup-mstack models, /setup-mstack env, "configure mstack", "mstack budget", or when a skill reports that ~/.cursor/mstack/env.md is missing or a fact in it is not set, or offers to add a resource.

Keep a reviewable decision trail for long-running or unattended work: a TSV log with one row per decision (what, why, evidence, result). Local by default; commit it when a reviewer needs the trail to trust the result. Use for /show-me-your-work, autonomous or multi-phase runs, or work a human reviews after stepping away.

Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.

Explain a GPU kernel or a kernel change so a person understands it: data flow from global memory to LDS to registers to MFMA to epilogue, tiling and wave mapping, pipeline waits, why the design is this way, and what the numbers mean. Runs the how and why skills. Use for 'teach me this kernel', 'explain this FlyDSL or aiter change', 'walk me through the tiling', 'why is this tile size or pipeline used'.

Layered technical-writing standard: Diátaxis structure, Google developer style sentences, STE instruction rules, Global English syntax. Use for /technical-writing or when writing or reviewing docs, RFCs, readmes, PR descriptions, or commit messages.

Load a Jira ticket into its ticket folder (<tickets>/<KEY>/) before any work. Writes ticket-raw.md, a brief of at most 150 words, and an acceptance predicate. Use for /ticket-init <KEY>, or when the user names a ticket key (PROJ-123) and no ticket folder exists yet. When the folder exists, it resumes from its STATUS.md and replies with a state brief.

Cut AI tells from any writing.

Run one command on one locked AMD GPU in the right container, and write a correctness-and-perf JSON artifact into the ticket folder. The command is an aiter op_test, a FlyDSL pytest target, or a bench harness, which may interleave A and B itself. Use for /verify-gpu-kernel, whenever a playbook says to verify, reproduce, or benchmark on the real surface for aiter, FlyDSL, or Triton kernels on MI300X or MI355X. Comparing two git revisions is the pr.validate skill function, not this skill.

Use for 'why does X work this way', 'why does this kernel use this tile size', 'why does this dispatch threshold exist', 'why was this perf guard added', design rationale, regressions, or postmortems. Discovers available MCPs and queries each evidence category (code history, source control and PRs, issue tracker, long-form docs, chat) in parallel, with an incident lens for defensive code, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.