plan

name	plan
description	Run project intake questionnaire, apply decision engine, and generate a complete development plan with phased work orders. Use when the user says "make a plan", "break this down", "organize the work", "create a roadmap", or wants to structure their project into phases. Requires product discovery to be complete first.
argument-hint	[optional: path to project-definition.json]
allowed-tools	Read, Write, Glob, Grep, Bash, AskUserQuestion

/vibeos:plan — Project Planning & Intake

Turn validated product documents into a complete development plan with governance setup.

Communication Contract

Follow the full USER-COMMUNICATION-CONTRACT.md (docs/USER-COMMUNICATION-CONTRACT.md). Key rules:

• Lead with outcome, follow with mechanism
• Present decisions with consequences
• Introduce every concept on first use with plain English definition

Skill-specific addenda:

• Present inferred defaults as decisions with evidence, pros, cons, and a recommendation
• Before each question, briefly explain what you're asking and why it matters
• Explain in plain English first; add technical detail only when it helps the user understand the trade-off

Prerequisites

Before starting, verify these exist (from /vibeos:discover):

• project-definition.json in the project root
• docs/product/PRD.md
• docs/product/ARCHITECTURE-OUTLINE.md or docs/ARCHITECTURE.md
• docs/product/PRODUCT-ANCHOR.md
• docs/ENGINEERING-PRINCIPLES.md
• docs/research/RESEARCH-REGISTRY.md
• docs/decisions/DEVIATIONS.md

If any are missing, tell the user to run /vibeos:discover first.

Planning Flow

Step 1: Load Discovery Context

Read project-definition.json from the project root (or $ARGUMENTS path if provided).

Extract pre-filled values for:

• Project name, slug, description
• Product type, platforms
• Product promise, experience principles, non-negotiables
• Sensitive data, compliance targets
• Technical recommendation (language, framework, database)
• Governance profile (team size, risk level, deployment context)
• Engineering principles and research freshness policy

Tell the user what was found:

"I found your discovery outputs. Here's what I already know: [summary]. I'll use your product anchor and engineering principles as planning guardrails while I confirm the remaining details."

Step 1b: Midstream Detection (Architecture-First)

Check if the project has existing source code:

1. Look for source directories: src/, lib/, app/, pkg/, cmd/, internal/, server/, client/, api/, core/
2. Look for language indicators: package.json, requirements.txt, go.mod, Cargo.toml, pom.xml, build.gradle, *.csproj, Gemfile, composer.json, pyproject.toml, setup.py
3. Count source files (excluding test files, node_modules, vendor dirs, and generated files)

If existing code is found (midstream project):

Check if architecture documents exist (generated by /vibeos:discover midstream flow):

• docs/product/ARCHITECTURE-OUTLINE.md — the validated architecture document
• project-definition.json with inferred or confirmed values
• docs/product/PRODUCT-ANCHOR.md
• docs/ENGINEERING-PRINCIPLES.md

If architecture documents are missing:

Tell the user:

"I detected existing source code in this project, but I don't have an architecture document yet. Before I can create a meaningful development plan, I need to understand your codebase's architecture.

Run /vibeos:discover first — it will analyze your code, map the architecture, and ask you to validate what it finds. Then come back to /vibeos:plan."

Stop. Do not proceed with planning until architecture documents exist.

If architecture documents exist:

Tell the user:

"I found your architecture document from discovery. Your codebase has [architecture summary from ARCHITECTURE-OUTLINE.md]. I'll use this as the anchor for planning."

"I'll also use your Product Anchor and Engineering Principles so the plan protects both the intended experience and the quality bar."

Continue to Step 2. The guided codebase audit (running gates, dispatching audit agents, collecting findings with user decisions, and creating remediation WOs) is handled by the WO-042/043/044 pipeline during Step 2 and later steps — not in this detection step.

If no existing code (greenfield project):

Skip midstream flow. Continue to Step 2.

Step 1c: Guided Codebase Audit (Midstream Only)

If this is a midstream project (existing code with architecture documents from Step 1b), run a guided codebase audit before proceeding with planning:

1c-1. Run Comprehensive Audit

