M3 + Cursor 3.7 기반의 리포지토리(repo) 규모 엔지니어링을 위한 견고한 실행 중추 — 최첨단 에이전트(frontier-agent)의 코딩 판단력과 추론 프로토콜을 어떤 모델이라도 실행할 수 있는 규칙으로 정제하여 제공합니다.

*MiniMax M3 (1M-token MSA 컨텍스트, 네이티브 멀티모달(multimodal) 입력) 및 Cursor 3.7 (Agents Window, canvases, Design Mode, /worktree, /best-of-n, Await, MCP Apps)에 최적화되었습니다. 모델 변경 시에도 유용하게 유지되도록 작성되었습니다.

빠른 시작 · 이 리포지토리의 이유 · 아키텍처 · 런타임 모드 · 솔버 루프(Solver Loop) · AGENTS.md · 참고 문헌

핵심 전략: MiniMax는 페르소나 텍스트를 통해 개선되지 않습니다. 더 깨끗한 컨텍스트, 더 작은 증명 슬라이스(proving slices), 더 나은 도구 라우팅(tool routing), 정직한 검증을 통해 개선됩니다 — 그리고 최첨단 에이전트들이 사용하는 것과 동일한 판단 습관을 사용합니다: 증상을 고치는 것이 아니라 깨진 불변성(invariant)을 고칠 것; 테스트를 속이지 말 것; 모든 도구 결과 이후에 계획을 업데이트할 것. 여기의 모든 규칙은 이를 최적화합니다.

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

끝입니다. 두 개의 규칙은 항상 켜져 있습니다:

.cursor/rules/minimax-m3-core.mdc
— 추론 프로토콜, 실행 동작, 코드 규율, M3 롱 컨텍스트(long-context) 규율, M3 멀티모달(multimodal) 입력 규율

.cursor/rules/minimax-m3-status-verification.mdc
— 상태 및 증명 계약 (multimodal-grounded 시각적 증명, 버그 수정을 위한 red → green)

그 외의 모든 것은 설계상 **요청 가능(requestable)**하며 범위가 더 좁습니다 — 작업이나 파일 글로브(globs)가 호출할 때 로드됩니다. 두 개의 fable5-* 제작 규칙은 복잡한 코딩 및 추론 작업을 위해 로드되며, 나머지는 런타임 또는 도메인에 따라 연결됩니다.

공식 문서에서는 MiniMax 텍스트 모델에 대해 Anthropic 호환 (Anthropic-compatible) 액세스를 권장하며, OpenAI 호환 (OpenAI-compatible) 액세스 경로도 지원합니다. MiniMax 텍스트 생성 문서 · MiniMax API 개요를 참조하세요.

docs/AGENTS.md를 대상 리포지토리 루트에 AGENTS.md로 복사하세요.

이 파일이 이곳 docs/ 아래에 위치하는 것은 의도된 것입니다. 그래야 사용자가 이 규칙들을 편집하는 동안 Cursor가 이를 자동으로 활성화하지 않기 때문입니다.

.cursor/
├── rules/ # 20개의 규칙 (항상 활성화되는 2개 + 요청 가능한 18개)
│ ├── minimax-m3-core.mdc ★ 항상 활성화 · 실행 중추 (execution spine) + 추론 프로토콜 (reasoning protocol) + M3 규율 (disciplines)
...

이 리포지토리는 M3 출시가 강조하는 바로 그 지점들에서 MiniMax M3가 강력하게 느껴지도록 만듭니다:

• 1M-토큰 MSA 컨텍스트 (context) — 그리고 이를 비대하게 만들지 않고 사용하는 규율 (discipline)
• 네이티브 멀티모달 (native multimodal) 입력 (이미지, 비디오) — 그리고 시각적 주장을 실제 파일에 근거(grounding)시키는 규율
• 더 높은 에이전트 (agentic) 및 코딩 벤치마크 — 역할 분리 및 명시적 검증을 통해 활용됨
• 최첨단 코딩 판단력 (frontier coding judgment) — fable5-* 제작 규칙은 SWE-Bench급 점수 뒤에 숨겨진 습관들(근본 원인 분석법, 테스트 무결성, 교차 사고)을 오픈 모델이 따를 수 있는 형태로 정제합니다. 여기에는 에이전트 하네스 (agent harnesses)와 /best-of-n을 일급 팀 패턴으로 포함하는 멀티 에이전트 협업, 그리고 관련이 있을 때만 로드되는 긴 스킬 팩 (skill packs) 및 상세한 도구 계약 (tool contracts)이 포함됩니다.
• 변화하는 환경에서의 동적 도구 발견 (Cursor 3.7의 진화하는 MCP + 플러그인 표면)

