mcode-stack is a public GitHub repository from MiniMax-AI that publishes "the workflows and skills the MiniMax Code team uses to build MiniMax Code." The repo appeared on GitHub's trending list for week 44 of 2026 as a brand-new project: when we read it on October 28 it had one star, three commits and no forks, so this is an early look, not a verdict on adoption.
What makes it worth a post anyway is the content. The README says plainly that it is "not a prompt collection or a list of 'best practices'." Each item is a SKILL.md that an agent can run as an audit: read your code or setup, answer a numbered list of questions with evidence, and return a verdict. It comes from the lab behind MiniMax Code, the open-source coding CLI and the M3.1 Flash open weights we covered earlier this month.
TL;DR: what readers ask first #
| Question | Answer |
|---|---|
| What is it? | 15 skills and checklists in one stack, with room for more stacks from the team |
| Who wrote it? | MiniMax-AI; the first stack belongs to Ronny, the MiniMax Code R&D lead |
| License | MIT; six engineering skills adapted from Google Engineering Practices under CC-BY 3.0 |
| Does it ship MiniMax Code? | No, the code lives in a separate repo |
| Does it work in Claude Code or Codex? | The SKILL.md format is shared, so many should; the README says so, and we have not tested each one |
| What does it cost? | Nothing to install; the skills just make your agent spend tokens running the audits |
| Biggest caveat | One star, three commits: young, and some referenced articles are still marked upcoming |
What is inside the 15 skills #
The repo is organized by when in a working day you would reach for each skill. The table below is the README's own grouping.
| When | Skill | What it does |
|---|---|---|
| Plan and split | subagent-split-check |
Decide whether work goes to a subagent or stays in the main loop |
| Plan and split | engineering-small-prs |
Split a large change into small, reviewable PRs |
| Plan and split | engineering-change-descriptions |
Write PR and commit descriptions |
| Context and tools | tool-budget-audit |
Measure what tools cost in context; trim, use tool search or programmatic tool calls |
| Context and tools | context-tax-audit |
Inventory what each request injects and how it affects the prompt cache |
| Long sessions and commands | long-session-check |
Decide what to drop, summarize or write to a file; compact or restart |
| Long sessions and commands | handoff-doc |
Write a hand-off document so a fresh session can continue |
| Long sessions and commands | long-command-check |
Ten-point audit of how an agent runs long shell commands |
| Review | independent-review |
Review a diff from a clean context |
| Review | engineering-code-review |
Review code health: design, complexity, tests, approval risk |
| Review | engineering-review-comments |
Write severity-labeled review comments |
| Review | engineering-review-feedback |
Handle reviewer comments as the author |
| Experiments and hotfixes | harness-experiment |
Run small evals, one change at a time, with repeated runs |
| Experiments and hotfixes | trajectory-review |
Examine how the agent reached a result, not only whether it passed |
| Experiments and hotfixes | engineering-emergency-changes |
Judge whether a hotfix is a real emergency and run expedited review |
Three kinds of item appear in a stack. A skill is a directory with a SKILL.md, invoked as a slash command or loaded automatically from its description. A checklist is a skill the agent walks item by item, and a plain-text copy sits in a checklists/ folder. A workflow is a WORKFLOW.md describing how a person uses MiniMax Code day to day. If those terms are new, our agent skills guide explains the format, and CLAUDE.md vs SKILL.md vs MCP shows where skills sit next to other configuration.
The skill that argues against subagents #
The most interesting file is subagent-split-check, because it pushes back on a popular habit. Its opening line says subagents are "a tool for managing context, not for dividing up territory," and it tells the agent to default to one main loop with skills loaded on demand.
It allows a split only if one of three conditions is clearly met. First, measured degradation: the single loop gets worse because its context grows, and "measured" means eval results, not a feeling. Second, parallel and disposable work, such as independent research threads that each need a clean context. Third, a tool or instruction conflict, where the main agent keeps picking the wrong tool. Then it asks one deciding question for the step: will you need the raw intermediate output later, or only a conclusion? Only conclusion-only work belongs in a subagent.
The skill also lists cheaper fixes to try before splitting. Merge tools by user intent and defer rarely used ones behind tool search. Turn procedures and rules into skills, live data into tools, and reference material into something loaded on demand. Write plans and decisions to a progress document so the session can be cleared safely. And if you already have many subagents, it lays out how to merge them back: build a small end-to-end eval first, merge the most tightly coupled ones, wrap the remainder as tools for the main agent, and keep a subagent only if the merged version is measurably worse.
That lines up with a trend we have tracked: Anthropic's guidance on folding subagents into the main agent loop, and the practical Claude Code subagent workflows most teams still run. Two labs landing on the same advice is a signal worth noting, though the MiniMax skill is guidance from one team's experience, not a published benchmark.
Context cost: tool budgets and the per-turn tax #
Two skills target the quiet cost of agent harnesses. tool-budget-audit measures what tool definitions cost in context and suggests trimming, tool search, or programmatic tool calls. context-tax-audit goes further: it asks you to capture one real request and list everything except the user's message, with where each part sits, how often it changes and its token count. Then it asks, for each part, "without this, the model would ..." and if you cannot finish the sentence, the part is a candidate for removal.
The cache rules in context-tax-audit are the useful part. Prompt caches match on prefix, so one changed byte invalidates everything after it. Content at the front that changes every request is the most expensive. Content written into history and never edited costs once and stays cacheable. Content attached only to the current request is never cached. The skill's rules of thumb: stable first, volatile last; keep the system prompt identical for the whole session and put the current time in the per-turn message; never rewrite reminders already in history.
If you only read one thing before tuning your own harness, pair this skill with our Claude Code token efficiency and prompt cache guide and the tool definition and schema design guide. The ideas are the same ones, packaged here as something an agent can run against itself.
Agent context window as a ribbon passing through a frame, illustrating the context tax audit in mcode-stack
Long commands: the ten-point audit #
long-command-check is written for people building agents, not just using them. The question: when the agent runs a shell command, should it wait? The skill names two costs. The visible one is that the user waits and nothing else happens. The hidden one is that the provider's prompt cache can expire, because a foreground command produces no new model requests, and if the wait outlasts the cache lifetime the next request re-processes the whole prefix, which is slower and costs more.
The audit has ten items, each answered with evidence such as a file and function, or a test you ran, with "unknown" allowed:
- Foreground limit, and whether it sits below the cache lifetime.
- No re-run: a command moved to background should be the same process, not killed and restarted.
- Timeout accounting: reading output must not reset the deadline.
- Result delivery: notification versus polling.
- Notification position: appended at the end, not editing a cached prefix.
- Anti-polling: capped blocking waits and a hint when repeated reads show no change.
- Output size: truncation or file-backed incremental reads, with incomplete output labeled.
- Cleanup when the user stops the agent, when a headless run exits, and on restart.
- After compaction: finished-but-unread results tracked outside the conversation history.
- Precondition: backgrounding disabled if the environment cannot read results.
It also gives four behavioral tests: start a dev server and do something else; run a command that takes minutes; start a background task and stop the agent; let a task finish and compact before reading the result. If your agent hangs on dev servers or long builds, this is the fastest way to find out why.
A runner on a long winding path with milestones, representing long-running command checks for coding agents
Review: a fresh pair of eyes by design #
independent-review rests on a simple claim: an agent that wrote code has made many small decisions and convinced itself of each, so a reviewer that inherits the conversation follows the same reasoning and misses the same things. The skill hands the reviewer exactly three inputs: the diff, the requirement (an issue, spec or acceptance criteria), and the real test output including failures and skips. It deliberately withholds the author's plan and self-assessment, and says that if the requirement is missing, stop and ask, since a review without one can only check style.
Findings must come back in a fixed shape: problem, location, reason and severity (blocking, should-fix or nit). Findings without a location or a reason count as opinions. Back in the main loop, the skill says not to apply findings wholesale: open the real code at the stated location and verify first. Pair this with the four engineering-* skills adapted from Google's engineering practices, which cover small PRs, change descriptions, review comments and handling feedback.
This is a close cousin of the multi-model review idea in tstack, which asks three models to review a change. The MiniMax approach is lighter: one clean-context reviewer, with the discipline in the inputs rather than in model diversity.
How to install it #
The README documents two routes.
One skill, all projects:
git clone https://github.com/MiniMax-AI/mcode-stack.git ~/mcode-stack
mkdir -p ~/.agents/skills
cp -R ~/mcode-stack/stacks/ronny/skills/long-command-check ~/.agents/skills/
Open a new session and type /skills to confirm it loads. For Claude Code, copy into ~/.claude/skills/ instead; for Codex, ~/.codex/skills/. For one project only, use .minimax/skills/, .claude/skills/ or .agents/skills/ inside the repo.
The whole stack as a MiniMax Code plugin: run mcode plugin marketplace list to find your local plugin directory, copy the entire stacks/ronny directory there, open /plugins in MiniMax Code and press Ctrl+R to refresh. The README notes that mcode plugin add installs only from the official catalog and does not accept GitHub URLs or local paths.
A sensible first run: ask your agent, "Run the long-command-check skill against our shell tool and give me the table with evidence." Read the evidence column before trusting any pass.
Honest limitations #
- Very young. One star, three commits, and the commit history is short enough that none of this has had outside testing. The README invites "I use this" issues, which means usage reports are not in yet.
- Referenced articles are uneven. The README links four MCode Engineering Notes (subagents, tool context, long sessions, bash waiting), marks the per-turn context tax note as upcoming, and its numbering skips 05 without comment.
- Audits, not guarantees. The skills tell an agent how to inspect a setup. The quality of the answer depends on the model running them, so check the evidence yourself.
- Compatibility is claimed, not tested here. The README says the SKILL.md format means many skills work in other agents. We did not run all 15 in Claude Code or Codex. Some, like
long-command-check, are about harness design and make most sense if you build or configure the harness. - Other stacks are still coming. Only Ronny's stack is complete. Other team members' stacks are listed as on the way, and a
community/folder accepts outside stacks that pass ascripts/check.mjscheck.
Why it matters for people building with agents #
Most public skill repos collect prompts: write better tests, follow this style. mcode-stack instead packages the maintenance questions a harness team asks itself. How many tools are we paying for in every request? Does a long build quietly expire our cache? Would a subagent really help here, or are we just splitting by org chart? Publishing those as runnable audits makes them portable, and it is a template for your own team: write the checks you keep repeating in code review as skills, with a fixed output format.
The contribution path reflects that. To add a stack, copy templates/stack-template/ to community/<your-id>/, write a WORKFLOW.md on how you use the agent, add at least one skill or checklist you actually use, run node scripts/check.mjs, and open a PR with the output and a short record of real usage. Requiring a record of real usage is a good filter against the prompt-collection problem the README warns about.
For the wider picture of how skills, rules and tools fit together, see steering Claude Code with CLAUDE.md, skills, hooks and rules and context engineering versus prompt engineering.
Related reading #
Official source: MiniMax-AI/mcode-stack on GitHub and its skill files.
Repository details, star counts and skill lists are accurate as of October 28, 2026 and may change as the repo grows.