SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsvibeflow-router

vibeflow-router

Agents & models

View repository

Updated 10-16 09:19

About this skill

Framework overview: Spark / Design / Tasks + Delivery Chain

VibeFlow exposes two development modes externally:

Full Mode (complete flow)

Phase Nature Description
Spark Manual By default, first enter Office Hours for problem framing, complete the complexity scan, optional DeepResearch, optional Roundtable, CEO value assessment, and after the closing summary wait for user confirmation
Design Manual Technical design + three-perspective review, and at phase closure wait for user confirmation on whether to enter Tasks
Tasks Manual Execution-level task-based handoff, generating tasks.md
Build Automatic takeover After entering build , by default the system automatically continues the subsequent chain, no longer waiting for the user at each segment
Review Automatic Cross-functional review (architecture, security, performance)
Test Automatic System testing + QA verification

Optional phases: Ship、Reflect

Quick Mode (rapid development)

Compress upfront analysis, retain a minimal design and task list, and after passing the Quick admission check go directly to Build.

Applicable: Bug fix, small changes, configuration updates, test/documentation patches

Minimum requirements：

  • .vibeflow/state.json in mode=quick
  • quick_meta.decision=approved
  • checkpoints.quick_ready=true
  • docs/changes/<change-id>/design.md
  • docs/changes/<change-id>/tasks.md

Not applicable：

  • New features
  • Authentication, payment, security, data migration
  • Multi-service, multi-database, architecture changes
  • UI redesign

Entry：/vibeflow-quick

Mode selection rules

  • .vibeflow/state.json Does not exist: This is the first entry, the user must first explicitly choose Full Mode or Quick Mode
  • .vibeflow/state.json Already exists: Directly continue using the existing mode, do not automatically rewrite, and do not ask again
  • /vibeflow-quick: Explicit Quick direct entry, no need to ask about the mode again

VibeFlow currentlywill not automatically inferwhich mode should be used on first entry. The first choice is an explicit decision; only subsequent resumption follows the existing state.

Session start protocol

At thestartof every session, follow this sequence without exception:

Step 1: Determine the current phase

Run the phase detection script:python scripts/get-vibeflow-phase.py Returns:increment、spark、design、tasks、build、review、test、ship、reflect、done

Step 2: Inject session context

Read the following files and format a summary:

  1. .vibeflow/state.json — current phase, mode, active work package
  2. .vibeflow/state.json.phase_history — completed phase history
  3. .vibeflow/state.json.runtime — current resumption reason, next-step suggestions, recommended files to open
  4. docs/overview/PROJECT.md、docs/overview/ARCHITECTURE.md、docs/overview/CURRENT-STATE.md(if present) — project-level long-term context
  5. feature-list.json — feature list and status
  6. Run python scripts/get-vibeflow-paths.py --json — parse the current work package artifact paths
  7. VIBEFLOW-DESIGN.md(if present) — project design document
=== Session Context ===
Current Phase: <phase>
Completed Phases: <list>
Reason: <why paused here>
Next Action: <what to do now>
Open Files: <recommended files>
Active Features: <count>
====================

Step 3: Check for increments

cat .vibeflow/increments/queue.json 2>/dev/null || echo "No pending increments"

If there are pending increments, handle them first.

Step 4: Route to the phase handler

Based on the detected phase, call the corresponding skill or script (see the routing table below).

Step 5: Check overview freshness

Read .vibeflow/wiki-status.jsonfirst; if it does not exist, then fall back to CURRENT-STATE.md 's "Documentation Sync Status" section.

If any of the following conditions are met:

  • docs/overview/PROJECT.md does not exist
  • docs/overview/ARCHITECTURE.md does not exist
  • docs/overview/CURRENT-STATE.md does not exist
  • .vibeflow/wiki-status.json any formal overview document in stale=true
  • CURRENT-STATE.md shows that the overview document is pending sync

then before entering Spark / Design / Review / Ship, first call skills/vibeflow-wiki/SKILL.md。