목표는 MiniMax가 다른 제공업체의 톤을 모방하게 만드는 것이 아닙니다. M3가 자신의 목소리를 유지하면서도, 코드를 어디서 수정할지, 수정을 어떻게 증명할지, 언제 전략을 바꿀지와 같은 *판단력 (judgment)*을 전수하는 것입니다. 실제 엔지니어링, 복잡한 기술, 에이전트 워크플로, 긴 컨텍스트, 그리고 멀티모달 근거(multimodal grounding)를 중심으로 한 M3의 공식 포지셔닝을 보완하는 내구성 있는 실행 중추(execution spine)를 구축하는 것입니다.

왜 M3-네이티브인가 (그리고 그것이 무엇을 최적화하는가)

MiniMax는 M3를 세대적 전환으로 포지셔닝합니다: 1M-토큰 MSA 컨텍스트, 네이티브 멀티모달 입력, 그리고 더 높은 에이전트 및 코딩 벤치마크 (모델 페이지 참조).

따라서 이 리포지토리는 다음을 최적화합니다:

• 1M 토큰에 대한 명시적인 유지 및 압축 결정 ("모두 집어넣고 바라기"가 아님)
• 모든 시각적 주장을 실제 첨부된 이미지/프레임에 근거함 (multimodal-grounded)
• 모든 것을 읽는 대신 제한된 리포지토리 탐색 (bounded repo exploration)
• 대규모 작업을 위한 가장 작은 증명 슬라이스 (smallest proving slices)
• 높은 이해관계가 걸린 선택을 위한 /best-of-n을 포함하여, 멀티 에이전트 작업을 위한 명시적인 역할 및 핸드오프 (handoff) 규율
• 모호하고 긴 프롬프트 대신 강력한 기술 계약 (skill contracts)
• 정직한 런타임 (runtime) 및 검증 보고

MoE / MSA 참고 사항 — 제어할 수 있는 것과 없는 것

이 규칙들은 페르소나 텍스트를 통해 모델의 내부 라우팅 (internal routing)을 조종할 수 있다고 가정하지 않습니다. M3는 전체 어텐션 (full attention)을 쿼리당 KV-블록을 선택하는 MiniMax Sparse Attention (MSA)으로 교체하며, 제어 가능한 레버는 여전히 외부에 있습니다:

• 더 깔끔한 컨텍스트 (명시적인 유지 결정 포함)
• 더 나은 분해 (decomposition)
• 더 나은 도구 라우팅 (Cursor 3.7 인터페이스 포함)
• multimodal-grounded 시각적 증명을 포함한 더 나은 검증 루프 (verification loops)
• 더 명확한 완료 정의 (definitions of done)

만약 규칙 변경 후 M3의 성능이 향상되었다면, 그 이유는 숨겨진 전문가에게 마법처럼 접근했기 때문이 아니라, 외부 문제 구조가 개선되었기 때문일 가능성이 높습니다.

이 리포지토리가 M3로 전달하는 가장 중요한 단일 행동 양식은 다음과 같습니다:

1. 결과를 운영적 용어로 정의한다.
2. 결정하기 전에 리포지토리와 런타임을 검사한다.
3. 중추(spine)를 찾는다: 엔트리 포인트 (entry points), 데이터 흐름 (data flow), 상태 (state), 지속성 (persistence), 사용자 가시적 동작.
...

앱 구축의 경우, 이는 다음과 같은 의미입니다: 컴포넌트 더미로 시작하지 마세요. 먼저 핵심 흐름을 해결하고, 초기 단계에서 하나의 엔드 투 엔드 (end-to-end) 슬라이스를 증명한 다음, 다듬기 작업을 추가하세요.

이 리포지토리가 타협 불가능한 것으로 취급하는 몇 가지 행동 양식은 다음과 같습니다:

