MCode Stack 是什么：MiniMax Code 团队开源的工作流 Skill
MiniMax 在 GitHub 开源了 MCode Stack：MiniMax Code 团队自己每天在用的工作流和 Skill，一个技能一个 SKILL.md，可以装进 MiniMax Code，也能装进 Claude Code 和 Codex。仓库 2026-10-28 创建，到 10-29 有 366 星。这个仓库里没有 MiniMax Code 的源码（源码在 MiniMax-AI/minimax-code），它装的是团队在 Agent 外面那层工程习惯：什么时候拆子 Agent、长命令等多久、长会话怎么不变钝、审查交给谁。下面按仓库 README 和各个 SKILL.md（2026-10-29 北京时间查阅）整理清单、装法和最值得先拿的几个。
里面有什么：五组 15 个，按「什么时候用」排
| 时刻 | Skill | 干什么 |
|---|---|---|
| 规划拆分 | subagent-split-check | 这活该派子 Agent 还是留在主循环 |
engineering-small-prs | 大功能、重构、迁移拆成小 PR | |
engineering-change-descriptions | PR / commit 说明写清改了什么、为什么 | |
| 上下文与工具 | tool-budget-audit | 量工具占多少上下文，再决定删减、工具搜索还是程序化调用 |
context-tax-audit | 每轮请求都被注入了什么，对 prompt cache 有什么影响 | |
| 长会话与长命令 | long-session-check | 丢弃、总结还是写进文件；压缩还是开新会话 |
handoff-doc | 写交接文档，让新会话接着干 | |
long-command-check | 长 shell 命令和后台任务的十项审计 | |
| 审查 | independent-review | 干净上下文审 diff：只给 diff、需求和测试结果 |
engineering-code-review | 按设计、功能、复杂度、测试审代码健康度 | |
engineering-review-comments | 写带严重程度标签、讲清理由的审查意见 | |
engineering-review-feedback | 作者一方怎么处理审查意见 | |
| 实验与热修 | harness-experiment | 小评测，一次只改一处，重复跑，看翻转的任务 |
trajectory-review | 看 Agent 怎么得到结果，不只看过没过 | |
engineering-emergency-changes | 判断热修是不是真紧急，怎么走加急审查 |
stacks/jiachen 另加两个：lifting-loops 找出你总在给 Agent 当「人工一步」的环节并把你撤出来，making-content 把笔记素材做成小红书图文和竖版短视频。仓库还留了 stacks/<name>/ 的位置和模板，团队成员和社区可以各加一套。
怎么装：三种 Agent 各一条路
Claude Code，shell 里一条命令装整组：
claude plugin install ronny --marketplace MiniMax-AI/mcode-stack旧版本先加市场再装：会话里依次跑 /plugin marketplace add MiniMax-AI/mcode-stack 和 /plugin install ronny@mcode-stack。把 ronny 换成 jiachen 就是另一组。
Codex：
codex plugin marketplace add MiniMax-AI/mcode-stack
codex plugin add ronny@mcode-stack只要一个 Skill，所有项目通用：
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/MiniMax Code 和 Codex 都扫 ~/.agents/skills/。MiniMax Code 里新开会话敲 /skills 能看到，用 /long-command-check 调用，或者让 Agent 按描述自己加载。项目级可以放 .minimax/skills/、.claude/skills/ 或 .agents/skills/；用户级除了 ~/.agents/skills/，也会读 ~/.claude/skills/ 和 ~/.codex/skills/。克隆下来的仓库里还有 scripts/install.sh，PATH 上有 claude 或 codex 就走插件安装，都没有就把文件复制进 ~/.agents/skills/。
先拿哪几个：和每天的坑对得上的
subagent-split-check：拆之前先问一句
它的立场很明确：子 Agent 是管理上下文的工具，不是分地盘的工具，默认一个主循环加按需加载的 Skill。只有三种情况才考虑拆：评测上测得出来的退化（不是感觉）、可以并行且用完即扔的活、工具或指令打架。然后问那句决定性的话：后面还要原始中间输出，还是只要一个结论？只要结论的才适合派出去。拆之前还要先试更便宜的办法：工具太多就合并、挪到工具搜索后面；提示太大就把流程变成 Skill；怕丢状态就写进进度文档。这和站内 什么时候把子 Agent 并回主循环 说的是同一件事，这里给成了能逐条过的检查表。
long-session-check：上下文是工作台，不是仓库
模式 A 管你手上这个会话：把上下文里的东西分三堆。能重新拿到的直接丢（大文件、测试日志、搜索结果、放弃的尝试）；只属于本次的总结（进度、下一步、未解的 bug）；丢了会疼的写进文件（决策和理由、待办、验收标准）。然后选下一步：同一任务只是历史长了就压缩并说明保留什么；换任务开新会话；压了几次开始跑偏、重复问已经答过的问题，就写交接文档重开；走错路用回退，别让错误尝试进摘要。模式 B 是 12 项清单，用来审查一个 Agent 自己的长会话设计。
long-command-check：等一条命令也有隐性成本
前台阻塞等命令时没有新请求，等的时间超过模型服务的 prompt cache 有效期，下一次请求就得重新处理整段前缀：首 token 变慢、费用变高。这个 Skill 是写 Agent 的人用的十项审计：前台最长等多久、转后台是不是同一个进程、超时会不会被重置、完成靠通知还是轮询、通知追加在末尾还是改了已缓存的前缀、压缩后「任务已完成但结果没读」能不能留住，等等。每一项都要求附证据，看不出就写「unknown」，不许猜。
independent-review：审查员只拿三样东西
写代码的会话里塞满了自己的思路，让它自己审，容易替自己圆。这个 Skill 让审查在干净上下文里做，只给 diff、需求、测试结果，结论按固定表格交回：问题、位置、原因、严重程度（blocking / should-fix / nit）。修之前先核实每条意见是不是真的。
这套东西的价值在「什么时候停下来检查」的习惯，写成了 Agent 能逐条执行的格式。
适合谁、注意什么
- 天天用编程 Agent 的人：从
subagent-split-check、long-session-check、independent-review拿起，单个复制进去就能用。 - 自己写 Agent 或 harness 的人：
long-command-check、tool-budget-audit、long-session-check的模式 B、harness-experiment是审计清单，要读你 Agent 的代码逐项回答。 - 许可证：仓库 MIT；
engineering-*改编自 Google Engineering Practices，改编内容沿用 CC-BY 3.0，作者自己补充的部分是 MIT，每个SKILL.md里都写了来源。 - 它会变：README 写明这些做法会随实验继续改，第 06 篇笔记还在路上。装插件的方式方便以后跟着更新。
Skill 本身怎么写、放在哪，见站内 写你的第一个 Agent Skill。
最后
先把 long-session-check 复制进 ~/.agents/skills/，下次会话变钝的时候让 Agent 跑一遍，看它把上下文分成的三堆和你想的是否一样。
