Vibe New App Skill

Generates the complete project kit from brief and architecture. Produces CLAUDE.md at project root and the full vibe/ folder the AI coding agent uses.

Always run in Plan Mode (Shift+Tab). Exit Plan Mode only before task execution.

Autonomous / headless mode. At startup resolve the settings with python3 ~/.claude/skills/vibe-mode/scripts/vibe_state.py mode. If vibe_mode is autonomous, every "wait", "ask", "confirm" and approval step in this skill follows vibe-mode's references/HEADLESS.md §2 instead: take the recommended option, accept your own draft after one self-check, log each choice to vibe/DECISIONS.md, never ask the user, and stop — writing vibe/.run_state.json — only when a person is genuinely required.

The O'Reilly principles this enforces

Spec before code — SPEC.md with acceptance criteria exists before any task runs. Context preservation — CLAUDE.md, CODEBASE.md, ARCHITECTURE.md, SPEC_INDEX.md, TASKS.md read every session so the agent never re-discovers what's been built. Incremental verifiable progress — TASKS.md breaks the build into single verifiable tasks. Drift prevention — DECISIONS.md created ready to log from the first task forward.

Two audiences. Two file types.

Human-facing — open this:

• vibe/TASKS.md — your single progress view. Plain English. Updated after every task.

Agent-facing — agent reads these, you never need to open them:

• CLAUDE.md · vibe/ARCHITECTURE.md · vibe/CODEBASE.md
• vibe/SPEC.md · vibe/SPEC_INDEX.md · vibe/PLAN.md · vibe/DECISIONS.md
• vibe/IMPLEMENTATION_LOG.md — agent: append-only implementation-decision log (why-this-approach / why-this-library)
• vibe/DESIGN_SYSTEM.md (created by design: — agent reads for design context)
• vibe/reviews/ · vibe/features/ · vibe/bugs/ · vibe/backlog/

Folder structure this skill creates

your-project/
├── BRIEF.md                   ← brainstorm output (if exists)
├── CLAUDE.md                  ← agent rules — auto-read by Claude Code
└── vibe/
    ├── TASKS.md               ← YOUR progress view — only file you open
    ├── ARCHITECTURE.md        ← agent: patterns, read every session
    ├── CODEBASE.md            ← agent: live codebase snapshot
    ├── SPEC.md                ← agent: full requirements
    ├── SPEC_INDEX.md          ← agent: compressed spec map
    ├── PLAN.md                ← agent: phases and architecture
    ├── DECISIONS.md           ← agent: spec/scope drift and change log (append-only)
    ├── IMPLEMENTATION_LOG.md  ← agent: implementation-decision log — why-this-approach (append-only)
    ├── DESIGN_SYSTEM.md       ← agent: design tokens (created by design:)
    ├── reviews/
    │   └── backlog.md
    ├── features/
    ├── bugs/
    └── backlog/

Note: vibe/DESIGN_SYSTEM.md is not created here — it is generated the first time design: runs. The agent checks for it at session startup and reads it if it exists.

Step 1 — Capture the idea and check for existing files

Run the parity check first. Read references/PIPELINE.md and follow its parity check: classify UI vs non-UI, detect the pipeline stage, and route to any missing upstream step. In particular:

• If BRIEF.md is missing, empty, or in a foreign shape (an idea pasted or

dropped from elsewhere, e.g. the Claude desktop app): route to brainstorm: first — its Step 0 ingests and normalizes external input into a canonical BRIEF.md. This is what brings an externally-produced idea to parity. Don't scaffold from a hollow or non-canonical brief.

• Note whether this is a UI project — it determines the design gate in Step 10C.

Then check for BRIEF.md and ARCHITECTURE.md at project root.

Both exist (ran brainstorm: and architect: — recommended path):

• Read both fully before doing anything else
• Confirm: "Found brief and architecture. [App name] — [core value]. [N] decisions locked. Building from these — no repeated questions."
• Pre-populate Steps 2–5 from BRIEF.md. Use ARCHITECTURE.md for PLAN.md folder structure and CLAUDE.md conventions.
• Skip all answered questions. Surface open questions from the brief.