• 새로운 패키지(packages), 프레임워크(frameworks), 툴체인(toolchains)은 추천되거나 설치되기 전에 현재의 권위 있는 소스(authoritative sources)를 통해 검증됩니다. - 스캐폴딩(Scaffolding)은 공식 CLI / create / init 경로가 존재하는 경우 해당 프레임워크의 공식 경로를 사용합니다. - 스캐폴딩 결과물은 작업을 계속하기 전에 검사됩니다.
• 실행 가능한 작업은 단순히 정적인 확신(static confidence)이 아닌, **실행 가능한 증거(runnable proof)**가 있을 때까지 "완료"된 것이 아닙니다. - 버그 수정은 red → green으로 증명되어야 합니다: 즉, 변경 전에는 재현(reproduction)이 실패하고 변경 후에는 통과해야 합니다. 한 번도 red 상태였던 적이 없는 체크는 아무것도 증명하지 못합니다. - 테스트는 green 상태에 도달하기 위해 약화되거나, 건너뛰어지거나, 예외 처리(special-cased)되지 않습니다. 테스트가 곧 명세(spec)입니다. 만약 명세가 잘못되어 보인다면, 이는 사용자에게 전달되어야 합니다.
• 수정 사항은 증상 부위가 아닌 근본 원인(root cause)(깨진 불변량, broken invariant)에 적용되어야 하며, 배포된 임시 방편(workarounds)은 임시 방편으로 라벨링됩니다. - 스텁(Stubs), 모크(mocks), 하드코딩된 플레이스홀더(placeholders)는 마무리 단계(closeout)에서 명시되어야 하며, 결코 완성된 동작으로 제시되어서는 안 됩니다.
• 시각적 작업은 변경 후의 프레임이 다시 읽히기( multimodal-grounded ) 전까지는 "완료"된 것이 아닙니다. - 필수 체크가 실패하거나 건너뛰어지는 경우, 에이전트는 blocked 또는 implemented but unverified라고 보고해야 하며, 결코 거짓 완료(false completion)를 보고해서는 안 됩니다. - UI 및 상호작용에 대한 주장에는 브라우저 또는 사용자 인터페이스(user-surface) 검증이 필요합니다.
• 도구 기반의 약속(Tool-based promises)은 런타임 경로(runtime path)가 확인될 때까지 대기합니다.
• 1M-토큰 컨텍스트(1M-token context)가 에이전트의 압축 의무를 면제해주지는 않습니다. 오히려 압축에 실패했을 때의 비용을 높일 뿐입니다.

이 시스템은 계층화되어 있습니다: 항상 켜져 있는 아주 작은 코어(core), 최첨단 판단력(frontier judgment)을 담은 제작 규칙(craft rules), 필요에 따라 로드되는 런타임 규칙(runtime rules), 그리고 파일 글로브(file globs)를 통해 부착되는 도메인 규칙(domain rules)으로 구성됩니다. 깊이는 기술(skills)에 존재합니다.

최첨단 에이전트(Frontier-agent)의 판단력을 요청 가능한 규칙으로 정제 — SWE-Bench급 점수를 뒷받침하는 습관들을 M3 및 모든 오픈 모델로 전이 가능하게 구현함:

교차 도메인(cross-cutting domains)을 위한 요청 가능한 규칙이며, 언어별 요리법(cookbooks)이 아닙니다. 언어별 관용구(idioms)는 리포지토리 읽기, 공식 문서, 그리고 항상 활성화되어 있는 코드 규율 (Code Discipline) 섹션을 통해 습득합니다.

기술 (Skills)은 심층적이고 도메인 특화된 절차를 항상 활성화된 핵심 (core)에서 분리하여 유지하며, 점진적 공개 (progressive disclosure) (SKILL.md + 선택적 reference.md)를 통해 대규모의 구조화된 가이드를 제공합니다.

작업이 핵심 (core)에 담기에는 너무 상세하여 반복 가능한 워크플로우를 갖거나, 예시 또는 카테고리 휴리스틱이 필요하거나, 점진적 공개를 통해 이득을 얻을 수 있는 경우 기술 (skill)을 로드합니다. M3의 1M 문맥 (context) 환경에서도

MiniMax M3 (2026-06-01 출시)는 이 리포지토리의 대상 모델입니다. 이 모델은 1M 토큰의 MSA 문맥 창 (context window)과 네이티브 멀티모달 입력 (text, image, video)을 제공합니다. 이 리포지토리는 M3를 우선적으로 튜닝하였으나, composer-2.5, GPT 또는 Claude와 같은 제3자 모델에서도 올바르게 작동합니다. 즉, M3 전용 섹션(긴 문맥 규율 (long-context discipline), 멀티모달 입력 규율 (multimodal input discipline))은 비활성화되지만, 항상 작동하는 핵심 기능 (always-on core)은 계속해서 적용됩니다.