feat: add MiniMax Code skills support

docs/cli.md

@@ -107,7 +107,7 @@ openspec init [path] [options]
 
 `--profile custom` uses whatever workflows are currently selected in global config (`openspec config profile`).
 
-**Supported tool IDs (`--tools`):** `amazon-q`, `antigravity`, `auggie`, `bob`, `claude`, `cline`, `codex`, `forgecode`, `codebuddy`, `continue`, `costrict`, `crush`, `cursor`, `factory`, `gemini`, `github-copilot`, `iflow`, `junie`, `kilocode`, `kimi`, `kiro`, `opencode`, `pi`, `qoder`, `lingma`, `qwen`, `roocode`, `trae`, `windsurf`
+**Supported tool IDs (`--tools`):** `amazon-q`, `antigravity`, `auggie`, `bob`, `claude`, `cline`, `codex`, `forgecode`, `codebuddy`, `continue`, `costrict`, `crush`, `cursor`, `factory`, `gemini`, `github-copilot`, `iflow`, `junie`, `kilocode`, `kimi`, `kiro`, `lingma`, `minimax-code`, `opencode`, `pi`, `qoder`, `qwen`, `roocode`, `trae`, `vibe`, `windsurf`
 
 **Examples:**
 
@@ -121,6 +121,9 @@ openspec init ./my-project
 # Non-interactive: configure for Claude and Cursor
 openspec init --tools claude,cursor
 
+# Non-interactive: configure MiniMax Code global skills
+openspec init --tools minimax-code
+
 # Configure for all supported tools
 openspec init --tools all
 
@@ -142,9 +145,12 @@ openspec/
 .claude/skills/         # Claude Code skills (if claude selected)
 .cursor/skills/         # Cursor skills (if cursor selected)
 .cursor/commands/       # Cursor OPSX commands (if delivery includes commands)
+~/.minimax/skills/      # MiniMax Code skills (if minimax-code selected)
 ... (other tool configs)
 ```
 
+MiniMax Code uses a fixed user-home target: OpenSpec writes its skills to `~/.minimax/skills/` and detects existing OpenSpec MiniMax Code setup from that directory. It does not create project-local `.minimax` or `.mavis` directories. When delivery is `commands`, MiniMax Code command generation is skipped because no command adapter exists, and existing global MiniMax Code skills are left untouched.
+
 ---
 
 ### `openspec update`
@@ -215,7 +221,7 @@ openspec workspace setup --no-interactive --json --name checkout --link /repos/p
 
 Interactive setup asks for a preferred opener and can install workspace-local OpenSpec skills for selected agents. Non-interactive setup stores a preferred opener only when `--opener` is provided; otherwise `workspace open` prompts later in interactive terminals when a supported opener is available, or asks scripts to pass `--agent <tool>` or `--editor`.
 
-Workspace skill installation is skills-only in this beta slice: even if global delivery is `commands` or `both`, workspace setup writes agent skill folders in the workspace root and does not create slash command files. The active global profile chooses which workflow skills are installed; `--tools` chooses which agents receive them. If `--tools` is omitted in non-interactive setup, no skills are installed and `workspace update --tools <ids>` can add them later.
+Workspace skill installation is skills-only in this beta slice: even if global delivery is `commands` or `both`, workspace setup writes agent skill folders and does not create slash command files. Project-local tools are written in the workspace root; MiniMax Code is written to `~/.minimax/skills/`. The active global profile chooses which workflow skills are installed; `--tools` chooses which agents receive them. If `--tools` is omitted in non-interactive setup, no skills are installed and `workspace update --tools <ids>` can add them later.
 
 ### `openspec workspace list`
 
@@ -304,7 +310,7 @@ openspec workspace update --workspace platform --tools codex,claude
 openspec workspace update --workspace platform --tools none
 ```
 
-`workspace update` refreshes the generated workspace guidance block and local open surface. For agent skills, it reuses the stored workspace skill agent selection when `--tools` is omitted. Passing `--tools` replaces that stored selection. It refreshes only OpenSpec-managed workflow skill directories in the workspace root, removes deselected managed workflow skills, and leaves linked repos and folders untouched.
+`workspace update` refreshes the generated workspace guidance block and local open surface. For agent skills, it reuses the stored workspace skill agent selection when `--tools` is omitted. Passing `--tools` replaces that stored selection. It refreshes only OpenSpec-managed workflow skill directories in the resolved skill target, removes deselected managed workflow skills, and leaves linked repos and folders untouched. MiniMax Code workspace skills use `~/.minimax/skills/` and never create workspace-local `.minimax` or `.mavis` fallback directories.
 
 Running `openspec update` from inside a workspace does not update workspace-local files. Use `openspec workspace update` when you want workspace-local guidance and skills refreshed, and run `openspec update` inside repo-local projects when you want repo-owned tool files updated.
 

