| name | vibe |
| description | Delegate coding tasks to Mistral Vibe CLI (powered by Devstral 2.1) for cost-efficient execution. Use this skill whenever a task is straightforward, well-defined, and does not require Claude's full reasoning capabilities — simple refactors, boilerplate generation, test scaffolding, documentation updates, file renaming, linting fixes, dependency bumps, small bug fixes, formatting, or mechanical code changes. Also use when the user explicitly asks to use Vibe, Devstral, or Mistral for a task. Do NOT use for complex architectural decisions, multi-step debugging requiring deep reasoning, or security-sensitive code review.
|
Mistral Vibe CLI Delegation Skill
Delegate simple, well-defined coding tasks to Mistral's Vibe CLI agent (powered by Devstral 2.1)
to save Claude tokens for harder problems. Vibe runs non-interactively via --prompt and returns
results that Claude summarizes for the user.
Prerequisites
vibe CLI installed and on PATH (install: curl -LsSf https://mistral.ai/vibe/install.sh | bash)
- Mistral API key configured (
~/.vibe/.env or MISTRAL_API_KEY env var)
- Confirm installation:
vibe --version; resolve any errors before using this skill
If vibe is not installed or not configured, inform the user and provide the installation
instructions above. Do NOT attempt to run vibe commands if the prerequisites are not met.
How It Works
- Claude evaluates the user's request
- If the task is simple/mechanical, Claude delegates to Vibe via a shell command
- Vibe runs non-interactively with
--prompt, auto-approving tool executions
- Claude reads the output and summarizes results back to the user
- If Vibe's output is insufficient or incorrect, Claude can either retry with a refined
prompt or fall back to handling the task itself
Task Routing Guidelines
Delegate to Vibe (cheap, fast)
- Boilerplate generation (new files, structs, interfaces, CRUD endpoints)
- Simple refactors (rename, extract function, move code between files)
- Test scaffolding and simple test writing
- Documentation and comment generation
- Formatting, linting fixes, import sorting
- Dependency version bumps
- Mechanical find-and-replace across files
- Adding error handling to straightforward functions
- Generating type definitions or interfaces from existing code
- Simple bug fixes where the issue is clearly identified
Keep in Claude (complex, nuanced)
- Architectural decisions or design pattern selection
- Security-sensitive code review or vulnerability analysis
- Complex multi-step debugging requiring deep reasoning
- Performance optimization requiring profiling analysis
- Tasks requiring understanding of the full project context across many files
- Anything the user explicitly wants Claude to handle
When in doubt
Ask the user: "This looks like it could be delegated to Vibe (Devstral 2.1) to save tokens.
Want me to handle it myself or delegate?"
CLI Usage
Basic non-interactive execution
vibe --prompt "<task description>" --max-turns <N> --max-price <dollars> 2>/dev/null
Flags reference
| Flag | Description | Default in --prompt mode |
|---|
--prompt "<task>" | Run non-interactively with this prompt | Required |
--max-turns N | Limit assistant turns | No limit |
--max-price N | Cost cap in USD | No limit |
--enabled-tools TOOL | Restrict to specific tools (can repeat) | All tools enabled |
Important notes
--prompt mode automatically enables auto-approve (no user confirmation needed)
- Stderr contains thinking tokens / debug output — suppress with
2>/dev/null to avoid
bloating Claude Code's context window
- If the user explicitly asks to see Vibe's thinking/reasoning, omit the
2>/dev/null
- Vibe requires a trusted folder — run from the project's working directory
Execution Patterns
Pattern 1: Simple task delegation (most common)
For a contained, single-purpose task:
cd /path/to/project && vibe --prompt "Add JSDoc comments to all exported functions in src/utils.ts" --max-turns 10 --max-price 0.50 2>/dev/null
Pattern 2: Read-only analysis
For tasks that only need to read code (no writes):
cd /path/to/project && vibe --prompt "List all API endpoints in this project with their HTTP methods and paths" --enabled-tools read_file --enabled-tools grep --max-turns 8 --max-price 0.30 2>/dev/null
Pattern 3: Scoped file edits
For edits limited to specific files:
cd /path/to/project && vibe --prompt "Refactor the error handling in src/api/client.rs to use thiserror instead of manual impl. Only modify files in src/api/." --max-turns 15 --max-price 1.00 2>/dev/null
Pattern 4: Test generation
cd /path/to/project && vibe --prompt "Generate unit tests for the functions in src/auth/token.go. Use the standard testing package. Place tests in src/auth/token_test.go" --max-turns 12 --max-price 0.50 2>/dev/null
Prompt Engineering for Vibe
When constructing the --prompt string for Vibe, follow these guidelines:
-
Be specific and self-contained — Vibe does not have the conversation context that Claude has.
Include all relevant details: file paths, function names, expected behavior, constraints.
-
Specify scope explicitly — Tell Vibe which files/directories to work in and which to avoid.
-
State the expected output — "Create a new file at X", "Modify function Y in file Z",
"Print a summary to stdout".
-
Include language/framework context — "This is a Rust project using Actix-web",
"This is a SvelteKit app with TypeScript".
-
Set boundaries — "Do not modify any files outside src/api/",
"Do not add new dependencies".
Handling Vibe Output
After Vibe completes:
- Read the stdout output — This contains Vibe's actions and results
- Verify the changes — Check modified files if needed (use
git diff or read the files)
- Summarize for the user — Tell them what Vibe did, what files changed, and whether
the task completed successfully
- Handle failures gracefully — If Vibe failed or produced incorrect results:
- For minor issues: retry with a more specific prompt
- For fundamental failures: fall back to handling the task directly with Claude
- Always inform the user what happened
Cost Management
Devstral 2.1 pricing: $0.40/M input tokens, $2.00/M output tokens.
For simple tasks, set conservative limits:
| Task type | Suggested --max-turns | Suggested --max-price |
|---|
| Boilerplate / scaffolding | 8-10 | $0.30 |
| Simple refactor | 10-15 | $0.50 |
| Test generation | 10-15 | $0.50 |
| Multi-file mechanical change | 15-20 | $1.00 |
| Read-only analysis | 5-8 | $0.20 |
Example Workflow
User says: "Add error handling to the API calls in src/services/"
Claude's process:
- Recognizes this as a mechanical task suitable for Vibe
- Constructs a specific prompt with project context
- Runs:
cd /path/to/project && vibe --prompt "Add proper error handling (try/catch or Result types as appropriate) to all API call functions in the src/services/ directory. Preserve existing function signatures. Use the project's existing error handling patterns." --max-turns 15 --max-price 0.50 2>/dev/null
- Reads output, verifies changes with
git diff --stat
- Reports to user: "Vibe updated 4 files in src/services/ — added error handling to 12 API calls. Here's a summary of changes: ..."