Appearance
wb-flow Documentation
The official documentation for the 33-command
/wb*agentic workflow system.This is a field manual — opinionated, direct, and written for developers who actually use these commands rather than just read about them.
Who is this for?
Stack-agnostic. wb-flow runs on any project where you have source files and markdown — Vue, React, Svelte, Solid, Next.js, Nuxt, Astro, Django, FastAPI, Rails, Go, Rust, anything. The 33 commands operate on package.json, source trees, and report folders; none of them care which framework wrote the code they're reading.
The one exception: /wbToWBC converts code to use the wbc-ui2 component primitives, which are Vue-based. If you're not on Vue, ignore that one command. The other 32 are universal.
Why examples skew Vue. This documentation was authored within a Vue monorepo (wb-core, wb-press, wbdataviewer2.wbc-ui.com), so every worked example draws from there. The patterns transfer one-for-one — /wbAudit reads source code the same way whether the source is .vue, .tsx, or .py.
What you need on day one:
- A folder with code in it (any language)
- A way to run the commands (any AI agent environment that accepts prompts)
- Nothing else — no Node version requirement, no framework lock-in
How outputs are tagged (v1.8+)
Every output file from a suggestion-emitting command (/wbPlan, /wbAudit, /wbReview, /wbVision, /wbIdea, /wbStandup, /wbNext, /wbActOn) carries three metadata layers:
1. YAML front-matter:
yaml
---
type: 🔨 Worker # the dominant action type
emits: mixed # `pure` or `mixed`
---2. A Requires column in every recommendation table:
3. The four canonical action types:
- 🧠 Planner — Deep reasoning, strategy, multi-step decomposition
- ✅ Validator — Big-thinker code-quality judgment, scoring
- 🔨 Worker — Coder/executor: surgical code edits, refactors
- 📋 Mechanical — Run command, parse output, format report. No judgment
See concepts/model_recommendations for which model to use per role.
How to read this documentation
The seven files per command:
Reading order for a new user
- start_here/installation— NPM, NPX, or Git installation
- start_here/getting_started— 30-day onboarding plan
- start_here/first_run_walkthrough— Annotated first session
- start_here/bootstrapping_existing_project— Inheriting code without- /wbSetup
- concepts/overview_agentic_workflows— Commands grouped by the question they answer
- daily_use/the_daily_playbook— Morning → midday → afternoon → evening shape
- commands/— Pick the command you're about to use; read its- practicalfile
If you only ever read one of these, read the daily playbook.
Concept deep-dives
Cross-cutting ideas that don't belong in any single command's docs:
- concepts/agentic_vs_manual— When structured commands beat freeform prompting (and when they don't)
- concepts/command_classification— All 33 commands grouped into functional families
- concepts/command_composition— Self-application, chaining notation, chain recipes
- concepts/wbPlan_flag— How- --actand- --wbPlancompose across commands
- concepts/plan_state_management— The five task states (- ⬜- ✅- ⏸️- 🚫- 🔄), override flags, and the plan file's four derived blocks
- concepts/report_lifecycle— Consolidate, then archive: keeping one live file per category
- concepts/ideas_pipeline— The 8-step Ideas Pipeline from birth to execution
- concepts/model_recommendations— Which model to use per command role
- concepts/flags_and_shortcuts— System-wide flag→shortcut grammar
- concepts/universal_flags_exhaustive_simulation— Brain Control super-flags simulation
- concepts/wbWorkflow/README— Workflow architecture, lifecycle, and task sequencing
- session_lifecycle/README— Golden Save Point, session boundaries, publishing arcs
The 33-command catalog
Grouped by the question you're asking when you reach for them.
"What is this codebase?" — Context Builders
"What should I do next?" — Planners
"Execute and validate" — Workers & Validators
"Is this any good?" — Critics
"Clean this up" — Surgeons
"Ship it" — Shippers
"Version control" — Archivist
"Protect & cross-cut" — Security, Translation, Migration
"Session telemetry" — Tracking
What this documentation is NOT
- Not the runtime templates. The source-of-truth _template.mdfiles that define what each command actually does live inpackages/wb-flow/templates/commands/. This documentation covers how to use them.
- Not API documentation. Every file is hand-authored for human readers.
- Not exhaustive on flags. If a command has 12 flags but only 3 matter daily, the docs cover the 3. The full flag list is in the runtime template.
wb-flow documentation — flow.wbc-ui.com · wb-flow on npm · wi-bg.com
Previous-release documentation
They are two separate VitePress apps, not one versioned site. The 1.0.1 build sets base: '/v1.0.1/' and is deployed into its own subdirectory of the web root; it never lives in the current source tree. Every archive page carries a banner and a Current version nav entry linking back here, so the two directions both close.
IMPORTANT
Verify this route by content, never by status code. The host serves try_files $uri $uri/ /index.html, so every path returns HTTP 200 — including paths that do not exist. /v1.0.1/ answered 200 for roughly ninety days while it was not deployed at all, and a status-code check reported that as healthy the entire time.
The check that works asserts something only a correctly-built archive can produce: its HTML contains /v1.0.1/assets/…, because base rewrites every asset URL. A redirect body, a soft-404, a partial upload, or a build made without base all fail it. scripts/smoke_test.sh runs exactly this.
CAUTION
Deploy with tar xzf, never rsync --delete. tar extracts over the existing web root and leaves unrelated paths alone; --delete removes everything absent from the new build. The web root is shared, so --delete would destroy any versioned archive alongside the current site. See the deploy runbook.