1. Run quality gates: Execute bash ".vibeos/scripts/gate-runner.sh" pre_commit --project-dir "${CLAUDE_PROJECT_DIR:-.}". If .claude/quality-gate-manifest.json does not exist yet (midstream projects that have never used VibeOS), generate a temporary gate manifest from project-definition.json stack info. If that's not possible, run only universal gates (secrets scan, placeholder check, stub detection) and note framework-specific gates as "skipped — manifest not yet generated."
2. Dispatch the audit agents (security, architecture, correctness, test, evidence, product-drift, flow, system-invariant, dependency-intelligence, delivery-infrastructure, red-team, contract-validator) following skills/audit/SKILL.md protocol. Use isolation: worktree for each agent.
3. Run language-specific dependency audit with graceful degradation — if the tool is not installed, skip and note it as "CVE audit skipped: [tool] not found":
   • Node.js: npm audit --json
   • Python: pip-audit --format json or safety check
   • Go: govulncheck ./...
   • Rust: cargo audit
   • Java: dependency-check or OWASP plugin
4. Assess test coverage: Count test files, map to source files, identify gaps.

1c-2. Categorize and Prioritize

Organize all findings into 5 categories, sorted by severity within each:

1. Security — secrets, injection, auth gaps, CVEs in dependencies
2. Architecture — layer violations, circular deps, boundary violations
3. Code Quality — complexity, dead code, error handling gaps, type safety
4. Dependencies — outdated packages, known CVEs, unpinned versions
5. Test Coverage — untested modules, low coverage areas, missing edge cases

1c-3. Guided Walkthrough

Present findings category by category. For each category:

Critical and high findings: Present individually with risk context and recommendation.

[Category] Audit Results

I found [N] [category]-related issues in your codebase:

Critical:

1. [title] in [file]:[line]
   • Risk: [plain English impact on business/users]
   • Recommendation: [what to do]
   • Your options:
     1. Fix now — resolve it before feature work continues.
        • Pros: removes the risk immediately
        • Cons: slows current progress
        • Technical note: this becomes Phase 0 remediation work
     2. Fix later — track it and continue for now.
        • Pros: keeps momentum on the current plan
        • Cons: the risk remains until scheduled later
        • Technical note: it stays in findings-registry.json and reminder flows
     3. Accept risk — keep it intentionally and document why.
        • Pros: fastest path when the trade-off is deliberate
        • Cons: the issue remains and becomes part of the audit record
        • Technical note: accepted risks become part of the baseline and audit trail
   • I recommend [option] because [specific reasoning based on severity, project risk, and user goals]

Medium and low findings: Summarize by pattern (not individually walked through).

Medium (tracked):

• [N] instances of [pattern description]
• [M] instances of [pattern description] These are tracked but won't block your development.

For accepted-risk dispositions, require justification:

"You chose to accept the risk of [finding]. Can you briefly explain why? This will be documented for audit trail purposes."

1c-4. Store Decisions

Write .vibeos/findings-registry.json — a formal schema contract consumed by downstream WOs (WO-043 for baselining, WO-044 for remediation).

Schema v1.0:

{
  "schema_version": "1.0",
  "audit_date": "ISO-8601",
  "architecture_doc": "docs/product/ARCHITECTURE-OUTLINE.md",
  "findings": [
    {
      "id": "SEC-001",
      "category": "security|architecture|code-quality|dependencies|test-coverage",
      "severity": "critical|high|medium|low",
      "title": "Hardcoded API key",
      "file": "src/config.py",
      "line": 42,
      "pattern": "hardcoded-secret",
      "description": "AWS API key hardcoded in source",
      "recommendation": "Move to environment variable",
      "disposition": "fix-now|fix-later|accepted-risk",
      "justification": "string|null (required if disposition is accepted-risk)",
      "agents": ["security-auditor", "correctness-auditor"],
      "consensus": "true-positive|warning",
      "baselined_at_wo": "string|null (set by WO-043 when finding is first baselined)"
    }
  ],
  "summary": {
    "total": 48,
    "by_severity": {"critical": 3, "high": 8, "medium": 15, "low": 22},
    "by_disposition": {"fix_now": 5, "fix_later": 12, "accepted_risk": 9},
    "gates_run": 12,
    "gates_skipped": 0,
    "cve_tools_skipped": ["(tool names if any were not installed)"]
  }
}

