Runtime Mode

interactive_governed

Default and effective mode.

Use this when the system should still ask the user high-value questions, confirm frozen requirements, and pause at plan approval boundaries.

benchmark_autonomous

Legacy compatibility alias only.

If older callers still pass benchmark_autonomous, the runtime silently normalizes it to interactive_governed. It is not a separate execution plane and it must not create a second unattended control path.

Internal Execution Grades

M, L, and XL remain active, but only as internal orchestration grades.

• M: narrow execution, single-agent or tightly scoped work
• L: design or coordination work that needs staged planning and review
• XL: parallelizable or long-running work that benefits from agent teams and wave control

The governed runtime selects the internal grade after deep_interview and before plan_execute.

User-facing behavior stays the same regardless of host syntax:

• one governed entry
• one frozen requirement surface
• one XL-style plan surface
• one execution and cleanup contract

Compatibility notes for downstream verification and host adapters:

• M=single-agent
• L grade always follows: design → plan → user approval → subagent execution → two-stage review.
• XL native lifecycle APIs remain spawn_agent/send_input/wait/close_agent

Stage Contract

1. skeleton_check

Check repo shape, active branch, existing plan or requirement artifacts, and runtime prerequisites before starting.

2. deep_interview

Produce a structured intent contract containing:

• goal
• deliverable
• constraints
• acceptance criteria
• non-goals
• autonomy mode
• inferred assumptions

In interactive_governed, this stage may ask direct questions. Legacy benchmark_autonomous input is normalized before this stage runs, so intent capture stays on the same governed mode.

3. requirement_doc

Freeze a single requirement document under docs/requirements/.

After this point, execution should trace back to the requirement document rather than to raw chat history.

4. xl_plan

Write the execution plan under docs/plans/.

The plan must contain:

• internal grade decision
• wave or batch structure
• ownership boundaries
• verification commands
• rollback rules
• phase cleanup expectations

5. plan_execute

Execute the approved plan.

If the work is parallelizable, prefer Codex-native XL orchestration. If subagents are spawned, their prompts must end with $vibe.

6. phase_cleanup

Cleanup is part of the runtime, not an afterthought.

Each phase must leave behind:

• cleanup receipt
• temp-file cleanup result
• node audit or cleanup result
• proof artifacts needed for later verification

Router And Runtime Authority

The canonical router remains authoritative for route selection.

vibe does not create a second router. It consumes the canonical route, confirm, unattended, and overlay surfaces and then executes the governed runtime contract around them.

Rules:

• explicit user tool choice still overrides routing
• confirm_required still uses the existing white-box user_confirm interface
• unattended behavior is mapped into governed runtime mode, not into a separate control plane
• provider-backed intelligence may advise but must not replace route authority

Compatibility With Process Layers

Other workflow layers may shape discipline, but they must not become a parallel runtime.

Required ownership split:

• canonical router: route authority
• vibe: governed runtime authority
• host bridge: hidden hook wiring and artifact persistence
• superpowers or other process helpers: discipline and workflow advice only

Forbidden outcomes:

• second visible startup/runtime prompt surface
• second requirement freeze surface
• second execution-plan surface
• second route authority

Protocol Map

Read these protocols on demand:

• protocols/runtime.md: governed runtime contract and stage ownership
• protocols/think.md: planning, research, and pre-execution analysis
• protocols/do.md: coding, debugging, and verification
• protocols/review.md: review and quality gates
• protocols/team.md: XL multi-agent orchestration
• protocols/retro.md: retrospective and learning capture

Learn And Retro Surface

For LEARN / retrospective work, use the Context Retro Advisor vocabulary from protocols/retro.md.

• retro outputs should preserve CER format artifacts when that protocol is invoked
• completion-language corrections remain governed and evidence-backed

Memory Rules

Memory remains runtime-neutral:

• state_store (runtime-neutral): default session memory
• Serena: explicit decisions only
• ruflo: optional short-horizon vector memory
• Cognee: optional long-horizon graph memory
• episodic memory: disabled in governed routing

Quality Rules

Never claim success without evidence.

Minimum invariants:

• verification before completion
• no silent no-regression claims
• requirement and plan artifacts remain traceable
• cleanup receipts are emitted before phase completion is claimed

Outputs

The governed runtime should leave behind:

• outputs/runtime/vibe-sessions/<run-id>/skeleton-receipt.json
• outputs/runtime/vibe-sessions/<run-id>/intent-contract.json
• docs/requirements/YYYY-MM-DD-<topic>.md
• docs/plans/YYYY-MM-DD-<topic>-execution-plan.md
• outputs/runtime/vibe-sessions/<run-id>/phase-*.json
• outputs/runtime/vibe-sessions/<run-id>/cleanup-receipt.json

Known Boundaries

• the canonical router still owns route selection
• install or check surfaces should not be rebaselined casually
• host adapters may shape capability declarations, but must not fork runtime truth
• benchmark autonomy does not mean governance-free execution

Maintenance

• Runtime family: governed-runtime-first
• Version: 2.3.49
• Updated: 2026-03-23
• Canonical router: scripts/router/resolve-pack-route.ps1
• Primary contract metadata: core/skill-contracts/v1/vibe.json

