# Write Vibe Design Doc

Create or update implementation-ready design proposals for Mistral Vibe under...

- Repository: https://github.com/mistralai/mistral-vibe (5270 stars)
- Category: Design
- License: Apache-2.0
- Last updated: 2026-10-30
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add mistralai/mistral-vibe --skill write-vibe-design-doc -g -a claude-code -y`
Codex: `npx skills add mistralai/mistral-vibe --skill write-vibe-design-doc -g -a codex -y`
Cursor: `npx skills add mistralai/mistral-vibe --skill write-vibe-design-doc -g -a cursor -y`
Gemini CLI: `npx skills add mistralai/mistral-vibe --skill write-vibe-design-doc -g -a gemini-cli -y`

## Description

Create or update implementation-ready design proposals for Mistral Vibe under docs/design, including a bounded design-tree decision review before drafting. Use before implementing a substantial Vibe feature, migration, protocol or API change, runtime or persistence change, cross-component workflow, compatibility plan, or other work whose ownership, behavior, failure semantics, rollout, and validation need review.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Write Vibe Design Doc

Produce a decision artifact that a reviewer can use to evaluate the proposal and
an implementer can use as a completion checklist. Base it on product intent and
the real code path, not on a plausible architecture invented from file names.

## Design Doc Versus ADR

- Write a design doc for proposed work, implementation choices, migrations,
  alternatives, rollout, and verification.
- Use `write-vibe-adr` for a concise, durable architecture rule that future
  changes must follow. A design may require a new or updated ADR, but it does
  not replace one.
- Unless the user also asks for implementation, stop after the reviewed design
  document. Do not make product-code changes implicitly.

## Workflow

### 1. Establish scope and authority

1. Identify the user outcome, affected surfaces, requested deliverable, and
   destination. Default new proposals to `docs/design/<descriptive-slug>.md`.
   Honor response-only or alternate-destination requests without creating a
   repository artifact. Settle the target surfaces first, following the
   "Cross-Surface Features" section of `AGENTS.md`.
2. Collect named product specifications, issues, accepted decisions, and user
   corrections. Treat an explicitly named product source of truth as the target
   authority; use current code and ADRs to explain the starting point.
3. Read `README.md`, `AGENTS.md`, the matching ADRs, and one or two nearby
   design documents. Read the nearest `AGENTS.md` before examining a sibling
   project.
4. If the target direction conflicts with an ADR, flag the conflict and include
   the required ADR follow-up. Do not silently dilute either source.

When updating an existing proposal, preserve accepted decisions that the user
has not changed. Apply each correction throughout the document instead of
appending a new section that contradicts old routes, diagrams, ownership,
failure semantics, or acceptance checks.

The rest: https://github.com/mistralai/mistral-vibe/blob/HEAD/.vibe/skills/write-vibe-design-doc/SKILL.md