1c-5. Generate Report

Write .vibeos/midstream-report.md:

• Executive summary (1 paragraph plain English)
• Category-by-category findings with dispositions
• Fix-now items (will become Phase 0 remediation WOs via WO-044)
• Fix-later items (tracked, prioritized)
• Accepted risks (with justifications)
• Test coverage gap summary

Report to user:

"Audit complete. Here's the summary:

• [N] total findings: [critical] critical, [high] high, [medium] medium, [low] low
• Your decisions: [fix-now] fix now, [fix-later] fix later, [accepted-risk] accepted risk

The fix-now items will become Phase 0 remediation work orders in your development plan. Fix-later items are tracked and will be reminded periodically. Full report saved to .vibeos/midstream-report.md."

1c-6. Create Initial Baseline

Create the quality baseline from the findings registry. This establishes the "starting point" so future builds only flag new issues:

mkdir -p .vibeos/baselines
bash ".vibeos/convergence/baseline-check.sh" create \
  --mode finding-level \
  --baseline-file ".vibeos/baselines/midstream-baseline.json" \
  --current-findings-file ".vibeos/findings-registry.json"

Tell the user:

"I've established a quality baseline with [N] tracked findings. From now on, only new issues will be flagged — these existing ones are tracked and won't block your builds. Quality can only improve from here (a one-way ratchet — the count of known issues can go down but never up)."

Continue to Step 2.

Step 2: Run Project Intake Questionnaire

Run the 18-question intake from 4 rounds. Pre-fill from project-definition.json — only ask questions where the answer is missing, confidence is low, or impact is high enough to justify confirmation.

Round 1: Project Identity (Q1-Q4)

#	Question	Pre-fill Source
Q1	Project name	idea.name.value
Q2	Project slug (lowercase, hyphens)	Derive from Q1
Q3	One-line description	idea.summary.value
Q4	Repository URL (optional)	Ask if not set

Validate Q2 matches ^[a-z][a-z0-9-]*$.

Round 2: Technical Stack (Q5-Q10)

#	Question	Pre-fill Source
Q5	Primary language	technical_recommendation.language.value
Q6	Framework	technical_recommendation.framework.value
Q7	Source directories	Derive from language convention
Q8	Test directory	Derive from language convention
Q9	Package manager	Derive from language
Q10	Database	technical_recommendation.database.value

For each pre-filled answer with medium+ confidence, present it as a recommendation:

"I inferred [language] based on [plain-English evidence].

Your options:

1. Keep it — use [language] as the default.
   • Pros: faster and likely correct when the evidence is strong
   • Cons: could preserve a wrong assumption if your constraints changed
   • Technical note: this value affects framework, tooling, and generated work orders
2. Change it — pick a different value now.
   • Pros: gives you direct control over the stack
   • Cons: takes longer because downstream recommendations must change too
   • Technical note: changing this may affect gates, testing setup, and architecture rules

I recommend option [1 or 2] because [specific reasoning]."

For low-confidence or missing answers, ask the full question with options, pros/cons, and recommendation.

Framework options are filtered by language:

• python: fastapi, django, flask, none
• typescript: express, nestjs, nextjs, none
• javascript: express, nextjs, react-only, none
• go: gin, echo, chi, none
• rust: actix, axum, rocket, none
• java: spring-boot, quarkus, none

Round 3: Governance Profile (Q11-Q15)

#	Question	Pre-fill Source
Q11	Team size (solo/small/enterprise)	governance_profile.team_size.value
Q12	Compliance targets (soc2/gdpr/owasp/none)	constraints.compliance_targets
Q12b	Deployment context (prototype/production/customer-facing/scale)	governance_profile.deployment_context.value
Q13	Work order directory	Default: docs/planning/
Q14	Frozen files (never edit)	Ask
Q15	Production URLs (never target)	Ask

Solo compliance warning: If team_size is "solo" AND compliance targets are not "none":