Only BRIEF.md exists (ran brainstorm: but not architect:):

• Read BRIEF.md fully
• Confirm: "Found brief. [App name] — [core value]. [N] decisions locked."
• Pre-populate Steps 2–5. Skip answered questions.
• Note: architect: was skipped — minimal ARCHITECTURE.md will be generated from PLAN.md decisions in Step 9.

Neither exists (starting fresh — not recommended but supported):

• Extract: what the app does, who uses it, the core value.
• If unclear, ask the few genuinely-needed clarifying questions together (batched,

not one at a time) — but only what you actually need to proceed.

• Confirm: "Got it — building [X] for [who], core value: [Y]. Starting spec."
• Note: both BRIEF.md and ARCHITECTURE.md will be absent — minimal versions generated.

Step 2 — Generate vibe/SPEC.md

Draft SPEC.md covering:

1. Overview — What this app does and why (2-3 sentences)
2. Target users — Who uses this and what they need
3. Core features — Each feature with acceptance criteria
4. Out of scope — Explicitly NOT in v1
5. Tech stack — Confirmed choices with reasoning
6. Data model — Key entities and relationships
7. API shape — Core endpoints (if applicable)
8. Non-functional requirements — Performance, security, responsiveness
9. Conformance checklist — What must be true for v1 to be done

Present draft. Ask: "Does this spec look right? Anything to add, change, or cut?" Wait for approval. Save as vibe/SPEC.md.

Living document rules:

• Edit in-place on scope changes (via change: only — never informally)
• ~~Strikethrough~~ for removed items — never delete
• Update note at top: > ⚠️ Last updated: [date] · [reason]
• SPEC.md and SPEC_INDEX.md always updated as a pair — never one without the other

Step 3 — UI Design

Requires: frontend-design skill. If not installed, proceed with prose wireframe description.

If `DESIGN.md` (project root) or `vibe/design/CONTRACT.md` already exists (the user ran design-md: / design: first), read it and treat its tokens as authoritative — the wireframe must use those colours/type/spacing rather than inventing a new aesthetic. DESIGN.md wins where it and DESIGN_SYSTEM.md conflict.

Tell the user: "Before planning the build phases, let's lock the UI."

Ask all at once:

1. Screens — How many screens/views? List briefly.
2. Primary screen — Where do users spend most time?
3. Layout & nav — Preferences? (sidebar, bottom nav, top nav — or no preference)
4. Device — Desktop only, mobile first, or both?
5. Interactions — Anything complex? (drag-drop, real-time, multi-step)
6. References — Any apps whose UI you like?
7. Constraints — Component library already chosen? Anything must show above fold?

Wait for answers. Generate wireframe using frontend-design skill principles:

• Commit to a bold, intentional aesthetic based on the app's purpose
• Complete HTML wireframe artifact covering all screens
• Realistic placeholder content — not Lorem ipsum
• Show navigation between screens

Present wireframe. Iterate until approved. Append UI Specification to vibe/SPEC.md:

## UI Specification
### Design direction
[One sentence: aesthetic direction and why]
### Component library
[What's being used, or "none specified"]
### Navigation structure
[Top-level destinations and flow — locked here, expensive to change mid-build]
### Screens
#### [Screen name]
- **Purpose**: [What the user does here]
- **Layout**: [Describe]
- **Key components**: [List]
- **User interactions**: [What the user can do]
- **States**: [Empty, loading, error states]
### Responsive behaviour
[Desktop/mobile approach]

Tell the user: "UI spec locked. Moving to planning."

Step 4 — Generate vibe/SPEC_INDEX.md

Read vibe/SPEC.md in full. Generate SPEC_INDEX.md — compressed map under 40 lines:

# SPEC_INDEX — [Project Name]
> Compressed map of SPEC.md. Read each session. Fetch only the section you need.
> Last synced: [date]
## Overview — [one sentence] → SPEC.md#overview
## Features — [Feature]: [one sentence] (N criteria) → SPEC.md#feature-name
## UI — [N screens, direction summary] → SPEC.md#ui-specification
## Boundaries — Out of scope: [N items] → SPEC.md#out-of-scope
## Technical — Stack: [key choices] · Data: [N entities] · API: [N endpoints]
## Done condition — Conformance: [N items] → SPEC.md#conformance-checklist
## Backlog — [N items deferred] → vibe/backlog/

Save as vibe/SPEC_INDEX.md. Rule: SPEC.md and SPEC_INDEX.md always committed together. Never one without the other.

Step 5 — Generate vibe/PLAN.md

Read references/PLAN_MD.md for the full template. Read vibe/SPEC.md in full. Read ARCHITECTURE.md if it exists. Read BRIEF.md — specifically: feature list, non-goals, complexity estimate.

The critical section is the Feature Map (Section 6). This is the complete build plan — every feature, every phase, fully sequenced. It is not a list of slugs. It is not deferred to later. It is planned now, before Phase 1 begins.

Step 5A — Draft Sections 1–5 (structure, stack, architecture, data model, API):

These are standard — fill from SPEC.md and ARCHITECTURE.md. Identify shared data now: which tables/entities will be read or written by multiple features. List them explicitly in Section 4 "Shared data" table. This is the most common source of inter-feature conflicts caught too late.

Step 5B — Build the Feature Map (Section 6) — the most important step:

🧠 Effort: sequencing features by dependency is the reasoning that every later build wave and parallel dispatch relies on. Run it at high/xhigh effort with adaptive thinking — get the dependency ordering and shared-data analysis right here, because errors propagate through the whole build.

Read vibe/SPEC.md features section. Read BRIEF.md feature list and non-goals.

For every v1 feature, determine:

1. Build order — which features have no dependencies (start here),

which need another feature's data model first, which can run in parallel.

Ask yourself for each feature:

• Does this feature READ data created by another feature?

→ It depends on that feature. Build that one first.

• Does this feature WRITE data that another feature reads?

→ It must come before that feature.

• Do two features share NO data writes and have the same dependencies?

→ They can run in parallel. Mark both explicitly.

1. Shared data — which entities/tables are created by one feature

and consumed by another. These are the inter-feature dependency points that cause mid-build surprises if not planned now.

1. Future phase sketch — for Phase 4+ features from BRIEF.md backlog:

note what Phase 1-3 must NOT hard-code to keep them possible. This prevents architectural decisions that feel fine now but block v2.

Build the dependency diagram:

Phase 1 complete
    ↓
[Feature with no deps — can start immediately after Phase 1]
    ↓              ↓
[Next feature]  [Parallel feature — no shared writes]
    ↓
[Feature that needs both above]

If the dependency order is unclear — ask the user ONE focused question:

"Does [Feature B] need [Feature A]'s [entity] to exist first, or can they be built independently?"

Step 5C — Present the feature map for approval:

"Here's the complete build plan — all phases mapped out before we start.

>

[Present the feature map — Phase 1, Phase 2 ordered features with deps, Phase 3 tasks, Phase 4+ sketch if applicable]

>

Build order for Phase 2: [ASCII dependency diagram]

>

Parallel opportunities: [list features that can run simultaneously] Shared data points: [list entities that cross feature boundaries]

>

Does this sequencing look right? Any features that should move earlier or later?"

Wait for approval. Adjust if needed.

Step 5D — Save as `vibe/PLAN.md`.

The feature map in PLAN.md is the source of truth for:

• TASKS.md Phase 2+ section (generated from it in Step 7)
• vibe-add-feature (reads it before drafting each feature spec)
• vibe-change-spec (reads it to assess phase impact of scope changes)
• vibe-parallel (reads dependency diagram for wave planning)

Step 6 — Generate CLAUDE.md (project root)

Read vibe/SPEC.md, vibe/PLAN.md, vibe/ARCHITECTURE.md (if exists). Read references/CLAUDE_MD.md for the full template.

Generate CLAUDE.md at project root substituting all [placeholders]:

• Project overview from SPEC.md
• Tech stack from PLAN.md
• Commands from chosen stack
• Code style and naming from ARCHITECTURE.md (if exists) or PLAN.md
• Phase gates section — mandatory review gates baked in from day one
• Execution mode section — the three settings as resolved now by

python3 ~/.claude/skills/vibe-mode/scripts/vibe_state.py mode (never hardcode manual: a driver may have set VIBE_MODE=autonomous in the environment)

• Session completion checklist — the 10-step post-task sequence (full checklist from template)
• CLAUDE.md active feature sections — cleanup rule included

The per-task "next" sequence must be included verbatim in CLAUDE.md:

## Per-task sequence (runs on every "next")

1. Verify acceptance criteria in FEATURE_TASKS.md are all ticked
2. Run tests: `[test command]` — must pass before commit
3. Run lint: `[lint command] --silent` — must pass before commit
4. Commit code changes — stage the files THIS task touched, not `git add -A`
   (blanket-staging risks committing .env, build artifacts, or stray files;
   ensure .gitignore covers .env*, node_modules, build output first):
   git add [the specific paths this task created/modified]
   git commit -m "feat([scope]): [TASK-ID] — [one line plain English description]"
5. If this task made a MEANINGFUL implementation decision (hard to reverse · picked
   among real alternatives — a library/pattern/data-model/API shape · would surprise a
   future reader · deviates from ARCHITECTURE.md), append one entry to
   vibe/IMPLEMENTATION_LOG.md per the schema in that file's header (newest last; set
   Touches: to the files/functions changed). Routine work needs no entry — don't add noise.
