The MiniMax Code Team's Coding-Agent Workflow Library

What the repository is, and what it is not

mcode-stack is an open library of coding-agent workflows published by the MiniMax Code team. It turns everyday engineering habits into installable SKILL.md files, checklists, and workflow guides covering review, context management, long-session handoffs, controlled experiments, and requirement tracking. These are not merely prompt templates. Each piece is written to be applied step by step inside a real project.

The repository does not contain the MiniMax Code application source. It also does not present a benchmark-proven method for improving every model. What it provides is an operating procedure and a way to test whether that procedure helps. Teams still need to evaluate a skill against the same model, tool set, repository state, and task set they use in production.

Three published stacks

The repository currently publishes three stacks containing 27 skills. All three can be installed as plugins, but they address different kinds of work.

Stack	Skills	Scope
ronny	19	Context, review, long-running work, experiments, and daily engineering practice for coding agents
jiachen	2	Removing repeated human-in-the-loop work and turning source material into finished content
req-tpm	6	Requirement management from intake through outcome review

ronny is the largest stack and reflects the working system of the MiniMax Code R&D lead. It covers task splitting, code review, small changes, long commands, subagent allocation, tool budgets, and trajectory analysis. The other stacks are not renamed copies. jiachen focuses on the relationship between a person and their agents, while req-tpm extends the workflow into product requirements and organizational state.

Independent review and evidence before claims

independent-review asks a reviewer to start from a clean context and inspect only the diff, the original requirement, test results, and necessary project documentation. The implementation session's reasoning is excluded. This separates the question of whether the code is sound from the question of whether the implementer can explain it. Assumptions formed during implementation should not silently become premises for review.

evidence-first-review handles the moment when an agent says a task is complete. It requires the reviewer to open the transcript and tool output before reading the final summary, then identify what each check proves, what it does not prove, and which defaults were chosen without an explicit decision. A passing test proves one behavior for one input. It does not prove that the caller supplies the right input or that runtime behavior is correct. For high-stakes work, the reviewer should also try to falsify the result before accepting it.

review-capacity-check treats review capacity as a real constraint. Starting more parallel agents does not automatically create more trustworthy output. If nobody has time to understand the diff, judge the tradeoffs, and own the consequences, more agents only create more pending review work. The check ties parallelism to the team's actual ability to stand behind each result.

Context budgets and prompt-cache placement

tool-budget-audit measures both tool definitions and tool results. Its recommended sequence is to remove unnecessary tools first, defer rarely used tools behind search second, and let the model write programs that call tools third. Each step should be measured independently because tool count, result size, and round trips all affect the cost and quality of a session.

context-tax-audit inventories everything injected into every request, including system instructions, environment details, directory structure, rules, and changing state. The repository calls out a concrete cache problem: putting the current time directly into the system prompt changes the shared prefix on every turn. A more stable arrangement is to place session-stable environment information first, write time updates into history as context that is never rewritten, and keep precision only as high as necessary. Each injected item can be evaluated by necessity, frequency, precision, position, and cache impact.

Long sessions, handoffs, and long commands

long-session-check addresses attention drift as a session grows. It asks which information can be dropped, which should be summarized, which must be written to a file, and which belongs in longer-term memory. Compaction is not just deletion. It is a rearrangement of state so that later work can still trace its objective, constraints, and completed steps.

handoff-doc turns that state into a document another session can consume. The new session receives the goal, current state, important decisions, failed attempts, remaining work, and verification method without relying on hidden memory from the previous session. This is useful near a context limit, across multiple days, or when work moves to another agent.

long-command-check applies a ten-point audit to commands and background tasks. It looks for main-loop blocking, unbounded waits, oversized output, invisible failures, concurrency conflicts, and missing completion checks after a process detaches from the terminal. The point is not to add ceremony to every command. It is to establish observability and a cleanup path before starting work that is slow or has side effects.

Treat harness changes as controlled experiments

harness-experiment frames any change to prompts, tools, skills, subagent layout, compaction, or other agent scaffolding as an experiment. Before changing anything, write a falsifiable hypothesis and prepare a small end-to-end evaluation set. Pin the model version, settings, tools, and repository state. Repeat the baseline to expose run-to-run noise.

The candidate changes exactly one variable. Baseline and candidate are then compared using more than an average score: per-task pass rates, tasks that flip in either direction, requests per task, input and output tokens, cache hit rate, and wall-clock time. A flat score with fewer requests can be a win. A higher average that breaks a must-not-fail rule is not. Every flipped task should be opened and traced to understand why it changed.

trajectory-review supplies that missing inspection step. It asks not only whether the final result passed, but how the agent reached it. Did it skip a required step, misread a tool result, repeat a failed action, take an unstable shortcut, or succeed because of an accidental condition? These questions are especially important when a change appears to improve one aggregate metric.

Convert repeated corrections into checks

taste-to-checks targets corrections that keep recurring. If a reviewer has to make the same point a second time, the team should consider turning that preference into a test, static check, hook, or CI step. This moves judgment from individual memory into a repeatable gate and reduces repeated negotiation between agents and reviewers.

The main stack also includes skills for small changes, change descriptions, review comments, responding to review feedback, and emergency changes. Portions of the engineering-practice material are adapted from Google Engineering Practices with attribution, while the repository notes that it is not affiliated with or endorsed by Google.

The six-stage requirement lifecycle

req-tpm asks the person raising a product or technical requirement to act as its technical program manager alongside their own agent. The lifecycle has six stages: intake, prioritization, design, tracking, shipping, and outcome review. The requirement body lives in a Feishu document, while status and flow live in Meegle.

1. Intake: decide whether the requirement is worth doing and fix the metric, baseline, target, measurement method, and observation window.
2. Prioritize: summarize cost, impact, and risk, then let the owner make the priority decision.
3. Design: record alternatives, the chosen decision, blast radius, and checkpoints.
4. Track: maintain progress, blockers, and next steps on a cadence, while surfacing stale items first.
5. Ship: check rollback, observability, definition of done, and status transitions.
6. Outcome: compare evidence with the expected outcome fixed at intake and close only when that outcome is supported.

This separates shipping from success. A requirement does not become successful simply because the work item is closed. If the expected outcome is not met, the workflow returns to design for another iteration. Comments, mentions, and status changes visible to other people must be shown to the requester before the agent executes them.

The important boundary is that req-tpm is explicitly labeled v0 and is optional. It has not yet been run against a real Meegle space. Some project-specific fields, roles, and states remain assumptions until they are verified, and the stack depends on the meegle and lark-cli tools. It is a structured starting point for requirement process experiments, not a fully validated turnkey product.

Installation, validation, and adoption

The repository documents installation through Claude Code, Codex, the MiniMax Code marketplace, and direct copying. A team can install a whole stack as a plugin or copy one skill directory into ~/.agents/skills/. The installation script prefers an available claude or codex command and otherwise falls back to copying the skill directories.

scripts/check.mjs validates skill front matter, manifest wiring, marketplace consistency, optional version bumps, and the official MiniMax Code validator. It is useful after changing a skill or adding a stack because it catches drift between directory structure and plugin declarations.

The practical adoption path is not to install all 27 skills at once. Start with one recurring problem, such as unfocused review, context growth, or poor handoffs. Record the current baseline, enable one skill, and inspect whether it changes actual behavior. If the team keeps the procedure, also decide where the evidence comes from, how failures are handled, and when the procedure should be removed. A skill makes a practice executable. It does not replace project goals, engineering judgment, or accountability.