"Running full compliance governance as a solo developer adds overhead.

Your options:

1. Keep tier 1 — full enforcement from the start.
   • Pros: strongest compliance posture
   • Cons: highest friction and most interruptions while building
   • Technical note: compliance gates stay blocking
2. Set tier 2 — important checks stay on, but they do not block work.
   • Pros: good balance of safety and speed
   • Cons: some compliance issues may wait until later to be fixed
   • Technical note: compliance gates remain enabled but non-blocking
3. Set tier 3 — advisory only.
   • Pros: lightest process overhead
   • Cons: weakest enforcement and easiest way to miss important issues
   • Technical note: compliance guidance becomes informational only

I recommend option 2 because it keeps the signals visible without overwhelming a solo developer."

Round 4: Agent Preferences (Q16-Q18)

#	Question	Pre-fill Source
Q16	Cloud provider (azure/aws/gcp/vercel/none)	Ask or infer
Q17	CI/CD platform (github-actions/gitlab-ci/azure-devops/none)	Ask or infer
Q18	MCP servers (comma-separated or none)	Ask

Drift Guardrail Confirmation

Before finalizing the plan, confirm that the anchors still look right:

• Does docs/product/PRODUCT-ANCHOR.md still describe the product you actually want?
• Does docs/ENGINEERING-PRINCIPLES.md still reflect how strict the build should be?
• Should any existing entry in docs/decisions/DEVIATIONS.md expire, be revised, or be added now?

If the user changes any of these, update the corresponding files before generating work orders.

Step 3: Validate and Confirm

After all answers are collected, validate:

1. project.name is not empty
2. project.slug matches ^[a-z][a-z0-9-]*$
3. stack.language is in [python, typescript, javascript, go, rust, java]
4. stack.source_dirs — warn if directories don't exist yet
5. governance.team_size is in [solo, small, enterprise]
6. governance.compliance_targets is a non-empty list
7. governance.deployment_context is in [prototype, production, customer-facing, scale]

Present a complete summary showing each field and its source (user-confirmed, inferred from discovery, or defaulted). Ask:

"Does this look correct? [Y/n]"

If the user says no, ask what to change, update, re-validate.

Write the final answers to project-definition.json in the project root, merging with existing discovery data. Use the full answer schema:

{
  "project": { "name": "", "slug": "", "description": "", "repo_url": "" },
  "stack": { "language": "", "framework": "", "source_dirs": [], "test_dir": "", "package_manager": "", "database": "" },
  "governance": { "team_size": "", "compliance_targets": [], "deployment_context": "", "wo_dir": "", "frozen_files": [], "production_urls": [] },
  "agent": { "cloud_provider": "", "ci_cd_platform": "", "mcp_servers": [] },
  "anchors": {
    "product_promise": "",
    "experience_principles": [],
    "non_negotiables": [],
    "engineering_principles": [],
    "research_freshness_policy": ""
  }
}

Step 4: Apply Decision Engine

Read and apply the 5 decision engine trees from .vibeos/decision-engine/:

4a. Gate Selection (gate-selection.md)

Determine which of the gate scripts to enable based on:

• stack.language and stack.database
• governance.compliance_targets
• governance.production_urls
• governance.deployment_context
• whether anchor and research documents should be enforced at WO entry/completion

Produces: list of enabled gates with tier, blocking status, and config.

Explain to user:

"I've configured [N] quality gates based on your project profile ([language], [deployment context]):

• Always on: [list of tier-0 gates] — these catch critical issues like secrets and security vulnerabilities
• Enabled for your stack: [list of stack-specific gates] — [brief reason each is relevant]
• [If compliance]: [M] gates are required by your [compliance target] and cannot be disabled
• Advisory only: [list of tier-2+ gates] — these flag issues but won't block your builds
• Anchor protection: work orders must stay aligned with your Product Anchor, Engineering Principles, and research freshness requirements

You can manage gates anytime with /vibeos:gate list, /vibeos:gate enable <name>, or /vibeos:gate disable <name>."

4b. Phase Selection (phase-selection.md)

Determine which gate phases to enable based on:

• governance.team_size
• governance.compliance_targets
• governance.production_urls