docs/commands.md

@@ -619,6 +619,7 @@ Different AI tools use slightly different command syntax. Use the format that ma
 | Windsurf | `/opsx-propose`, `/opsx-apply` |
 | Copilot (IDE) | `/opsx-propose`, `/opsx-apply` |
 | Kimi CLI | Skill-based invocations such as `/skill:openspec-propose`, `/skill:openspec-apply-change` (no generated `opsx-*` command files) |
+| MiniMax Code | Skill-based invocations from `~/.minimax/skills`, such as `openspec-propose` or `openspec-apply-change` depending on the MiniMax Code skill picker UI (no generated `opsx-*` command files) |
 | Trae | Skill-based invocations such as `/openspec-propose`, `/openspec-apply-change` (no generated `opsx-*` command files) |
 
 The intent is the same across tools, but how commands are surfaced can differ by integration.
@@ -684,6 +685,7 @@ The AI tool doesn't recognize OpenSpec commands.
 - Ensure OpenSpec is initialized: `openspec init`
 - Regenerate skills: `openspec update`
 - Check that `.claude/skills/` directory exists (for Claude Code)
+- Check that `~/.minimax/skills/openspec-*/SKILL.md` exists for MiniMax Code
 - Restart your AI tool to pick up new skills
 
 ### Artifacts not generating properly

docs/supported-tools.md

