Why This Repo Exists

This repo is designed to make MiniMax M2.7 feel strong in the places the official release emphasizes most:

• repo-scale and end-to-end engineering
• agent harnesses and multi-agent collaboration
• long skill packs and detailed tool contracts
• dynamic tool discovery in changing environments
• proportional verification with evidence-backed closeouts

The goal is not to make MiniMax merely imitate another provider's tone. The goal is to give M2.7 a durable execution spine that complements its official positioning around real-world engineering, complex skills, and agent workflows.

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 current environment actually exposes
• version-sensitive claims are meant to be verified at runtime, not frozen into the rules

This makes the repo useful for MiniMax first, while still compatible with other Cursor-supported models.

Why M2.7-Native

MiniMax positions M2.7 as strong at real-world software engineering, full project delivery, large skill adherence, and agent teams rather than only one-shot code generation MiniMax M2.7 release report MiniMax M2.7 model page.

That means this repo optimizes for:

• bounded repo exploration instead of reading everything
• smallest proving slices for large tasks
• explicit role and handoff discipline for multi-agent work
• strong skill contracts instead of vague long prompts
• truthful runtime and verification reporting

What Changed

This refactor removes most of the old prompt bloat:

• no more Opus-style identity anchoring in the core
• a separate always-on verification contract instead of burying proof rules in prose
• far less duplicated tool and verification doctrine
• no hardcoded month/year version examples in workflow rules
• no fake <think> or <thinking> scaffolding
• less "always run everything" language in domain-specific rules
• docs/AGENTS.md is now a real standalone agent contract for non-Cursor environments
• M2.7-specific docs now distinguish core execution rules from optional agent-team, skill, and tool-discovery depth

Execution Guarantees

The repo now tries to enforce a few non-negotiable behaviors:

• new packages, frameworks, and toolchains must be checked against current authoritative sources before they are recommended or installed
• scaffolding should use the framework's official CLI or official create or init path when one exists
• scaffold output must be inspected before continuing after generators or CLIs run
• runnable work is not done until there is runnable proof, not just static confidence
• if a required check fails or is skipped, the agent should report blocked or implemented but unverified instead of claiming completion
• browser or user-surface verification is required for UI and interaction claims
• tool-based promises should not be made until the current runtime path is confirmed

M2.7 Runtime Modes

The official API docs expose both MiniMax-M2.7 and MiniMax-M2.7-highspeed, each with a 204,800 token context window. The docs describe standard M2.7 at roughly 60 tps and M2.7-highspeed at roughly 100 tps, with the highspeed variant positioned as the same capability profile with lower latency MiniMax text generation docs MiniMax API overview.

Use that split like this:

Solver Loop

The main thing this repo now tries to transfer into MiniMax M2.7 is a repeatable solver loop:

1. Define the outcome in operational terms.
2. Inspect the repo and runtime before deciding.
3. Find the spine: entry points, data flow, state boundaries, persistence, and 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.
6. Expand scope only after the core slice is working.

For app-building, this means:

• do not start with a pile of components
• resolve key flows and acceptance first
• prove one end-to-end slice early
• add polish and secondary features afterward

The minimum proving loop for a new app should usually be:

1. install or setup succeeds
2. dev server or health check starts
3. production build succeeds
4. one primary happy-path flow works
5. promised integrations such as styling, routing, persistence, or auth are actually verified

Example:

• For "build a task app", prioritize create -> list -> complete -> persist -> reload
• Delay filters, collaboration, settings, and animations until the core path works

MoE Note

These rules do not assume you can directly control a model's internal MoE routing through persona text.

The controllable levers are:

• cleaner context
• better decomposition
• better tool routing
• better verification loops
• clearer definitions of done

If MiniMax performs better after a prompt rewrite, the likely reason is improved external problem structure, not magical direct access to hidden experts.

Quick Start

For Cursor

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

The always-on rules are:

• .cursor/rules/minimax-m2-core.mdc
• .cursor/rules/minimax-m2-status-verification.mdc

The rest of the rules are requestable and narrower by design.

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

