MiniMax Open-Sources Its Coding Agent Playbook: 17 Skills for Reviews, Context, and Long Sessions

On October 28, MiniMax published a repository called mcode-stack on GitHub. It contains no MiniMax Code source code. What it holds is the working method the MiniMax Code team actually uses every day: 17 SKILL.md skills and 5 checklists, aimed at the places where agent work most often goes wrong — when to split work into subagents, where context money goes, how long sessions stay sharp, how long commands should wait, and how code review avoids being led astray by the author. The repository was created on October 28 under the MIT license, and by the morning of October 29 it had already gathered 360 stars. This is not another prompt collection. It is a coding-agent team publishing its internal playbook, and the interesting question is what an ordinary developer can copy from it directly.

First, what this repository is and is not. It is not MiniMax Code itself — that is a separate MIT-licensed terminal coding agent, and none of its source code lives here. It is also not a pile of generic prompts. The repository says so plainly: this is not a prompt collection or a list of best practices, but what people on the team actually use every day — how to keep AI-written code at a high bar, how to decide whether a task should go to a subagent, how long to wait on a long command, how to keep long sessions from going dull, and what goes into context on every turn. Each item is a SKILL.md skill or checklist that installs straight into an agent and runs, rather than an article you read and forget.

What is inside

The repository has two stacks. The main one, ronny, comes from Ronny, MiniMax Code's R&D lead, and is the first and most complete set, with 15 skills. The other, jiachen, adds 2 more, for 17 in total, plus 5 checklists and 5 companion essays in the MCode Engineering Notes column. The pairing is the point worth copying: the essay explains the idea, the skill makes it runnable. That turns advice into a check an agent can actually execute.

Ronny's 15 skills are grouped by moment in the working day. Plan and split has three: subagent-split-check, which decides whether work goes to a subagent or stays in the main loop; engineering-small-prs, which splits large features, refactors, and migrations into small reviewable pull requests; and engineering-change-descriptions, which writes PR and commit descriptions that say what changed and why. Context and tools has two: tool-budget-audit, which measures what tools cost in context; and context-tax-audit, which looks at what gets injected into every request and what it does to the prompt cache. Long sessions and commands has three: long-session-check, covering whether to drop, summarize, or write to file, whether to compact or start fresh, and how memory is scoped; handoff-doc, a hand-off document so a new session can pick up the work; and long-command-check, a ten-point audit of long shell commands and background tasks. Review has four: independent-review, engineering-code-review, engineering-review-comments, and engineering-review-feedback. Experiments and hotfixes has three: harness-experiment, trajectory-review, and engineering-emergency-changes.

A few of these deserve a closer look. independent-review gives the reviewer exactly three inputs: the diff, the requirement, and test results, and deliberately withholds the author's conversation. The reasoning is direct: a reviewer who inherits the author's context repeats the author's blind spots. That runs against the usual habit of reading the author's explanation first, but for AI-generated code it makes particular sense, because the author — human or agent — is most likely to glide past the premises it already believes.

subagent-split-check sets a hard rule for splitting work: split only when context is the measured problem. Splitting by team, or by question type, does not count as a valid reason. That is a useful check on the current fashion for spinning up parallel agents: parallelism is not free. Every extra agent adds a context bill and coordination cost, and without measurement, you cannot tell whether you bought speed or just more overhead.

tool-budget-audit splits tool cost into two accounts: tool definitions, which tell the model what tools exist, and tool results, which are what the tools return. Tool search mainly cuts the first; programmatic tool calling mainly cuts the second. Many people tune agent cost while watching only one account, while the other quietly leaks. context-tax-audit covers the other half: everything automatically injected into each turn — system prompts, skill descriptions, memory, tool definitions — charges a tax, and affects prompt cache hits. If you do not know where the tax is paid, you cannot talk seriously about saving tokens.

long-command-check's ten items address familiar failure modes: if a command moves to the background, does the process re-run? Do unread results survive compaction? These are the reasons long jobs get lost or run twice. harness-experiment enforces one change per experiment, tracking flipped tasks, requests per task, tokens, cache hit rate, and wall-clock time. Without that discipline, "the new model works better" is often just luck wearing a lab coat.

One licensing detail to note: the six engineering-* skills are adapted from Google Engineering Practices, and that adapted material stays under CC-BY 3.0 rather than MIT. If you quote or adapt them, mind the difference. Jiachen's two skills point elsewhere: lifting-loops finds the loops where you keep acting as a manual step for your agents and lifts you out of them, while making-content turns notes and material into Xiaohongshu image posts and short vertical videos. The second has little to do with coding, so it is worth separating the stack's coding content from its content-creation content when you borrow from it.

Why an agent vendor would publish its own playbook