@@ -44,6 +44,7 @@ You can enable expanded workflows (`new`, `continue`, `ff`, `verify`, `bulk-arch
 | Kimi CLI (`kimi`) | `.kimi/skills/openspec-*/SKILL.md` | Not generated (no command adapter; use skill-based `/skill:openspec-*` invocations) |
 | Kiro (`kiro`) | `.kiro/skills/openspec-*/SKILL.md` | `.kiro/prompts/opsx-<id>.prompt.md` |
 | Lingma (`lingma`) | `.lingma/skills/openspec-*/SKILL.md` | `.lingma/commands/opsx/<id>.md` |
+| MiniMax Code (`minimax-code`) | `~/.minimax/skills/openspec-*/SKILL.md` | Not generated (no command adapter; use MiniMax Code skill-based invocations) |
 | Mistral Vibe (`vibe`) | `.vibe/skills/openspec-*/SKILL.md` | Not generated (no command adapter; use skill-based `/openspec-*` invocations) |
 | OpenCode (`opencode`) | `.opencode/skills/openspec-*/SKILL.md` | `.opencode/commands/opsx-<id>.md` |
 | Pi (`pi`) | `.pi/skills/openspec-*/SKILL.md` | `.pi/prompts/opsx-<id>.md` |
@@ -57,6 +58,8 @@ You can enable expanded workflows (`new`, `continue`, `ff`, `verify`, `bulk-arch
 
 \*\* GitHub Copilot prompt files are recognized as custom slash commands in IDE extensions (VS Code, JetBrains, Visual Studio). Copilot CLI does not currently consume `.github/prompts/*.prompt.md` directly.
 
+MiniMax Code skills are installed in the user's global MiniMax Code skills directory (`~/.minimax/skills/`), not in the current repository. OpenSpec never creates repo-local `.minimax` or `.mavis` fallback directories for MiniMax Code. If delivery is `commands`, OpenSpec skips MiniMax Code command generation and preserves any existing global MiniMax Code skills.
+
 ## Non-Interactive Setup
 
 For CI/CD or scripted setup, use `--tools` (and optionally `--profile`):
@@ -75,7 +78,7 @@ openspec init --tools none
 openspec init --profile core
 ```
 
-**Available tool IDs (`--tools`):** `amazon-q`, `antigravity`, `auggie`, `bob`, `claude`, `cline`, `codex`, `forgecode`, `codebuddy`, `continue`, `costrict`, `crush`, `cursor`, `factory`, `gemini`, `github-copilot`, `iflow`, `junie`, `kilocode`, `kimi`, `kiro`, `lingma`, `opencode`, `pi`, `qoder`, `qwen`, `roocode`, `trae`, `vibe`, `windsurf`
+**Available tool IDs (`--tools`):** `amazon-q`, `antigravity`, `auggie`, `bob`, `claude`, `cline`, `codex`, `forgecode`, `codebuddy`, `continue`, `costrict`, `crush`, `cursor`, `factory`, `gemini`, `github-copilot`, `iflow`, `junie`, `kilocode`, `kimi`, `kiro`, `lingma`, `minimax-code`, `opencode`, `pi`, `qoder`, `qwen`, `roocode`, `trae`, `vibe`, `windsurf`
 
 ## Workflow-Dependent Installation
 

openspec/changes/add-minimax-code-tool-support/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-06-14

openspec/changes/add-minimax-code-tool-support/design.md

@@ -0,0 +1,122 @@
+## Context
+
+OpenSpec currently treats skill installation as a project-root concern. Tool metadata is centered on `skillsDir`, detection scans project directories, and both `init` and `update` derive skill targets from `path.join(projectRoot, tool.skillsDir, 'skills')`.
+
+MiniMax Code needs a different skill target. Current local verification shows MiniMax Code uses the user's `~/.minimax/skills` location for user-installable skills, and `.mavis` compatibility appears to point at the same backing location. For this change, OpenSpec will target `~/.minimax/skills` directly and will not attempt to discover MiniMax runtime profile or data-dir overrides.
+
+The implementation should stay close to the existing model: keep the common skill generation logic, add a small shared helper for resolving the effective skill directory, and reuse the existing behavior for tools that have skills but no command adapter.
+
+## Goals / Non-Goals
+
+**Goals:**
+
+- Add MiniMax Code as a supported OpenSpec tool target with a stable tool id (`minimax-code`)
+- Install MiniMax Code OpenSpec skills into the user's fixed MiniMax Code skill directory (`~/.minimax/skills`)
+- Let `openspec init` detect, install, and refresh MiniMax Code skills using that global user-home target
+- Let `openspec update` detect an existing MiniMax Code OpenSpec installation and refresh it in place
+- Avoid creating repo-local `.minimax` or `.mavis` directories for MiniMax Code
+- Keep implementation additive and low-disruption by reusing existing adapterless skills behavior
+
+**Non-Goals:**
+
+- Adding a MiniMax-specific slash-command adapter or command file output path
+- Dynamically resolving MiniMax runtime profile or data-dir overrides
+- Supporting arbitrary user-entered MiniMax skill paths
+- Migrating pre-existing MiniMax user skills that are not OpenSpec-managed
+- Redesigning command generation, profile delivery, or all tool metadata beyond what is needed for this fixed global skill target
+
+## Decisions
+
+### 1. Represent MiniMax Code with fixed user-home global skill target metadata
+
+`AI_TOOLS` should gain a minimal `globalSkillsDir` field for tools whose OpenSpec skills are not stored under `<projectRoot>/<skillsDir>/skills`. Existing tools continue using `skillsDir`, while MiniMax Code declares `globalSkillsDir: '.minimax'`.
+
+Call sites that only need to know whether a tool supports skills can use `tool.skillsDir || tool.globalSkillsDir`. Path resolution still needs to distinguish the two fields:
+
+- `skillsDir`: resolve to `<projectRoot>/<skillsDir>/skills`
+- `globalSkillsDir`: resolve to `<home>/<globalSkillsDir>/skills`
+
+Why this over a full runtime resolver:
+
+- It keeps this change small and close to the current `skillsDir` model.
+- It avoids making synchronous detection/update flows depend on an external MiniMax CLI command.
+- It matches current local verification where `.mavis` points to `.minimax`.
+- It leaves runtime discovery as a future improvement if real installations require it.
+
+Alternative considered:
+
+- Invoke MiniMax runtime configuration and parse a `dataDir`.
+  Deferred because it expands the failure surface and requires stronger knowledge of MiniMax CLI contracts than this first integration needs.
+
+### 2. Add a shared skill directory helper instead of a skill adapter system
+
+OpenSpec does not currently have skill adapters. Skills use common content generation and a tool-level `skillsDir`; only commands have adapters. This change should preserve that shape by adding a small helper that resolves the skill directory for a tool:
+
+- Project-local tools with `skillsDir`: `<projectRoot>/<skillsDir>/skills`
+- MiniMax Code with `globalSkillsDir: '.minimax'`: `<home>/.minimax/skills`
+
+Why this approach:
+
+- It keeps `init`, `update`, detection, profile drift, and migration aligned without duplicating path rules.
+- It avoids introducing a broader skill adapter abstraction before there is more than one tool-specific skill format.
+- It lets MiniMax Code reuse the same skill templates and generated metadata as other tools.
+
+### 3. Treat MiniMax Code as a global skills-only integration
+
+MiniMax Code should reuse the adapterless command behavior, but not the destructive commands-only skill cleanup behavior for global user-home skills. In repo-local `openspec init` and `openspec update`, when delivery includes skills, OpenSpec writes MiniMax Code skills. When delivery includes commands, OpenSpec skips command generation for MiniMax Code because no command adapter exists. When repo delivery is `commands`, OpenSpec should leave existing MiniMax Code global skills untouched.
+
+Workspace setup/update is different: existing workspace skill behavior ignores command delivery and remains skills-only. When MiniMax Code is selected as a workspace agent, workspace setup/update should refresh MiniMax Code skills in `<home>/.minimax/skills` even if global delivery is `commands` or `both`; it still never generates MiniMax command files.
+
+Codex is the closest reference point for global command output: Codex commands are written to `CODEX_HOME/prompts`, but Codex OpenSpec skills remain workspace/project-local, so commands-only delivery never deletes user-home OpenSpec skill directories. MiniMax Code's only OpenSpec surface in this change is a user-home global skill directory, so deleting that directory on a repo-local delivery change would have a wider blast radius than Codex.
+
+Why this approach:
+
+- It reuses existing delivery semantics instead of adding MiniMax-specific delivery rules.
+- It keeps repo-local `delivery=commands` non-destructive for user-home global skill targets.
+- It prevents OpenSpec from inventing unsupported MiniMax command files.
+- It avoids one project's delivery setting removing OpenSpec skills used by other MiniMax Code projects.
+
+### 4. Detect and refresh MiniMax Code from the fixed global target
+
+Configured-tool detection, version checks, profile drift checks, migration scans, and update refresh logic should use the shared skill directory helper. For MiniMax Code, detection is based on `openspec-*` skill files under `~/.minimax/skills`, not on a repo-local marker directory.
+
+Why this approach:
+
+- `openspec init` can show MiniMax Code as already configured when its managed skills already exist globally.
+- `openspec update` can refresh MiniMax Code even when there is no project-local MiniMax directory.
+- A shared path helper avoids drift where setup, detection, and refresh disagree about the active target.
+
+Workspace skill setup and update should also use the same helper. Workspace code currently assumes `workspaceRoot/<skillsDir>/skills`; if it is not updated, MiniMax Code will either be excluded from workspace agent selection or written to the wrong workspace-local fallback path.
+
+### 5. Never create a repo-local MiniMax fallback
+
+OpenSpec should not create `<projectRoot>/.minimax`, `<projectRoot>/.mavis`, or any repo-local MiniMax fallback when setting up MiniMax Code. If the fixed home target cannot be prepared or written, MiniMax Code setup should fail for that tool with a clear filesystem error while preserving the existing per-tool success/failure summary behavior.
+
+Why this approach:
+
+- It avoids silently writing invalid files to the repository.
+- It keeps the first implementation simple and predictable.
+- It preserves non-OpenSpec MiniMax user skills outside `openspec-*` skill directories. `openspec-*` directories are treated as OpenSpec-owned workflow skill targets and may be overwritten or removed by profile cleanup even if the user edited their contents.
+
+## Risks / Trade-offs
+
+- `[MiniMax installations with custom data roots are not supported in this first version]` -> Mitigation: document the fixed `~/.minimax/skills` target and leave runtime discovery as future work.
+- `[Global installations are less project-scoped than repo-local paths]` -> Mitigation: document MiniMax Code as a global user-home integration and display the global path in user-facing setup/update output where practical.
+- `[Cross-platform home path bugs]` -> Mitigation: build targets with `os.homedir()` and `path.join()`, and cover Windows-style home directories in unit tests.
+- `[Commands-only delivery could remove global MiniMax Code OpenSpec skills across projects]` -> Mitigation: commands-only delivery for MiniMax Code must skip command generation and leave existing global MiniMax Code skills untouched, mirroring Codex's non-destructive treatment of user-home surfaces.
+- `[Managed cleanup or refresh could overwrite user-authored colliding MiniMax skills]` -> Mitigation: document that `openspec-*` directories under the MiniMax Code skill target are OpenSpec-managed workflow skill targets. Users should keep unrelated MiniMax skills outside the `openspec-*` namespace.
+
+## Migration Plan
+
+There is no schema or repository migration required for existing OpenSpec projects.
+
+Implementation rollout should follow this sequence:
+
+1. Add MiniMax Code metadata and the shared skill directory helper for project-local and home-relative global targets.
+2. Wire detection, init, update, profile drift, migration scans, and workspace skill setup/update to use the helper.
+3. Update documentation so users know MiniMax Code installs globally at `~/.minimax/skills` and uses skills as its workflow surface.
+4. Verify fresh setup, repeat refresh, delivery modes, workspace setup/update, managed-only cleanup, and non-OpenSpec skill preservation before release.
+
+## Open Questions
+
+- Do MiniMax installations with explicit profile/data-dir overrides need to be supported in a follow-up runtime discovery change?