xAI’s Grok coding agent documents native SKILL.md support. It discovers project and user skills, exposes user-invocable skills as slash commands, and can load skills from plugins and extra configured paths. Grok also reads Claude Code skill and instruction locations for compatibility.
Where Grok discovers skills
Project skills live under ./.grok/skills/; user skills live under ~/.grok/skills/. Grok can also discover skills from enabled plugins and paths configured in ~/.grok/config.toml. Its compatibility layer reads common Claude Code locations and the shared ~/.agents/skills/ path.
Core and extended frontmatter
A skill can use name and description as the portable base. Grok adds fields including when-to-use, path globs, invocation controls, argument hints, and display metadata. It accepts several common fields that it does not enforce. That makes a file parse successfully without guaranteeing every host-specific behavior.
---
name: release-check
description: Verify a candidate release against its build, package, download, and public runtime. Use before calling a desktop or web product shipped.
when-to-use:
- release readiness
- verify the download
user-invocable: true
---
Exercise the artifact a user receives. Report any platform or signing path that was not run.Paths can keep a skill quiet
Grok’s paths field can hide a skill until work touches matching files. This can reduce noise in a large repository. Use it for genuinely file-specific procedures, not to compensate for a vague description. A deployment skill that applies to the whole service should remain discoverable before a deployment file changes.
Skills do not create tools
The documented allowed-tools field does not grant or restrict tools in Grok. Plugins and MCP servers provide actual capabilities. Keep the skill’s instructions separate from its tool dependencies and verify that the required extension is enabled before the workflow begins.
Claude compatibility still needs testing
Grok’s compatibility support is useful for reusing a Claude Code package, but extension semantics can differ. Dynamic context, permission fields, hooks, or subagent controls should be treated as host-specific until Grok’s documentation says otherwise. Test the portable body first, then add Grok-specific metadata only where it improves a real workflow.
A safe portability check
Install the same instruction-only skill in Grok and one other host. Run identical should-trigger and should-not-trigger prompts. Compare the selected evidence, steps, and output rather than prose style. Then add scripts or plugins one at a time. This isolates format portability from differences in models, tools, permissions, and shell behavior.