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.