At A Glance

The bet: MiniMax doesn't get better from persona text. It gets better from cleaner context, smaller proving slices, better tool routing, honest verification — and the same judgment habits frontier agents use: fix the broken invariant, not the symptom; never game a test; update the plan after every tool result. Every rule here optimizes for that.

Quick Start

For Cursor

git clone https://github.com/madebyaris/advance-minimax-m3-cursor-rules.git
cp -r advance-minimax-m3-cursor-rules/.cursor your-project/.cursor

That's it. Two rules are always on:

• .cursor/rules/minimax-m3-core.mdc — reasoning protocol, execution behavior, code discipline, M3 long-context discipline, M3 multimodal input discipline
• .cursor/rules/minimax-m3-status-verification.mdc — status & proof contract (multimodal-grounded visual proof, red → green for bug fixes)

Everything else is requestable and narrower by design — it loads when the task or file globs call for it. The two fable5-* craft rules load for non-trivial coding and reasoning work; the rest attach by runtime or domain.

The official docs recommend Anthropic-compatible access for MiniMax text models, and also support OpenAI-compatible access paths. See MiniMax text generation docs · MiniMax API overview.

For Other IDEs and CLIs

Copy docs/AGENTS.md into the target repo root as AGENTS.md. It lives under docs/ here on purpose, so Cursor does not auto-activate it while you edit these rules.

Repository Layout

.cursor/
├── rules/                         # 20 rules (2 always-on + 18 requestable)
│   ├── minimax-m3-core.mdc                  ★ always-on · execution spine + reasoning protocol + M3 disciplines
│   ├── minimax-m3-status-verification.mdc   ★ always-on · proof contract (+ multimodal-grounded, red → green)
│   ├── fable5-coding-craft.mdc              requestable · frontier coding judgment distillation
│   ├── fable5-reasoning.mdc                 requestable · frontier thinking protocols
│   └── …                                    requestable: runtime + domain
├── agents/                        # subagents (/debugger, /verifier)
│   ├── debugger.md                          root-cause analysis: hypothesis ledger, bisection, fix-at-the-owner
│   └── verifier.md                          adversarial validation: claim-gaming hunt, proof execution
└── skills/                        # 7 deep, structured skill packs
    ├── anti-slop-design/
    ├── 3d-web-experiences/
    ├── deep-research/
    ├── incident-triage-harness/
    ├── minimax-multimodal-toolkit/
    ├── minimax-m3-long-context/             # new · 1M-context retention/compression
    └── minimax-m3-multimodal-input/         # new · native image/video input workflow
docs/
└── AGENTS.md                      # portable agent contract (non-Cursor)
examples/
└── agent-teams-product-prototype.md

Why This Repo Exists

This repo makes MiniMax M3 feel strong exactly where the M3 release puts its emphasis:

• 1M-token MSA context — and the discipline to use it without bloating
• native multimodal input (image, video) — and the discipline to ground visual claims in the actual file
• higher agentic and coding benchmarks — leveraged through role separation and explicit verification
• frontier coding judgment — the fable5-* craft rules distill the habits behind SWE-Bench-class scores (root-cause method, test integrity, interleaved thinking) into a form open models can follow
• agent harnesses and multi-agent collaboration, including /best-of-n as a first-class team pattern
• long skill packs and detailed tool contracts that load only when relevant
• dynamic tool discovery in changing environments (Cursor 3.7's evolving MCP + plugin surface)

The goal is not to make MiniMax imitate another provider's tone. It is to transfer the judgment — where to change code, how to prove a fix, when to switch strategy — while M3 keeps its own voice. A durable execution spine that complements its official positioning around real-world engineering, complex skills, agent workflows, long context, and multimodal grounding.

The Solver Loop

The single most important behavior this repo transfers into M3:

1. Define the outcome in operational terms.
2. Inspect the repo and runtime before deciding.
3. Find the spine: entry points, data flow, state, persistence, user-visible behavior.
4. Build the smallest vertical slice that proves the feature works.
5. Verify at the surface where the user experiences the change.
   - For visual claims: re-read the actual post-change frame (multimodal-grounded).
6. Expand scope only after the core slice works.

For app-building, that means: don't start with a pile of components — resolve key flows first, prove one end-to-end slice early, then add polish.

Example — for "build a task app", prioritize create → list → complete → persist → reload. Delay filters, collaboration, settings, and animations until the core path works.

Execution Guarantees

A few behaviors the repo treats as non-negotiable:

• New packages, frameworks, and toolchains are checked against current authoritative sources before they are recommended or installed.
• Scaffolding uses the framework's official CLI / create / init path when one exists.
• Scaffold output is inspected before continuing.
• Runnable work is not "done" until there is runnable proof, not just static confidence.
• Bug fixes are proven red → green: the reproduction fails before the change and passes after. A check that was never red proves nothing.
• Tests are never weakened, skipped, or special-cased to reach green — the test is the spec; if the spec looks wrong, that goes to the user.
• Fixes land at the root cause (the broken invariant), not at the symptom site; shipped workarounds are labeled as workarounds.
• Stubs, mocks, and hardcoded placeholders are declared in the closeout — never presented as finished behavior.
• Visual work is not "done" until the post-change frame is re-read (multimodal-grounded).
• If a required check fails or is skipped, the agent reports blocked or implemented but unverified — never a false completion.
• Browser or user-surface verification is required for UI and interaction claims.
• Tool-based promises wait until the runtime path is confirmed.
• 1M-token context does not free the agent from compressing; it raises the cost of failing to compress.

Rule Architecture

The system is layered: a tiny always-on core, craft rules that carry frontier judgment, runtime rules that load on demand, and domain rules that attach via file globs. Depth lives in skills.

★ Always-On Core

Craft Rules (Fable 5 Distillation)

Frontier-agent judgment distilled into requestable rules — the habits behind SWE-Bench-class scores, made transferable to M3 and any open model:

Runtime Rules

Domain Rules

Requestable rules for cross-cutting domains — not per-language cookbooks. Language-specific idioms come from reading the repo, official docs, and the always-on Code Discipline section.

Skills

Skills keep deep, domain-specific procedures out of the always-on core, then deliver large structured guidance through progressive disclosure (SKILL.md + optional reference.md).

Load a skill when the task has a repeatable workflow too detailed for the core, needs examples or category heuristics, or benefits from progressive disclosure. M3's 1M context still rewards "load the on-point skill, do not preload the catalog."

M3 Runtime Modes

MiniMax M3 (released 2026-06-01) is the target model for this repo. It ships a 1M-token MSA context window and native multimodal input (text, image, video). The repo is tuned for M3 first; it stays correct on third-party models such as composer-2.5, GPT, or Claude — the M3-specific sections (long-context discipline, multimodal input discipline) become inert and the always-on core continues to apply.

When working in a model that is not M3, do not promise multimodal or 1M-context behavior. The model-selection guidance in model-compatibility.mdc is the source of truth for which capabilities the active model actually exposes.

M3 + Cursor 3.7 Surface

A quick reference for the new surface — when to use each.

Tool names and command names can drift across Cursor builds. The decision still stands (use an isolated worktree for risky work; await long-running jobs; prefer structured MCP outputs); if a specific identifier is not exposed in your build, fall back to the next best exposed path.

Where M3 Feels Different

Three areas separate M3 from a generic coding model — and the optional rules / skills deepen each without bloating the core:

• 1M-token MSA + long-context discipline — explicit retention, compression, and skill-handoff rules, plus a dedicated minimax-m3-long-context skill.
• Native multimodal input + multimodal-grounded verification — image and video inputs ground visual claims; a dedicated minimax-m3-multimodal-input skill teaches the workflow.
• Agent Teams on Cursor 3.7 — explicit roles, bounded handoffs (with environment + model fields), /best-of-n as a first-class team pattern, and Await for long-running branches.

Model Compatibility

The rules are designed to survive model changes:

• the core rule stays short and durable
• runtime-specific guidance lives in requestable rules
• tool advice is written around whatever the environment actually exposes
• version-sensitive claims are verified at runtime, not frozen into the rules

The always-on core does not depend on a specific model — it teaches tool-first, read-before-edit, scope-controlled behavior that holds across M3, Composer 2.5, GPT, Claude, and other strong coding models. The M3-specific sections (long-context discipline, multimodal input discipline) are inert on models that do not expose those capabilities; the agent must not promise them.

Design Principles

Example Patterns

Want concrete M3-native patterns instead of only rules? Start here:

• examples/agent-teams-product-prototype.md — a bounded planner / explorer / builder / verifier workflow with M3 + Cursor 3.7 handoff fields (environment, model) and /best-of-n + Await notes
• .cursor/skills/incident-triage-harness/SKILL.md — a large-skill example for incident-style debugging and mitigation, now with M3 visual-evidence handling
• .cursor/skills/incident-triage-harness/reference.md — companion reference showing progressive disclosure
• .cursor/skills/minimax-m3-long-context/SKILL.md — the 1M-context discipline skill
• .cursor/skills/minimax-m3-multimodal-input/SKILL.md — the visual-input workflow skill

AGENTS.md For Other IDEs and CLIs

docs/AGENTS.md is the portable, standalone version of M3 behavior for environments that use agent instruction files but don't support Cursor rules. It carries the core behavior directly instead of acting as a thin pointer.

It focuses on action-first execution, the reasoning protocol (intent-first, interleaved thinking, explicit hypotheses, end-to-end ownership), solver-loop thinking, scope control, read-before-edit discipline, root-cause-first code discipline with test integrity, proportional verification (including red → green for bug fixes), explicit status labels (including multimodal-grounded), M3 long-context discipline, M3 multimodal input discipline, current-source version discipline, CLI-first scaffolding, and concise communication.

To use it elsewhere: copy docs/AGENTS.md into the target repo root as AGENTS.md. If you run both AGENTS.md and .cursor/rules, keep them aligned rather than letting them drift into contradictory layers.

Contributing

See CONTRIBUTING.md for contribution rules, the skill frontmatter contract (including the optional model_assumptions field), and placement guidance across always-on rules, requestable rules, and skills.

References