On the surface, MiniMax is giving something away. Underneath, it is drawing a line. Over recent months, agent skills in the SKILL.md format have become contested ground: Anthropic donated Agent Skills and related projects to a Linux Foundation organization on October 22, and skill packs of all kinds are circulating. Publishing its own internal usage at this moment is a bid for template status — not for any single skill being well written, but for "our way of working" becoming the thing other people copy by default. The format is open, the content is theirs, and if the ecosystem follows their template, their agent becomes easier to adopt.

For developers, the more practical meaning is different: this collection answers "how do you manage an agent that works on its own" rather than "how do you write prompts." As models get stronger, the bottleneck moves away from "can it write this" toward "who checks it, what did the context cost, what happens when a long task drops, and how trustworthy is a single change." Almost every skill in mcode-stack targets that second layer. That is also what separates it from many skill packs on the market: those teach you how to get an agent to do more, while this one teaches you how to get it to cause less trouble.

It is also worth noting that the starting point is genuinely internal use, not writing written for publication. The organization shows it: each skill pairs with an engineering note that explains why, and the contribution rules state that for now only collaborators can open pull requests directly, with everyone else asked to discuss in an issue first. That reads as a living handbook still evolving, not a finished standard. Useful to borrow from, premature to memorize as doctrine.

For vibe coding developers: start with four

If you are one person plus one agent on a project, do not install all 17. Start with four, in this order.

First, install independent-review and actually use it on AI changes. After the agent writes code and runs tests, open a clean review view with only the diff, the original requirement, and the test results — no prior conversation — and have it write severity-labeled review comments. You will find problems in that clean view that looked fine in the working session. Once that runs smoothly, add the engineering-review-comments habit: comments carry a severity label and explain their reasoning, rather than just saying "this is bad."

Second, install subagent-split-check as a cure for parallel-agent enthusiasm. Before splitting, make it answer one question: is context already the measured bottleneck? If not, do not split. Many solo projects do not suffer from too few hands; they suffer from a main loop stuffed with too much. Run tool-budget-audit first, see how much tool definitions and tool results each cost, and then decide whether to trim tools, add tool search, or switch to programmatic calling.

Third, install long-command-check and long-session-check to govern long jobs. For any command or background task lasting more than a few minutes, run the ten-point check: will it re-run, will results survive compaction, how do you resume if it breaks. When a long session starts going dull, do not keep pushing in the same conversation: summarize, write to file, or restart, and leave a handoff-doc so the new session can pick up. That is cheaper than correcting a dulled session over and over.

Fourth, install harness-experiment to discipline your own tuning. Every time you want to change a model, a skill, or a workflow, change one variable, repeat the runs, and record which tasks flipped, plus tokens and time. Without that record, your feeling that "the new version is better" is not evidence — luck and real improvement are indistinguishable.

Installation itself is simple, and the README gives three paths. The easiest is to install a whole stack in Claude Code with one marketplace command for ronny or jiachen; Codex has a matching marketplace command. To take a single skill, copy its folder into ~/.agents/skills/, which MiniMax Code, Claude Code, and Codex all read. Adding marketplaces in MiniMax Code desktop is still rolling out gradually, so if your version lacks that entry, use the folder copy. After installing, open a new session and check /skills to confirm the skill actually loaded before relying on it — installed but not loaded is the same as not installed.

Risks and open questions

A few cold facts first. The repository went public on October 28 with only 10 commits, and its star count was still moving fast the next morning. Treat anything you copy as a handbook that will change, and check back for updates, rather than installing once and treating it as settled.

Second, no evaluation data comes with it. The README gives no numbers for reduced rework or saved tokens after adopting these skills, and third-party coverage notes the same gap. So this is an experience playbook, not a proven methodology. Your own project is the evaluation: use the harness-experiment discipline, measure on your own tasks, and then decide what to keep and what to drop.

Third, not every skill fits a solo project. The engineering-* group comes from large-company engineering practice — PR splitting, review process, emergency change discipline for multi-person teams. Copying the full set into a side project will slow you down. The sensible split is to take the review and context skills wholesale, and take the process-discipline skills only as needed, rather than adding process to look like a big company.

Fourth, the skill format itself is still evolving. SKILL.md is now a common format supported by several agents, but loading, triggering, and permission handling differ between agents. A skill that runs smoothly in MiniMax Code may trigger at a different moment, or not at all, in another agent. When you switch agents, do not assume skill behavior moves with you; verify it again.

The judgment, in one line: mcode-stack's value is not the number 17, but the fact that it turns "how do you manage an agent" from folklore into checklists. Vibe coding today does not lack ways to make an agent write more lines; it lacks answers for who checks the result, where the context money goes, and how long jobs stay on track. Those unsolved problems mean faster code also means faster rework and faster bills. This open playbook does not give a standard answer, but it gives 17 ready-made checklists — and starting with the review and context ones is the cheapest place to begin.