Produces: list of enabled phases with gate assignments.

Explain to user:

"Quality checks run at [N] points during development:

• Before each commit (pre_commit): [N] fast checks — catches issues before code is saved
• Before completing a WO (wo_exit): [N] checks — validates the work meets requirements
• [If enabled] Full audit (full_audit): [N] deep checks — comprehensive compliance review
• [If enabled] After deployment (post_deploy): smoke tests and health checks

This was selected because [reason based on team size and deployment context]."

4c. Hook Selection (hook-selection.md)

Determine which hooks to enable based on:

• Agent type (claude-code for this plugin)
• governance.production_urls
• governance.frozen_files
• governance.compliance_targets

Produces: list of enabled hooks with config.

Explain to user:

"I've enabled [N] safety hooks that run automatically:

• Secrets scan — blocks any code containing API keys, passwords, or tokens
• Test file protection — prevents implementation agents from modifying your tests (TDD enforcement)
• [If frozen files] Frozen files — protects [list] from accidental modification
• [If production URLs] Production URL guard — prevents targeting your live systems

These run silently in the background and only interrupt you if they catch something."

4d. Architecture Rules (architecture-rules.md)

Select architecture enforcement rules based on:

• stack.language
• stack.framework
• stack.source_dirs

Produces: architecture-rules.json with framework-specific rules.

Explain to user:

"Architecture rules enforce your project structure:

• [For each rule]: [rule name] — [plain English: what it prevents and why]

These are based on [framework] best practices and prevent common structural mistakes like [example]."

4f. Drift Guardrails

Before generating WOs, make sure the plan explicitly uses:

• docs/product/PRODUCT-ANCHOR.md for product promise and experience principles
• docs/ENGINEERING-PRINCIPLES.md for quality bar and anti-shortcut rules
• docs/research/RESEARCH-REGISTRY.md for current-evidence requirements
• docs/decisions/DEVIATIONS.md for deliberate trade-offs

Every WO should inherit those guardrails, not invent its own.

4e. Compliance Mapping (compliance-mapping.md)

Map compliance targets to gate tiers, evidence requirements, and documentation:

• SOC 2: evidence bundles, audit completeness
• GDPR: PII handling, tenant isolation
• OWASP: security patterns strict mode
• Combined: union of all rules

Produces: tier overrides and compliance-specific configuration.

Explain to user:

"[If compliance targets exist]: Your [compliance targets] require:

• [N] gates elevated to blocking (must pass before committing)
• [Evidence requirements in plain English]
• [Documentation requirements in plain English]

These ensure your project stays audit-ready from day one."

[If no compliance]: "No compliance targets set. Gates use standard tiers based on your deployment context."

Summary to user:

"Here's your complete governance setup:

• [N] quality gates ([B] blocking, [A] advisory) — run /vibeos:gate list to see them all
• [M] gate phases — checks run before commits, WO completion[, and deployment]
• [K] hooks — automatic safety enforcement in the background
• [R] architecture rules — structural enforcement for [framework] [If compliance]: - [compliance targets] compliance — [N] gates mandatory, evidence required"

Step 5: Generate Development Plan

Read .vibeos/decision-engine/development-plan-generation.md for the plan structure.

Read .vibeos/reference/governance/DEVELOPMENT-PLAN.md.ref for the output template.

Generate docs/planning/DEVELOPMENT-PLAN.md with:

If midstream project with findings (.vibeos/findings-registry.json exists):

0. Phase 0: Remediation — generated from findings dispositions:
   • Read .vibeos/findings-registry.json
   • Create one WO per critical fix-now finding (high priority, specific scope)
   • Group related high fix-now findings into WOs (e.g., all auth issues in one WO)
   • Each remediation WO links to its finding ID and includes verification criteria
   • Create fix-later WOs with lower priority (not blocking Phase 1, tracked in parallel)
   • Generate docs/planning/ACCEPTED-RISKS.md with all accepted-risk findings, justifications, date, and risk level
   • Generate docs/planning/REMEDIATION-ROADMAP.md with timeline and dependencies

Phase 0 must complete before Phase 1 begins (enforced by build skill).