Works with Claude Code · Codex · Windsurf · OpenCode · Cursor and any AI environment that supports the Skills protocol. Native MCP compatibility.

| ❌  Traditional Pain Points (you've probably felt these) | ✅  VibeSkills Solutions (what we've built) | |:---|:---| | Skills never activate: Hundreds of capabilities in the repo, but AI rarely remembers to use them — activation rate is extremely low. | 🧠 Intelligent Routing: The system automatically routes to the right skill based on context — no need to memorize a skill list. | | Blind execution: AI dives in without clarifying requirements — fast but off-target, projects gradually become black boxes. | 🧭 Governed Workflow: Clarify → Verify → Trace is enforced in a unified process; every step is auditable. | | Conflicting tools: Lack of coordination between plugins and workflows leads to environment pollution or infinite loops. | 🧩 Global Governance: 129 contract rules define safety boundaries and fallback mechanisms for long-term stability. | | Messy workspace: After extended use, repos become cluttered; new Agents miss project details when taking over, causing handoff gaps. | 📁 Semantic Directory Governance: Fixed-architecture file storage so any new AI conversation instantly understands the project context. | | AI bad habits: Deletes main files while clearing backups; writes silent fallbacks then confidently claims "it's done". | 🛡️ Built-in Safety Rules: Batch file deletion is prohibited (one file at a time only); fallback mechanisms must always show explicit warnings. | | Manual workflow discipline: Users must maintain their own AI collaboration process from experience — high learning cost. | 🚦 Framework-guided end-to-end: Requirements → Plan → Multi-agent execution → Automated test iteration — fully managed. | | Skill dispatch chaos in multi-agent runs: Hard to assign the right skills to each agent for different tasks. | 🤖 Automatic Skill Dispatch: Multi-agent workflows automatically assign the corresponding Skills to each Agent's task. |

👥 Who is it for?

Which of those pain points hit home? Find your position — what comes next will land harder.

| Audience | Description | |:---:|:---| | 🎯 Users who need reliable delivery | Want AI to be a dependable partner, not a runaway horse | | ⚡ Power users heavily relying on AI/Agents | Need a unified foundation to support large-scale workflows | | 🏢 Small teams with high standardization needs | Want AI workflows to be more maintainable and transferable | | 😩 Practitioners exhausted by skill sprawl | Already tired of tool hunting — just want a ready-to-use solution |

If you're looking for a single small script, this may be overkill. But if you want to use AI more reliably, smoothly, and sustainably — this is your indispensable foundation.

🔀 Intelligent Routing: How 340+ Skills Collaborate Without Conflict

You know this is for you. Next question: 340+ skills in one system — how do they stay out of each other's way?

With 340+ skills, you might wonder: "Won't similar skills conflict? How does the system know which one to use?"

How routing works

VibeSkills uses a Canonical Router as the single authoritative routing decision center:

graph LR
    A[User Task] --> B{Canonical Router}
    B --> C[Intent Recognition]
    C --> D[Keyword Extraction]
    D --> E[Skill Matching]
    E --> F[Conflict Detection]
    F --> G[Priority Ranking]
    G --> H[Routing Decision]
    H --> I[Execute Skill]

    style B fill:#7B61FF,stroke:#fff,stroke-width:2px,color:#fff
    style F fill:#FF9800,stroke:#fff,stroke-width:2px,color:#fff

VibeSkills follows a Clarify ➔ Plan ➔ Execute ➔ Verify governed workflow to ensure every task goes through complete quality control:

• Requirements Clarification: Skills like speckit-clarify define clear boundaries and acceptance criteria
• Architecture Planning: Skills like aios-architect design the implementation path
• Execution Layer: 340+ skills called on demand to complete the actual work
• Quality Verification: Skills like tdd-guide and code-review ensure delivery quality

[!TIP] Built-in CRON support: Explicitly enable it in your request to let vibe continuously advance tasks on a schedule.

I want you to continuously push forward XXX task based on cron, completing: XXXX $vibe

Why this design?

Traditional skill repos let AI "freely choose" — the result:

• ❌ AI can't remember what skills exist
• ❌ Similar skills conflict with each other
• ❌ Execution paths are unpredictable

VibeSkills routing guarantees:

• ✅ Determinism: Same task always follows the same routing logic
• ✅ Traceability: Every routing decision has a clear rationale
• ✅ Control: Users can override default routing via explicit invocation (e.g. /vibe)
• ✅ Stability: 129 governance rules prevent conflicts and divergence

M / L / XL Execution Levels

After selecting the primary skill, the router also automatically determines the execution level based on task complexity:

| Level | Use Case | Characteristics | |:---:|:---|:---| | M | Narrow-scope work with clear boundaries | Single-agent, token-efficient, fast response | | L | Medium complexity requiring design, planning, and review | Multi-phase, restrained, controllable | | XL | Large tasks — parallelizable, long-running, multi-agent wave execution | Auto-dispatches corresponding Skills, high parallelism |

The system automatically selects the level after requirements clarification, before plan execution. Users only need to invoke /vibe or $vibe.

You can also express an explicit preference:

Please execute this task according to the plan, launchin