Conversion & compatibility

Quartermaster converts three artifact types across AI coding tools — skills, rules, and MCP server configs — covering the full matrix across Claude, Codex, Gemini, Cursor, Grok, and more harnesses (Qwen Code, DeepSeek, Cline, Pi). For example, it can convert a Claude Code skill to Codex, or a .cursorrules file to CLAUDE.md or AGENTS.md. Everything outside the supported matrix returns a structured blocker — never a silent failure or a lossy guess — and every preview is dry-run (nothing written).

Supported conversions (convert_capability)

Conversion	From → To	Notes
<src>_skill_to_<dst>_skill	any indexed skill → claude · codex · gemini · cursor · grok · qwen · deepseek	Claude/Grok/DeepSeek targets get YAML frontmatter (name + trigger description); the rest get plain markdown with a ## When to use section.
rule_to_claude / rule_to_codex / rule_to_gemini / rule_to_grok / rule_to_qwen / rule_to_deepseek / rule_to_pi	any tool’s rule → CLAUDE.md / AGENTS.md / GEMINI.md / GROK.md / QWEN.md / DEEPSEEK.md / AGENTS.md (pi reads AGENTS.md)	warns that the target file may already exist — merge, don’t clobber.
rule_to_cline	any tool’s rule → .clinerules/<slug>.md	one-file-per-rule dir, no merge required.
rule_to_cursor	any tool’s rule → .cursor/rules/<slug>.mdc	mdc frontmatter with alwaysApply: true; globs can’t be inferred (noted as lossiness).
rule_to_generic	any tool’s rule → generic rule	frontmatter/tool-specifics noted as lossiness.
mcp_config_to_<dst>	an indexed mcp_server → .mcp.json · .codex/config.toml · .gemini/settings.json · .cursor/mcp.json · .grok/settings.json · .qwen/settings.json · .deepseek/settings.json · cline_mcp_settings.json	secret values are never present — placeholders (***) mark what the operator must fill in. Gemini/Qwen remote servers map to httpUrl (HTTP) vs url (SSE).

Same-tool “conversion” is a no-op (status: "native" from assess_compatibility).

Everything else is blocked, explicitly

• assess_compatibility returns status: "blocked" with structured blockers:
  • memory_cross_tool_unsupported — memories never convert across tools (they are context-sensitive by design and block hydration by default).
  • conversion_rule_missing — no conversion rule exists for the requested pair (agents, commands, hooks, and settings remain cross-tool-blocked).
  • network_access_unavailable_on_target — a remote MCP server targeting a device declared network: false.
• convert_capability on an unsupported pair returns status: "blocked", blockers: ["conversion_rule_missing"], and writes nothing (dryRun: true, files: []).

Compatibility signals

assess_compatibility also reports:

• confidence — 1.0 native, 0.8 convertible (0.7 for MCP configs), lower for blocked guesses.
• warnings — e.g. scripts_target_os_unknown, mcp_secret_values_not_migrated.
• required_conversions — which converter(s) a hydration to the target tool would need.

Deeper checks (shell / dependency / network)

Every assessment also runs three deterministic checks, returned under checks and folded into warnings/blockers:

• shell — bundled scripts are classified posix (.sh/.bash/.zsh) vs windows (.ps1/.bat/.cmd) and compared against target.os.
• dependencies — runtime commands referenced by the artifact (node, python, docker, git, powershell, rust, go) are detected; targets declaring runtimes: [...] get runtime_missing_on_target:<dep> warnings.
• network — remote MCP transports, URL references, and network-calling commands become evidence; credential key names come from the item’s requires. network: false targets block remote MCP servers.

Not yet implemented (roadmap, not claimed)

• Agent / command / hook / settings cross-tool conversions.
• Hermes as a conversion target.
• Shebang-level shell detection inside script bodies (extension-based today).