Advanced Productivity: Combining Agents, Skills, and Modes — Mistral Vibe Advanced: Agents, Skills, and Local Mode

Lesson updated November 2, 2026. Example agent files now use the keys documented by Vibe: instructions (not system_prompt), active_model (not model), [tools.<tool>] blocks for approvals (the auto_approve key does not exist in an agent file), and the correct tool names (edit, not edit_file; no list_dir tool). Reminder from Lesson 3: safety is a visual indicator, not a permission. Source: Configuration reference.

The Complete Ecosystem

You have now mastered the three pillars of Mistral Vibe: agents decide who executes, skills describe what to do, and modes set the context. In isolation, each offers a modest gain. It is their combination that changes the nature of the work—and this lesson shows you how to organize them into a coherent professional development environment.

It all starts with organization. What follows you from project to project lives in ~/.vibe/; what only makes sense for a specific repository stays in the repository. This separation prevents you from dragging a database seeding skill into every project, and more importantly, it ensures a colleague can clone your repository without missing the tools they need.

~/.vibe/
├── agents/
│   ├── review.toml          # Code review mode (safe)
│   ├── dev.toml             # Development mode (neutral)
│   ├── deploy.toml          # Deployment mode (destructive)
│   └── ci-runner.toml       # CI subagent (yolo, container only)
├── skills/
│   ├── code-review/SKILL.md
│   ├── test-gen/SKILL.md
│   ├── smart-commit/SKILL.md
│   ├── lint-fix/SKILL.md
│   └── db-migrate/SKILL.md
└── config.toml

mon-projet/.vibe/
├── skills/
│   ├── deploy-staging/SKILL.md    # Project-specific
│   └── seed-database/SKILL.md    # Project-specific
└── config.toml                    # Local configuration

A Typical Day

The morning starts in read-only mode. You begin with the custom plan agent created in Lesson 2 (Vibe does not provide a built-in one), ask what has changed since Monday, and get an explanation of a module you haven’t touched in six months—none of this modifies a file. Once you have surveyed the landscape, Shift+Tab switches you to review mode to tackle a pull request.

# Start with the custom plan agent from Lesson 2 (read-only)
vibe --agent plan

# Explore recent changes
> Which files have been modified since Monday?
> Analyze the architecture of the src/api/ module

# Switch to review mode
# Shift+Tab → review
> Review the changes in PR #42

Next comes implementation, which requires a mode capable of writing. You describe what you want, then delegate anything mechanical to slash commands: generating tests for the file you just wrote, cleaning up the touched directory.

# Switch to dev mode
# Shift+Tab → dev

> Implement the POST /api/users endpoint with Zod validation

# Use slash commands
/test-gen src/api/users.ts
/lint-fix src/api/

Before committing, the same sequence repeats every time, which is precisely why we made them commands.

# Slash commands in sequence
/lint-fix src/
/code-review src/api/users.ts

# Smart commit
/smart-commit

Finally, deployment happens in a destructive mode where every step requires your validation. Here, the mode change acts as a security barrier as much as a tooling switch.

# Switch to deploy mode (destructive, confirmation required)
# Shift+Tab → deploy

> Deploy to staging
# Vibe follows the sequence: test → build → deploy → verify

Making Agents and Skills Talk

An agent can know your skills and remind you of them at the right moment. Simply mention them in its system prompt: the agent does not execute them for you, but it suggests the relevant command immediately after producing code, at the exact moment you might forget.

# ~/.vibe/agents/fullstack-dev.toml
display_name = "Fullstack Dev"
safety = "neutral"

instructions = """
You are a fullstack developer.
Available skills you can suggest to the user:
- /test-gen for unit tests
- /lint-fix for cleanup
- /smart-commit for commits
- /code-review for code review

After each implementation, suggest relevant skills.
"""

Subagents, on the other hand, handle an isolated portion of the pipeline while you continue working. A read-only security check is the textbook case: it only needs read_file and grep, so it cannot break anything, and it runs in parallel without interrupting you.

# Subagent for security analysis (runs in parallel)
display_name = "Security Check"
agent_type = "subagent"
safety = "safe"
instructions = """Analyze files for OWASP Top 10 vulnerabilities."""
enabled_tools = ["read_file", "grep"]

[tools.read_file]
permission = "always"

[tools.grep]
permission = "always"

Three Recurring Workflows

The first, “Explore → Plan → Execute,” suits new features: you explore the codebase with your plan agent to understand the context, ask Vibe to propose an implementation plan, then execute that plan with the dev or accept-edits agent. The second, “Write → Review → Fix,” applies to code you just wrote: implement with the dev agent, review with /code-review, and fix identified issues by switching back to dev. The third, “Test → Commit → Deploy,” closes the cycle: /test-gen followed by test execution, /smart-commit for a conventional message, and the deploy agent for production release with verification.

Two Levels of Configuration

The global config.toml declares what follows you everywhere, including a directory of team-shared skills—this is how a commit convention or review checklist stops being a personal matter.

# ~/.vibe/config.toml

# Globally enabled skills
enabled_skills = ["code-review", "test-gen", "lint-fix", "smart-commit"]

# Paths to team-shared skills
skill_paths = ["/home/equipe/vibe-skills"]

The local file complements this set with project-specific skills, and crucially, removes those that do not belong there. This disabled_skills list matters as much as activation: autocomplete cluttered with irrelevant commands eventually gets ignored.

# mon-projet/.vibe/config.toml

# Additional skills for this project
enabled_skills = ["deploy-staging", "seed-database", "db-migrate"]

# Disable irrelevant skills
disabled_skills = ["experimental-*"]

Finally, verify that all this produces a real effect. Time your context-switching: moving from one task to another should take less than five seconds with Shift+Tab; otherwise, your modes are poorly defined. Next, count how many times per day your slash commands are actually used—a command not called in two weeks should be deleted or renamed. Lastly, look at how many issues the review mode catches before commit: this is the most telling metric, as it counts bugs that never reached production.

Key Takeaways

Organize your agents by security level, your skills by functionality
Follow the “Explore → Plan → Execute” pattern for new features
Use slash commands for repetitive tasks
Combine global agents with local project skills
Shift+Tab is your most productive shortcut
Measure and adjust your configuration regularly