May 26, 2026 · 5 min read

Grok Build Skills and Plugins: How to Extend Your Coding Agent

Grok Build ships with solid defaults, but the skills system is what makes it adaptable to your specific workflow. Skills are modular capabilities you can add, remove, and configure. Think of them as plugins that teach Grok Build new tricks.

This guide covers how skills work, how to install them from the marketplace, and how to build your own. For the basics of Grok Build itself, see the complete guide.

What Are Skills?

A skill is a packaged capability that extends what Grok Build can do. Each skill defines:

Tools it provides (functions the agent can call)
Context it adds (system prompts, documentation)
Triggers that activate it (file patterns, commands, hooks)

Examples of what skills enable:

Database migration generation from schema changes
Automatic test writing in your project’s testing framework
Deployment to specific cloud providers
Code style enforcement beyond what linters catch
Integration with your internal APIs or services

Installing Skills from the Marketplace

The Grok Build marketplace hosts community and official skills:

# Browse available skills
grok skills search "testing"

# Install a skill
grok skills install @grok/jest-generator

# List installed skills
grok skills list

# Remove a skill
grok skills remove @grok/jest-generator

Popular skills as of launch:

Skill	What it does
`@grok/jest-generator`	Generates Jest tests matching your patterns
`@grok/prisma-helper`	Schema migrations, seed data, query optimization
`@grok/docker-compose`	Generates and validates Docker Compose configs
`@grok/github-actions`	Creates CI/CD workflows from descriptions
`@grok/api-docs`	Generates OpenAPI specs from route handlers
`@grok/security-audit`	Scans for common vulnerabilities in code

Skill Configuration

Installed skills can be configured per-project:

// .grok/skills.json
{
  "installed": [
    {
      "name": "@grok/jest-generator",
      "version": "1.2.0",
      "config": {
        "testDir": "src/__tests__",
        "coverage": true,
        "mockStyle": "manual"
      }
    },
    {
      "name": "@grok/prisma-helper",
      "version": "0.9.1",
      "config": {
        "schemaPath": "prisma/schema.prisma",
        "provider": "postgresql"
      }
    }
  ]
}

Override skill settings from the CLI:

# Temporarily disable a skill
grok skills disable @grok/security-audit

# Enable it again
grok skills enable @grok/security-audit

# Update all skills
grok skills update

Creating Custom Skills

Custom skills let you teach Grok Build about your specific codebase, internal tools, or team conventions.

Skill Structure

A skill is a directory with a skill.json manifest:

my-skill/
├── skill.json          # Manifest
├── tools/              # Tool definitions
│   └── deploy.json
├── context/            # Additional context files
│   └── conventions.md
└── hooks/              # Lifecycle hooks (optional)
    └── before-commit.sh

The Manifest

// skill.json
{
  "name": "my-deploy-skill",
  "version": "1.0.0",
  "description": "Deploy to our internal Kubernetes cluster",
  "author": "your-team",
  "tools": [
    {
      "name": "deploy_to_staging",
      "description": "Deploy the current branch to the staging cluster",
      "parameters": {
        "service": {
          "type": "string",
          "description": "Service name to deploy",
          "required": true
        },
        "tag": {
          "type": "string",
          "description": "Docker image tag",
          "default": "latest"
        }
      },
      "command": "kubectl apply -f k8s/staging/ --image-tag={{tag}}"
    }
  ],
  "context": [
    {
      "file": "context/conventions.md",
      "description": "Team deployment conventions"
    }
  ],
  "triggers": {
    "filePatterns": ["k8s/**/*.yaml", "Dockerfile"],
    "commands": ["deploy", "release"]
  }
}

Tool Definitions

Tools are the functions Grok Build can call when your skill is active:

// tools/deploy.json
{
  "name": "deploy_to_staging",
  "type": "shell",
  "command": "./scripts/deploy.sh",
  "args": ["--env", "staging", "--service", "{{service}}"],
  "confirmation": true,
  "timeout": 120
}

The confirmation: true flag means Grok Build will ask the user before executing this tool. Use it for destructive or side-effect-heavy operations.

Adding Context

Context files give Grok Build knowledge about your conventions:

<!-- context/conventions.md -->
# Deployment Conventions

- All deployments go through staging first
- Use semantic versioning for image tags
- Never deploy directly to production from a feature branch
- Run integration tests before any deployment
- Notify #deployments Slack channel after successful deploy

When this skill is active, Grok Build includes this context in its system prompt and follows these rules.

Installing Your Custom Skill

# Install from a local directory
grok skills install ./my-skill

# Install from a git repo
grok skills install https://github.com/your-org/grok-deploy-skill

# Install from a tarball
grok skills install ./my-skill-1.0.0.tar.gz

Publishing to the Marketplace

Once your skill is ready for others:

# Validate your skill manifest
grok skills validate ./my-skill

# Package it
grok skills pack ./my-skill

# Publish (requires xAI developer account)
grok skills publish ./my-skill-1.0.0.tar.gz

Published skills go through a review process before appearing in the marketplace. The review checks for:

Valid manifest structure
No malicious commands
Proper permission declarations
Working tool definitions

Skills vs MCP Servers

Both skills and MCP servers extend Grok Build, but they serve different purposes:

Feature	Skills	MCP Servers
Scope	Grok Build specific	Cross-tool (works with Claude Code, etc.)
Tools	Defined in JSON	Defined via MCP protocol
Context	Bundled markdown files	Provided via resources
Distribution	Grok marketplace	Any MCP-compatible registry
Complexity	Low (JSON + scripts)	Medium (requires server process)

Use skills for Grok Build-specific workflows. Use MCP servers when you want the same capability available across multiple AI coding tools.

Best Practices

Keep skills focused. One skill per concern. Don’t bundle deployment, testing, and linting into a single skill.
Use confirmation for destructive actions. Any tool that modifies external state (deploys, database changes, API calls) should require confirmation.
Version your skills. Treat them like any other dependency. Pin versions in .grok/skills.json.
Include context files. The more context you give Grok Build about your conventions, the better it follows them.
Test your tools locally. Run the underlying commands manually before packaging them as skill tools.

FAQ

Can skills access the internet?

Yes, skill tools can make network requests if the underlying command does. However, skills that make outbound requests must declare this in their manifest under permissions.network. Users are warned during installation.

Do skills work in headless mode?

Yes. Skills are loaded in headless mode just like interactive mode. Tools with confirmation: true are auto-approved in headless mode unless you pass --require-confirmation.

Can I use skills from other team members?

Yes. Commit your .grok/skills.json to version control. Team members can run grok skills install to install all project skills. For private skills, host them in a private git repo.

How many skills can I install?

There’s no hard limit, but each skill adds context to the system prompt. If you install too many, you’ll eat into your 256K context window. Keep it to 5-10 active skills per project.

Do skills update automatically?

No. Run grok skills update to check for and install updates. You can pin specific versions in your config to prevent unexpected changes.

Can a skill override Grok Build’s default behavior?

Skills can add tools and context but cannot override core behavior. They extend, not replace. If a skill tool conflicts with a built-in tool name, the built-in takes priority.