When calling, clearly state:

  • which document is missing
  • or whether freshness has expired
  • After refresh, re-check .vibeflow/wiki-status.json

Phase routing table

The router isfile-driven. The phase is determined only fromscripts/get-vibeflow-phase.py.

Phase Skill / Script Key deliverables
quick skills/vibeflow-quick/SKILL.md .vibeflow/state.json(including quick_meta）+ docs/changes/<change-id>/design.md + tasks.md
increment scripts/increment-handler.py Update feature-list.json
wiki skills/vibeflow-wiki/SKILL.md docs/overview/*.md + .vibeflow/wiki-status.json
spark skills/vibeflow-spark/SKILL.md docs/changes/<change-id>/brief.md
design skills/vibeflow-design/SKILL.md docs/changes/<change-id>/design.md
tasks skills/vibeflow-tasks/SKILL.md docs/changes/<change-id>/tasks.md
build Automatically continue after Build (Claude Code default) / scripts/run-vibeflow-autopilot.py(CLI corresponding entry point) feature-list.json
review Automatically continue after Build (continue by default) docs/changes/<change-id>/verification/review.md
test Automatically continue after Build (continue by default) docs/changes/<change-id>/verification/
ship Automatically continue after Build (continue by default) RELEASE_NOTES.md
reflect Automatically continue after Build (continue by default) .vibeflow/logs/retro-*.md
done — Completion summary

Detailed phase description(for the full document, see references/）：

Automatically continue after Build rules

When detect_phase() returns any of the following phases:

  • build
  • review
  • test
  • ship
  • reflect

The default behavior in the Claude Code plugin is not to stop at the current sub-phase and wait for the user to continue, but to start automatically continuing the subsequent chain:

  1. Execute the substeps corresponding to the current phase
  2. Immediately rerun python scripts/get-vibeflow-phase.py
  3. If the next phase still belongs to the above implementation phases, continue to advance automatically
  4. until:
    • done
    • After review/test failure, return to build
    • Hit a manual confirmation point
    • A blockage occurs that requires manual handling

For Claude Code,Build is the implementation entry point, and automatically continuing the subsequent chain is the default execution semantics。
vibeflow-build-init、vibeflow-build-work、vibeflow-review、vibeflow-test-system Sub-skills such as these are still retained, but their default positioning is:

  • Internal substeps in the automatic continuation chain
  • Single-phase debugging entry point
  • Recovery entry point after failure

If the user explicitly requests command-line unattended operation, CI execution, or dashboard-supported operation, use the script entry point for this automatic execution chain:

python scripts/run-vibeflow-autopilot.py --project-root .

Phase:increment

Condition: There are pending incremental requests. Operation: Read scripts/increment-handler.py to get the protocol, process each increment in FIFO order, update feature-list.json, and sync .vibeflow/increments/history.json and .vibeflow/state.json.phase_history。

Phase:spark

Condition: The user inputs a feature requirement and needs to explore inspiration, determine direction, and assess value. Operation: Use skills/vibeflow-spark/SKILL.md. By default, first enter skills/vibeflow-office-hours/SKILL.md to frame the problem and have the user confirm the acceptance criteria for this round; then complete the complexity scan, and the user chooses whether to perform DeepResearch; after research, optionally enter skills/vibeflow-roundtable/SKILL.md; finally complete the CEO value assessment and output to docs/changes/<change-id>/brief.md. After Spark closes out, you must summarize the direction and scope to the user and confirm whether to enter design.

Phase:design

Condition: spark has been completed, and technical design begins. Action: Use skills/vibeflow-design/SKILL.md, output docs/changes/<change-id>/design.md. Includes built-in steps: UCD (if needed) → user approval → AI eng review → AI design review → scope decision → stage artifact presentation and confirmation, and summarize the review conclusions into the review summary section in design.md . Note: UCD (visual style guide) has been merged into the design stage. Skip when there are no UI requirements.

Stage:tasks

Condition: design is approved, begin generating the execution-level task plan. Action: Use skills/vibeflow-tasks/SKILL.md, output docs/changes/<change-id>/tasks.md. Here the full delivery plan must be presented and await manual confirmation; Build must not be entered before confirmation.

Stage:build

Condition: tasks are complete and the delivery plan has been manually confirmed, proceed to implementation. Action: Begin automatically continuing the subsequent chain. Build will first execute the preparation steps, then use skills/vibeflow-build-work/SKILL.md to iterate over feature-list.json to implement features by priority. If review/test fails and returns to this stage, automatic execution will resume from here.

Stage:review

Condition: feature implementation is complete, code review is required. Action: As part of the automatic continuation chain, run skills/vibeflow-review/SKILL.md, output docs/changes/<change-id>/verification/review.md. If review fails, automatically return to build to continue processing.

Stage:test

Condition: review passed, system testing and necessary QA verification must be completed. Action: As part of the automatic continuation chain, run skills/vibeflow-test-system/SKILL.md; for projects involving page interactions, forms, routing, frontend APIs, or UI state transitions, skills/vibeflow-browser-testing/SKILL.md must be invoked during the test stage for real browser verification; for UI projects, continue running skills/vibeflow-test-qa/SKILL.md, with unified output to docs/changes/<change-id>/verification/。

Stage:ship

Condition: all tests passed, ready for deployment. Action: As part of the automatic continuation chain, run skills/vibeflow-ship/SKILL.md, generate RELEASE_NOTES.md, update feature-list.json.

Stage:reflect

Condition: project delivery is complete, retrospective required. Action: As part of the automatic continuation chain, run skills/vibeflow-reflect/SKILL.md, output .vibeflow/logs/retro-*.md。

Stage:done

Condition: all stages complete. Action: Generate completion summary (stage list, feature count, elapsed time, retro link).

For more detailed reference documentation, see the skills/vibeflow-router/references/ directory.

Hard Rules

These rules arenon-negotiable。

Rule 1: Vendor-neutral naming

Always use VibeFlow aliases instead of underlying names:

Use this not that
Vector store Chroma, Pinecone, Weaviate
LLM GPT-4, Claude, Gemini
Embedding model text-embedding-ada-002, bge-large
Framework LangChain, LlamaIndex
Runtime Docker, Kubernetes

Exception: may be used when a specific vendor is explicitly required in design.md .

Rule 2: File-driven over memory

The stage must be read from scripts/get-vibeflow-phase.py . Never infer the stage from conversation history.

If the script is missing: rebuild the stage from state.json.phase_history and ask the user to confirm.

Rule 3: feature-list.json is the source of truth

Build order, status, dependencies, and blockers all come from feature-list.json. Never assume a feature is complete.

Rule 3.5: After entering Build, by default automatically continue the subsequent chain

When phase first enters build , by default begin automatically continuing the subsequent chain, and keep advancing build -> review -> test -> ship -> reflect. Unless the user explicitly requests single-phase debugging, do not stop between these phases to wait for the next instruction.

Rule 4: state.json.phase_history is append-only

Do not edit, delete, or reorder historical entries. Recovery events areadded.

Rule 5: No phase regression without user consent

Regression occurs only when requested by the user, required by the recovery protocol, or when review/testing fails.

Rule 6: Keep artifacts in sync

Complete design → update feature-list.json andwrite design.md Complete build → update feature status andphysical files exist Complete ship → mark shipped andrelease artifacts exist

Rule 7: Incremental queue FIFO

Process in first-in, first-out order, without skipping steps or parallelizing.

Reverse-Spec Pre-Flight Check

Before entering the Spark or Design phase:

  1. Check whether docs/overview/PROJECT.md、docs/overview/ARCHITECTURE.md、docs/overview/CURRENT-STATE.md exists and is fresh
    • If it exists and is fresh → continue the normal phase flow
  2. Check whether the project root directory contains source files (.py, .ts, .tsx, .js, .jsx)
    • If it does → on first entry, prompt the user that they can run /vibeflow-reverse-spec to refresh the overview document
  3. If overview is missing or outdated and the user has chosen to generate it → call vibeflow-reverse-spec skill