1. Phase 1: Foundation — scaffold, shared packages, database, auth, config baseline
2. Phase 2..N: Core Workflows — etc.

If greenfield project (no findings):

1. Phase 1: Foundation — scaffold, shared packages, database, auth, config baseline
2. Phase 2..N: Core Workflows — one phase per scope.core_workflows from project-definition.json, ordered by dependencies and critical path
3. Phase N+1..: V1 Features — remaining features from scope.v1_features
4. Conditional production phases based on governance.deployment_context:
   • IF production+: Security headers, health probes, structured logging, input validation
   • IF customer-facing+: Observability, resilience, security hardening

Each WO in the plan must have:

• WO number
• Title
• Dependencies (other WO numbers)
• Status (Draft)
• Objective
• Acceptance criteria

Order WOs so dependencies complete before dependents. Typical WO size: one feature area or one integration.

Step 5b: Generate Audit Governance Docs

Read:

• .vibeos/reference/governance/AGENTS.md.ref
• .vibeos/reference/governance/AUDIT-PROTOCOL.md.ref
• .vibeos/reference/governance/AGENT-WORKFLOW.md.ref

Generate:

• AGENTS.md
• docs/planning/AUDIT-PROTOCOL.md
• docs/planning/AGENT-WORKFLOW.md

These documents must align with the generated work-order flow, gate phases, and any companion-agent surfaces installed in the repo.

Step 6: Generate WO Index

Read .vibeos/reference/governance/WO-INDEX.md.ref for the template.

Generate docs/planning/WO-INDEX.md with all WOs listed, organized by phase, with columns:

• WO Number
• Title
• Phase
• Dependencies
• Status

Step 7: Mechanical Setup

7a. Create Project Directory Structure

Create the standard directories based on stack:

• {source_dirs} from intake
• {test_dir} from intake
• {wo_dir} from intake (default: docs/planning/)
• docs/ for documentation
• .claude/ for Claude Code configuration

7b. Generate Gate Manifest

Create .claude/quality-gate-manifest.json in the target project with the gate selection results:

{
  "gates": [
    { "script": "filename.sh", "tier": 0, "blocking": true, "phase": "pre_commit", "config": {} }
  ],
  "phases": { "phase_name": { "gates": [], "enabled": true } }
}

7c. Generate Hook Manifest

Create .claude/hook-manifest.json in the target project with hook selection results:

{
  "hooks": [
    { "name": "hook-name", "event": "PreToolUse", "config": {} }
  ]
}

7d. Generate Architecture Rules

Create scripts/architecture-rules.json in the target project with the rules from Step 4d.

7e. Copy Gate Scripts

Copy gate scripts from .vibeos/scripts/ to the target project's scripts/ directory.

7f. Install Git Pre-Commit Hook

Run setup-git-hooks.sh to install a git pre-commit hook that runs quality gates before each commit:

bash ".vibeos/scripts/setup-git-hooks.sh" --project-dir "${CLAUDE_PROJECT_DIR:-.}"

This ensures local commits cannot bypass quality gates. The hook auto-detects the gate runner location and runs pre_commit phase gates.

7g. Generate CLAUDE.md

Generate the target project's instruction surfaces:

• AGENTS.md as the shared repo contract
• CLAUDE.md as a thin entry loader
• .claude/CLAUDE.md as the Claude-specific runtime layer
• .claude/rules/always/*.md from the reference rules that apply to this project

The generated surfaces must point to:

• docs/planning/AUDIT-PROTOCOL.md
• docs/planning/AGENT-WORKFLOW.md
• .claude/quality-gate-manifest.json

Step 8: Autonomy Negotiation

After the plan is generated and setup is complete, negotiate how much control the user wants to retain during autonomous build.

Present three options in plain English:

"Before we start building, I want to understand how you'd like to work together. Here are three modes:"

Option A — Stop after every work order (most control):

"I'll build one thing at a time and check in with you after each piece. For example, after building your user authentication, I'll show you what was built, what tests pass, and ask before moving to the next feature. You'll review about [N] check-ins for this project. Best if this is your first time using VibeOS or you want to stay closely involved."

• Pros: maximum visibility and easiest course-correction
• Cons: slowest overall pace because there are more pauses
• Technical note: autonomy level wo

Option B — Stop after every phase (recommended):

"I'll build a complete group of related features, then check in. For example, I'll build all of Phase 1 (project scaffolding, database, auth) in one go, then show you the result before starting Phase 2. You'll review about [P] check-ins for this project. Good balance of speed and oversight."

• Pros: balanced oversight without too many interruptions
• Cons: less frequent review than work-order mode
• Technical note: autonomy level phase

Option C — Stop at major decisions only (most autonomous):

"I'll build continuously and only pause when I hit something that needs your input — like a design choice, an unexpected problem, or a security decision. This is the fastest option but you'll see less intermediate work. I'll still run all quality checks and audits automatically. If something breaks, I'll pause and ask."

• Pros: fastest path and lowest interaction cost
• Cons: least visibility into intermediate progress
• Technical note: autonomy level major

Make a recommendation:

"I recommend Option B (stop after every phase) for this project because [reason based on project complexity, team size, and risk level]. You can change this anytime by saying 'change autonomy level' during a check-in."

Also explain:

"If you later want me to stop routine check-ins and just keep building until I hit a real blocker, you can use /vibeos:autonomous as a temporary full-autonomous session override. For deliberate 24-48 hour runs, VibeOS uses long-run autonomy: heartbeat files, checkpoints, audit cadence, stale-run detection, and closeout validation so the run can resume safely if the runtime is interrupted."

Store the selection in .vibeos/config.json:

{
  "autonomy": {
    "level": "wo|phase|major",
    "negotiated_at": "ISO-8601 timestamp"
  }
}

Create the .vibeos/ directory if it doesn't exist.

Step 9: Gate Readiness

Before completing, verify all outputs exist:

• project-definition.json updated with full intake answers
• docs/planning/DEVELOPMENT-PLAN.md generated with phases and WOs
• docs/planning/WO-INDEX.md generated with all WOs
• docs/planning/AUDIT-PROTOCOL.md generated
• docs/planning/AGENT-WORKFLOW.md generated
• .claude/quality-gate-manifest.json generated
• .claude/hook-manifest.json generated
• scripts/architecture-rules.json generated
• Gate scripts copied
• Project directories created
• AGENTS.md, CLAUDE.md, and .claude/CLAUDE.md generated for target project
• .vibeos/config.json created with autonomy selection

Report the result:

"Planning is complete. Here's your development plan:

• [N] phases with [M] work orders
• [K] quality gates configured ([B] blocking) — manage with /vibeos:gate list
• [H] hooks enabled
• Governance profile: [team_size], [compliance], [deployment_context]

Your first work order is WO-[NNN]: [title] — [1-sentence description of what it builds].

Run /vibeos:build to start. I'll write tests first, then implement the code, run [K] quality checks, and have independent auditors review the result, including red-team, product-drift, flow-integrity, system-invariant, dependency-intelligence, and delivery-infrastructure checks. I'll check in after each [work order/phase] based on your autonomy preference ([level]).

Use /vibeos:status anytime for the tactical session view, /vibeos:project-status for the overall project briefing, or /vibeos:gate list to review your quality gates."

If any gate fails, explain what's missing and offer to fix it.

Output Summary

Artifact	Path	Purpose
project-definition.json	project root	Updated with full intake answers
DEVELOPMENT-PLAN.md	docs/planning/	Phased work orders
WO-INDEX.md	docs/planning/	Work order tracking
AUDIT-PROTOCOL.md	docs/planning/	Audit layers and trigger rules
AGENT-WORKFLOW.md	docs/planning/	Role separation and handoff rules
quality-gate-manifest.json	.claude/	Gate configuration
hook-manifest.json	.claude/	Hook configuration
architecture-rules.json	scripts/	Architecture enforcement rules
Gate scripts	scripts/	Quality gate scripts
AGENTS.md	project root	Shared repo contract
CLAUDE.md	project root	Thin Claude entry loader
.claude/CLAUDE.md	.claude/	Claude-specific runtime instructions
config.json	.vibeos/	Autonomy configuration