Quick Answer: MiniMax Code skills are the
SKILL.mdworkflows and checklists the MiniMax Code team uses to build MiniMax Code itself. The open-source mcode-stack repository packages 15 skills in theronnystack and two more injiachen, covering subagent splitting, context budgeting, long commands, and code review. Install them as a Claude Code or Codex plugin, or copy a single skill folder into~/.agents/skills/.
Most AI coding advice is about prompts. The MiniMax Code team's repository takes a different angle: the habits around the agent. When should it stop and check its own work? Who reviews the output? Where does state live between sessions? The README is blunt that this is "not a prompt collection or a list of best practices." It's what the team uses every day, packaged as installable skills. Here's what's in it, how to install it, and where you should be skeptical.
What's inside the repository
The core is stacks/ronny, the stack belonging to the MiniMax Code R&D lead. It holds 15 skills grouped by moment in the workflow: planning, context and tools, long sessions and commands, review, and experiments and hotfixes. The stacks/jiachen stack adds two more. lifting-loops finds the places where you keep acting as a manual step for your agents, then removes you from them. making-content turns notes into Xiaohongshu image posts and short vertical videos.
Every stack contains three kinds of material, and the difference matters because you use them differently:
- Skill: a directory with a
SKILL.md. You invoke it with/<skill-name>or let the agent load it from its description. - Checklist: also a skill, where the agent walks your project item by item. A plain-text copy lives in
checklists/. - Workflow: a
WORKFLOW.mddescribing how one team member works with the agent every day. You read it; you don't run it.
Most people start with a skill and ignore the workflows. That's a mistake. The workflows explain why the skills exist, and they're the fastest way to tell whether a habit fits your team.
How to install MiniMax Code skills
There are three practical paths, depending on how much you want.
- Claude Code, the full stack. In a shell, run
claude plugin install ronny --marketplace MiniMax-AI/mcode-stack. Inside a session, use/plugin install ronny --marketplace MiniMax-AI/mcode-stack. Swapjiachenin for the other stack. - Codex. Add the marketplace with
codex plugin marketplace add MiniMax-AI/mcode-stack, then runcodex plugin add ronny@mcode-stack. - One skill only. Clone the repo, create
~/.agents/skills/, and copy a single folder. Start withlong-command-checkif you want the smallest possible test.
Here's the part the install docs bury: mcode plugin add installs only from the official catalog. It won't take a GitHub URL or a local path. For a whole stack inside MiniMax Code, you copy the stacks/ronny directory into your local plugin directory, then refresh /plugins with Ctrl+R. Marketplace support for MiniMax Code desktop is rolling out gradually, so your version may not have it yet. Check before you assume it's there.
Because every skill uses the common SKILL.md format, most of them also run in other agents that read skills. That portability is a real advantage if you switch tools.
Plan first: when work belongs in a subagent
The first skill most teams should read is subagent-split-check. It decides whether a task goes to a subagent or stays in the main loop. The repository's first Engineering Notes article carries a title that sums up the position: "More subagents isn't better: manage context first, then parallelize."
Here's the cause-and-effect chain. A subagent starts with a clean context. It doesn't know the three decisions you made in the last hour, the constraint your reviewer raised, or the file you already ruled out. So every handoff costs you a context rebuild, and if the subagent returns a confident result built on partial information, you pay again during review. Parallelism only helps when the pieces are independent and the handoff is cheap.
That's why the skill asks you to check the split before you make it. It also pairs with engineering-small-prs, which splits large features, refactors, and migrations into small reviewable PRs. Small PRs and clean subagent boundaries solve the same problem: they keep each unit of work small enough that its context fits in one head.
Here's where most teams get it wrong. They reach for subagents to save time and end up with three partial answers that conflict. Ask yourself one question before you split: could a stranger finish this piece using only the task description and the repo? If not, keep it in the main loop.
Context costs: tools and the prefix cache
Two skills address what you pay for on every turn. tool-budget-audit measures what your tools cost in context and offers three responses: trim the tool set, use tool search, or use programmatic tool calling. context-tax-audit looks at what gets injected into every request and what that does to the prompt cache.
The trade-off between the tool-budget options is worth a table:
| Approach | What it reduces | Main trade-off |
|---|---|---|
| Trim the tool set | Tool definitions loaded every turn | You lose capabilities the agent might have needed |
| Tool search | Upfront tool definitions; tools load on demand | The agent must find the right tool, and a bad search costs a turn |
| Programmatic tool calling | Round trips and intermediate results in context | Logic moves into code you must write, test, and maintain |
The third Engineering Notes article covers the prefix cache, and its title is blunt: "One small field can break the whole prefix cache." The mechanism is simple. Prompt caching reuses the work done on an exact prefix of your request. If a field near the top of your system prompt changes every turn, such as a timestamp, a session ID, or a regenerated file list, the cached prefix stops matching. Every request then pays the full cost of processing the context again.
Most people stop here, but the fix is usually small. Move the volatile field below the stable content, or stop injecting it on every turn. Then check the cache behavior on a real session rather than trusting that it works. The context-tax-audit skill walks you through exactly that inventory.
Long commands and long sessions
Long shell commands and long conversations fail in similar ways. The process hangs, the context fills up with logs, and nobody notices until the output is useless. Two skills target this directly.
long-command-check is a ten-point audit of long shell commands and background tasks. The companion article asks how long one bash command should wait, and it moves from foreground blocking to background tasks. The practical rule is that a foreground command that blocks the agent for a long time wastes the turn and risks losing its output. Move it to the background, write its output to a file, and check it at intervals. The audit makes you decide, for each command, what counts as done and what counts as stuck before you start it.
long-session-check handles the conversation itself. It asks whether to drop context, summarize it, or write it to a file, and whether to compact the session or start fresh. Compaction and memory are different tools. Compaction shrinks what's in the current window, which keeps the thread but can quietly lose detail. Memory stores facts outside the window, which survives a restart but needs scoping so stale facts don't leak into unrelated work.
That leads to handoff-doc, which writes a hand-off document so a new session can pick up the work. Here's the test I'd use: if a fresh session can resume the task from the document alone, without asking you a single question, the handoff is good. If it needs you to re-explain the goal, it isn't.
Review from a clean context
Review is where the team's opinions are sharpest. The independent-review skill reviews a diff from a clean context, using only three inputs: the diff, the requirement, and the test results. It deliberately leaves out the author's reasoning.
That's the counter-intuitive part. Most teams assume the reviewer should know as much as possible about the change. But a reviewer who has absorbed the author's story tends to review the story, asking whether the explanation is convincing, instead of reviewing the code. Removing that context forces the reviewer to check whether the diff satisfies the requirement and whether the tests prove it. The trade-off is real, though. A clean-context reviewer can miss a design decision that only makes sense with history, so you should include the design rationale in the requirement input rather than dropping it.
The rest of the review group draws on Google Engineering Practices. engineering-code-review evaluates code health across design, functionality, complexity, tests, and approval risk. engineering-review-comments teaches you to write severity-labeled comments that explain the reasoning, so the author knows what must change and what's a suggestion. engineering-review-feedback covers the other side: handling reviewer comments by fixing, clarifying, or resolving disagreements. The adapted material stays under CC-BY 3.0, as the repository's NOTICE.md explains.
Here's where it gets interesting. Severity labels sound bureaucratic until you've watched a team argue about whether a missing null check blocks a merge. A label turns that argument into a shared vocabulary in one line.
Limits, caveats, and what to take with a grain of salt
Nothing here is a universal truth, and the repository says so. It describes what one team does, and it states that "everything here will keep changing as we learn." Treat each skill as a hypothesis to test on your own project.
Three caveats matter most. First, the engineering-* skills are adapted from Google's practices, so check the license terms before you copy them into a closed codebase. Second, the skills are written for MiniMax Code's workflow, so some assumptions about tool names and command structure may not match your agent. Third, the repository doesn't include MiniMax Code's source. It only holds workflows and skills, and you'll need the separate minimax-code project to run them.
Contributions are limited for now. Pull requests come only from repository collaborators, so non-collaborators should open an issue first. Using a skill from the repo in your own agent? The maintainers ask you to file an I use this issue.
Frequently Asked Questions
What are MiniMax Code skills?
MiniMax Code skills are SKILL.md directories that package a team's day-to-day agent workflows as reusable instructions. The mcode-stack repository holds the ronny and jiachen stacks, with 17 skills in total. You invoke a skill with /<skill-name> or let the agent load it from its description.
How do I install MiniMax Code skills?
For Claude Code, run claude plugin install ronny --marketplace MiniMax-AI/mcode-stack in a shell. For a single skill, clone the repo and copy the skill folder into ~/.agents/skills/, then open a new session and type /skills to confirm it loads.
Why does a small change break the prefix cache?
Prompt caching reuses work on an exact prefix of your request. If a volatile field, such as a timestamp, sits near the top of the prompt and changes each turn, the cached prefix stops matching and every request is processed in full. Move volatile fields below stable content to keep the cache hitting.
When should I use a subagent instead of the main loop?
Use a subagent only when the piece of work is independent and can be described completely in a short handoff. The subagent-split-check skill asks whether a stranger could finish the task using only the description and the repo. If not, keep the work in the main loop, because the subagent starts without your context.
Can I use these skills with other AI agents?
Yes, mostly. The skills use the common SKILL.md format, so many work in other agents that support skills. Expect to adjust tool names and command syntax, since the workflows were written for MiniMax Code.
Pick one skill and run it on a real task this week. long-command-check is the easiest starting point: install it, run it on the next long command you launch, and note which of the ten points you skipped before. Share the result with someone wrestling with the same problem. Mastering MiniMax Code skills comes from testing them on your own project, not from reading about them.