For Other IDEs and CLIs

Copy docs/AGENTS.md into the target repo root as AGENTS.md, or use it as your agent instructions file in environments that support a portable agent contract.
It intentionally lives under docs/ in this repo so Cursor does not auto-activate it while you are editing these rules.

Rule Architecture

Always-On Core

Runtime Rules

Domain Rules

Language and platform rules now focus on domain-specific patterns rather than repeating the global workflow in every file.

Skills

The repo's .cursor/skills/ directory is part of the intended M2.7 workflow, not a side feature. Skills let you keep deeper, domain-specific procedures out of the always-on core while still giving the model large, structured guidance when the task warrants it.

Use skills when:

• the task has a repeatable workflow that is too detailed for the always-on core
• the task needs examples, references, or category-specific heuristics
• you want progressive disclosure through SKILL.md and optional companion files such as reference.md

Current local skills:

Design Principles

Keep The Core Small

Large always-on prompts waste context and often reduce execution quality. The core rule should contain only durable behavior with high leverage.

Prefer Capability Framing Over Persona Framing

Rules work better when they say:

• inspect first
• build the smallest proving slice
• verify before claiming success

They work worse when they spend lots of tokens on identity, status, or stylistic self-description.

Make Acceptance Explicit

Good rules do not stop at "verify somehow." They define the minimum proof for the kind of claim being made, especially for new app scaffolds and user-facing behavior.

Trust The Current Environment

Cursor's tool surface changes. The rules should teach behavior that survives those changes instead of freezing old tool names or wrappers.

Agent Teams, Skills, And Tool Discovery

These are the three biggest places where M2.7 feels different from a generic coding model:

• Agent Teams: use explicit roles, bounded handoffs, and clear escalation points instead of vague multi-agent optimism
• Skills: invest in long, high-signal skill contracts rather than stuffing rare workflows into the always-on prompt
• Tool Discovery: discover the live runtime surface, schemas, and MCP shape before promising capability

The optional rules in this repo are meant to deepen those areas without bloating the always-on core.

Example Patterns

If you want concrete M2.7-native patterns instead of only rules, start here:

• examples/agent-teams-product-prototype.md - a bounded planner/explorer/builder/verifier workflow for multi-agent product work
• .cursor/skills/incident-triage-harness/SKILL.md - a large-skill example for incident-style debugging and mitigation
• .cursor/skills/incident-triage-harness/reference.md - companion reference material showing progressive disclosure for a deeper skill

AGENTS.md For Other IDEs and CLIs

docs/AGENTS.md is the portable standalone version of MiniMax M2.7 behavior for environments that use agent instruction files but do not support Cursor rules.
It carries the core behavior directly instead of acting as a thin pointer file.

It is focused on:

• action-first execution
• solver-loop thinking
• scope control
• read-before-edit discipline
• proportional verification
• explicit status labels and evidence-backed completion claims
• current-source version discipline
• CLI-first scaffolding
• concise communication

To use it elsewhere, copy docs/AGENTS.md into the target repo root as AGENTS.md.

If you use both AGENTS.md and .cursor/rules, keep them aligned rather than letting them evolve into contradictory prompt layers.

The example patterns above are still useful outside Cursor: the agent-team workflow is portable markdown, while the incident-triage skill shows how to structure a large workflow even if your environment uses a different skill system.

Warnings

Never manually fabricate:

• .xcodeproj
• project.pbxproj
• .xcworkspace
• complex .sln or similar IDE-managed project metadata

Use the relevant CLI or IDE instead, then let the agent work inside the real project.

Contributing

See CONTRIBUTING.md for the repo's contribution rules, skill frontmatter contract, and placement guidance for always-on rules, requestable rules, and skills.

References

• MiniMax M2.7 Release Report
• MiniMax M2.7 Model Page
• MiniMax Text Generation Docs
• MiniMax API Overview
• Cursor Changelog
• Cursor Rules Docs
• Cursor Agent Best Practices
• MiniMax Platform
• OpenAI Codex Best Practices
• OpenAI Exec Plans