6. Commit doc updates separately:
   git add vibe/TASKS.md vibe/DECISIONS.md vibe/IMPLEMENTATION_LOG.md vibe/CODEBASE.md
   git commit -m "docs(TASKS): mark [TASK-ID] done — [plain English]"
7. Update "What just happened" and "What's next" in vibe/TASKS.md
8. Re-read vibe/TASKS.md silently
9. State next task in plain English and confirm before starting

Rules:
- NEVER skip the commit step — uncommitted work is invisible to vibe-graph and vibe-review
- Code commit and doc commit are ALWAYS separate — never mix feat and docs in one commit
- If tests fail — fix before committing, do not commit broken code
- If lint fails — fix before committing, do not commit with lint errors

Investigation discipline (include verbatim):

## Investigation discipline
For requests under 10 words: restate intent in one sentence before reading any files.
Data/state operations (reset, clear, seed, refresh) are not code bugs — do not investigate code.
Confirm the actual request before opening any file.

Save as CLAUDE.md at project root.

Step 7 — Generate vibe/TASKS.md

Read references/TASKS_MD.md for full template and update rules. Read vibe/SPEC.md, vibe/SPEC_INDEX.md, vibe/PLAN.md — especially Section 6 (Feature Map).

Generate TASKS.md with every phase fully represented:

Header section:

# TASKS — [Project Name]
> [2-3 plain English sentences: what this app does, who it's for, core value]
> One file to watch. Updated after every task.

Phase 1 — Foundation: Each task as a checkbox with one plain English line.

## Phase 1 — Foundation
> No user-facing features. Sets up everything Phase 2 depends on.
> Phase 1 exit: run `review: phase 1` when all tasks complete.

[ ] P1-001 · [Task] — [one plain English line]
[ ] P1-002 · [Task] — [one plain English line]
...
[ ] P1-00N · Populate CODEBASE.md — document everything built in Phase 1

## Phase 1 gate
⬜ review: phase 1 — pending

## Design gate (UI projects)
⬜ design: — pending · UI features in Phase 2 need a design language first
   (run `design-md:` then `design:`, or `design:` alone). Skip only for non-UI.

Phase 2 — Core features (fully ordered from PLAN.md feature map):

This is the critical change. Phase 2 is not slugs — it is the complete ordered feature list with dependencies visible, derived from PLAN.md Section 6.

## Phase 2 — Core features
> Build order is deliberate. Features are sequenced by dependency.
> A feature marked [needs: X] cannot start until X is complete.
> Features marked [parallel with: X] can run simultaneously with X.
> Phase 2 exit: run `review: phase 2` when all features complete.

⬜ [Feature 1 name] — [what the user can do when this is done]
   Build order: 1 · No dependencies · Start here after Phase 1 gate passes
   Shared data: creates [Entity] used by Feature 2 and Feature 3
   Estimate: ~[N] hours
   Spec: run `feature: [name]` to plan this feature in detail

⬜ [Feature 2 name] — [what the user can do]
   Build order: 2 · Needs: Feature 1 complete
   Reason: reads [Entity] created by Feature 1
   Parallel with: Feature 3 (no shared writes)
   Estimate: ~[N] hours
   Spec: run `feature: [name]` to plan this feature in detail

⬜ [Feature 3 name] — [what the user can do]
   Build order: 2 · Needs: Feature 1 complete
   Parallel with: Feature 2 (no shared writes)
   Estimate: ~[N] hours
   Spec: run `feature: [name]` to plan this feature in detail

⬜ [Feature 4 name] — [what the user can do]
   Build order: 3 · Needs: Feature 2 + Feature 3 complete
   Reason: reads [Entity] from Feature 2 and [Entity] from Feature 3
   Estimate: ~[N] hours
   Spec: run `feature: [name]` to plan this feature in detail

## Phase 2 gate
⬜ review: phase 2 — pending

Phase 3 — Polish and hardening:

## Phase 3 — Polish and hardening
> Runs after Phase 2 gate passes. No new features.
> Phase 3 exit: run `review: final` — 0 P0 + 0 P1 before deploy.

⬜ Performance audit — profile and fix slow paths
⬜ Error handling pass — all edge cases, empty states, error boundaries
⬜ Accessibility audit — WCAG AA for all screens
⬜ E2E tests — critical user flows automated
⬜ Security review — auth, input validation, secrets, dependencies
⬜ Documentation — README, API docs, deployment guide

## Final gate
⬜ review: final — pending

Phase 4+ (if in PLAN.md — future phases sketched):

## Phase 4+ — Future (not in current build)
> Planned so Phase 1-3 architecture doesn't foreclose these.
> Run `brainstorm:` when ready to plan the next version.

⬜ [Future feature] — [one sentence] · planned for v2
⬜ [Future feature] — [one sentence] · planned for v2

Footer:

---
## What just happened
[Project name] project kit created. Phase 1 ready to begin.

## What's next
⬜ P1-001 · [First Phase 1 task in plain English]
Start Phase 1: read CLAUDE.md then vibe/TASKS.md. Say "next" for each task.
Run `review: phase 1` when all Phase 1 tasks are complete.

Non-negotiable rules:

• Build order and dependency reasons visible for every Phase 2+ feature
• feature: [name] trigger visible on every planned feature — user knows exactly what to run
• Phase gate instruction visible at end of each phase
• Plain English everywhere — what the user sees/experiences, not technical details
• Human should never need to open PLAN.md to know what to build next or in what order

Save as vibe/TASKS.md.

Step 8 — Generate vibe/CODEBASE.md (placeholder)

Read references/CODEBASE_MD.md for the full template.

For a new app, CODEBASE.md starts as a placeholder. The last task in Phase 1 populates it fully from the scaffolded project.

Generate the placeholder version. Save as vibe/CODEBASE.md.

Step 9 — Generate remaining vibe/ files and handle ARCHITECTURE.md

vibe/DECISIONS.md

# DECISIONS — [Project Name]
> Append-only. Every drift, scope change, tech choice — logged with full context.

## Decision types
- drift — deviated from PLAN.md or ARCHITECTURE.md
- blocker-resolution — impossible; workaround found
- tech-choice — chose between valid approaches not in plan
- scope-change — added/removed via change: command
- discovery — unexpected finding affecting future tasks

## Format
### D-[ID] — [Short title]
- **Date**: · **Task**: [TASK-ID] · **Type**: [type]
- **What was planned**: · **What was done**: · **Why**: 
- **Alternatives considered**: · **Impact on other tasks**:
- **Approved by**: human | agent-autonomous

(No entries yet)

vibe/IMPLEMENTATION_LOG.md

Write this file from the canonical template in references/IMPLEMENTATION_LOG_MD.md (use the FILE TEMPLATE block there verbatim). It is the append-only implementation-decision log — code-altitude "why this approach, why this library" — the companion to DECISIONS.md (which stays at spec/scope altitude). It starts empty; the build skills append to it as meaningful decisions are made, and Touches: lines link each decision to vibe-graph nodes. Do not duplicate the schema here — the file's own header carries it.

vibe/reviews/ folder

Create vibe/reviews/backlog.md:

# Review Backlog
> P1/P2/P3 issues tracked across all phase reviews.
> P1 must resolve before deploy. Updated after every review.
## Outstanding P1 Issues
(none yet)
## Outstanding P2 Issues
(none yet)
## Resolved Issues
(none yet)

ARCHITECTURE.md handling

If ARCHITECTURE.md exists at project root: Move to vibe/ARCHITECTURE.md.

If ARCHITECTURE.md does not exist (architect: was skipped): Generate a minimal vibe/ARCHITECTURE.md from PLAN.md decisions:

• Extract the folder structure, naming conventions, and tech choices from PLAN.md
• Apply the O'Reilly Principles section verbatim from references/ARCHITECTURE_MD.md
• Mark it clearly: > ⚠️ Auto-generated from PLAN.md — architect: was not run.
• > Consider running architect: to make these decisions explicit and add missing sections.

This ensures review: has an ARCHITECTURE.md to check against from Phase 1.

Step 10 — Spec review gate

Before telling the user the kit is ready, announce and hand off to spec-review:

"vibe/ folder created. Running spec-review before first task..."

Invoke vibe-spec-review with:

• Trigger source: new-app
• Scope: SPEC.md + ARCHITECTURE.md + BRIEF.md + AGENT_ARCH.md (all that exist)

After spec-review completes:

Step 10B — Initialise dependency graph

Invoke vibe-graph: init.

This builds the spec graph from SPEC.md and ARCHITECTURE.md — all planned nodes created before any code is written. Nodes will transition from planned to built as features are implemented.

After graph init completes:

Step 10S — Record the spec sign-off

The spec gate is the person's sign-off on the plan the build will follow. Record it in vibe/.gates.json (and the ## Spec gate line in TASKS.md) with the helper — pass the spec-review report from Step 10 as --report:

VS="$HOME/.claude/skills/vibe-mode/scripts/vibe_state.py"
python3 "$VS" mode        # → vibe_mode, approvals

• Manual mode: the user approved the SPEC in Step 2 and has seen the spec review —

python3 "$VS" gate set spec --status approved --by human --report [report].

• Autonomous, `APPROVALS=auto`: gate set spec --status approved --by agent-autonomous --report [report], and continue.
• Autonomous, `APPROVALS=human`: gate set spec --status pending --report [report],

then STOP — python3 "$VS" run-state set --status needs_human --reason spec_approval --next "approve the spec, then run vibe-mode: run" — and end the session. Do not start the design or any task. vibe-mode: run resumes from here once the spec is approved (HEADLESS.md §5).

Step 10C — Design gate (UI projects)

Design is a required pipeline step for UI projects, not an afterthought (see references/PIPELINE.md). Do not let the build start UI features with no design language — that is the "it skipped design" failure.

• Non-UI project (API / CLI / library / pure backend): skip this step; note

"design gate N/A — no UI", record it with vibe_state.py gate set design --status na, and continue.

• UI project, no design system yet (DESIGN.md / vibe/DESIGN_SYSTEM.md /

vibe/design/CONTRACT.md all absent): announce and hand off —

"This is a UI project. Before building screens, let's lock the design so they share one derived design language. Optionally run design-md: first to capture brand tokens, then design: to produce the design contract. Recommended. Reply 'skip design' to build without a design pass."

Invoke design: on a clear yes; when the user approves the result, record gate set design --status approved --by human. If the user says skip, log it in vibe/DECISIONS.md ("design gate skipped by user") so it's a visible decision, and record gate set design --status skipped.

• Design system already exists (user ran design-md:/design: earlier):

design gate already passed — record gate set design --status approved --by human if it isn't recorded yet, and continue.

• Autonomous mode (UI project, no design system): never skip. Run design: up to its

Step 3.5 checkpoint (contract, tokens, preview — no production UI files before sign-off), then design: critique, then one design: fix must pass. Then per APPROVALS: auto → gate set design --status approved --by agent-autonomous --report vibe/design/critique.md and continue; human → gate set design --status pending --report vibe/design/critique.md, STOP with run-state set --status needs_human --reason design_approval --next "approve the design, then run vibe-mode: run", and end the session.

The generated TASKS.md carries a matching Design gate line before Phase 2 so this is visible in the human-facing plan.

After the design gate resolves:

Step 10D — Install the gate hard-lock (git pre-push hook)

The phase/deploy gates are enforced by flow + vibe/.gates.json (see vibe-review/references/GATES.md), but the only true machine-level lock is a git hook. Offer to install it:

"Install the gate hard-lock? It blocks git push while any review gate is open (P0 or P1 outstanding) — so quality gates hold even if a step is skipped. Override anytime with git push --no-verify. (y/n)"

If yes, write .git/hooks/pre-push (chmod +x) with the check from GATES.md (reads vibe/.gates.json; any open gate → exit 1). If the project uses husky, add it as a husky pre-push instead. If declined, note it — gates then rely on flow + state only. In autonomous mode, install it (the recommended option) and note it in DECISIONS.md.

Step 11 — Tell the user

🎉 Your project kit is ready.

>

One file to watch: vibe/TASKS.md

>

Structure created: `` CLAUDE.md vibe/TASKS.md ← open this vibe/ARCHITECTURE.md ← [locked from architect: / auto-generated from plan] vibe/CODEBASE.md ← placeholder until Phase 1 done vibe/SPEC.md + SPEC_INDEX.md + PLAN.md + DECISIONS.md vibe/IMPLEMENTATION_LOG.md ← implementation decisions logged as you build vibe/reviews/backlog.md vibe/spec-reviews/ ← spec review history vibe/graph/ ← dependency graph (spec graph initialised) `` Spec review: [✅ clean / ⚠️ [N] warnings acknowledged / 🔴 [N] P0s fixed] Graph: [N] planned nodes · [N] concepts mapped · updates automatically

>

Read execution mode: ``bash python3 ~/.claude/skills/vibe-mode/scripts/vibe_state.py mode ``

>

If autonomous → read the vibe-mode skill's references/AUTONOMOUS_EXECUTION_BLOCK.md (resolve the vibe-mode install dir — commonly ~/.claude/skills/vibe-mode/, or ~/.claude/plugins/marketplaces/*/skills/vibe-mode/ under a plugin install) and follow the autonomous execution protocol for Phase 1 tasks. Begin immediately. (If Step 10S or 10C stopped for an approval, the session has already ended — this step runs on the resumed session instead.)

>

If manual or not set → tell the user: `` Read CLAUDE.md, then vibe/CODEBASE.md, then vibe/ARCHITECTURE.md, then vibe/SPEC_INDEX.md, then vibe/TASKS.md. Confirm the first task before writing any code. `` Say "next" after each task. Run "review: phase 1" when Phase 1 completes — mandatory gate.