Appearance
A Day in the Life of a BoB Workday
This page narrates one realistic developer day with BoB, end to end — a bug fix, a feature, a doc update, a parallel fan-out, and a stint on the farm. It is organized around the seams between commands (where one command's output becomes the next one's input), not as a per-command catalogue — the how-to guides already cover each command on its own. Read this when you want the mental model of how the pieces fit, before (or instead of) reading any single how-to.
Who this is for
Three readers enter the same narrative from different doors:
- The maintainer reads it to see the whole system run and notice where the seams are clumsy, manual, or surprising — so that friction can become filed backlog instead of dying in prose.
- The onboarding teammate (or future self) reads it for a narrative map of how the commands hand off to each other, before drilling into a specific how-to.
- The outside evaluator reads it to answer "what can you actually do with this?" without a live tour.
A fourth lens shows up the moment more than one machine is involved: the fleet operator working across the farm (ssh farm-01, Tailscale audits, cross-machine warp-drive). The farm section is written for them.
How to read it. The day runs on a temporal spine — morning triage → deep work → interrupts → end-of-day wrap — but each stop foregrounds the handoff, marked
A → B, where commandA's output feeds commandB. If you only want the handoff chain, skip to The seam map. If you want the automation-level differences, jump to The same task at two automation levels.
A note on honesty: BoB tracks all work as GitHub Issues (no local PM files), and the surfaces this page names — commands, flags, scripts — are the ones that ship today. Where a command is provisioned per-project rather than universal, the text says so, because that is exactly the kind of seam a newcomer trips on. As of 2026-07-17, the shipped inventory this page draws on is 47 commands, 61 skills, and 24 agents (universal and registry combined) — restamped from the live tree by /update-journey, so the numbers never rot.
Morning — triage
The day starts with the question "what should I work on?" BoB answers it from the issue tracker, framed by the product hierarchy (vision → business-case → capability → requirement).
/standup → /what-next. /standup summarizes where things stand — yesterday's commits, open work, anything blocked. /what-next then reads the approved queue (gh issue list --label approved) and names the single next item, ordered by priority (p1-critical → p4-low). The seam is the handoff from "where am I" to "what's next": /standup orients, /what-next selects.
Seam friction worth noticing.
/standupand/retrospectiveare registry commands — provisioned into a project from the registry, not present everywhere by default — whereas/what-nextis universal. On a fresh project the morning ritual is half-available until you provision the rest (/provisionorcdprov). That gap is the kind of thing this page exists to surface. → filed as #852 (promote/self-provision the ritual) and #854 (signal unprovisioned commands at the seam).
What you get out of triage is a requirement (or a bug) to work, already framed by its parent capability — so the why travels with the what into the next step.
Mid-morning — a bug interrupts
Before the planned feature gets started, something breaks. A bug is the most common interrupt, and BoB has a tight loop for it.
/report-bug → /start-work → fix → /commit → /finish-work.
/report-bug(orgh issue create --label bug) files the bug as an issue with a reproduction. A bug's definition of done is a reproduced failure plus a regression test that fails before the fix and passes after — not a checkbox./start-workcuts afeature/issue-NN-…branch off the main branch. This is a real seam: BoB refuses to do feature work on the main branch, so the branch is the handoff boundary between "triaged" and "in progress".- The fix. Reproduce first (ideally as a failing test on the pre-fix tree), root-cause it, then write the minimal fix that addresses the cause, not the symptom.
/commit. Here three seams fire at once, and they are worth naming because they catch people out:- the commit-gate hook blocks a commit that isn't allowed yet (during warp-drive it blocks commits outside the committing phase);
- the no-AI-attribution rule is enforced by a pre-commit hook that hard-blocks
Co-Authored-By: Claude/ "Generated with" trailers — commit messages stay clean of tool attribution; - branch cleanup is deliberate: merged branches are removed with safe deletes only, never a force-delete.
/finish-workmerges the branch back to main and cleans it up.
The bug closes with a resolution — a root-cause comment and a regression test named on the issue — not merely a merged PR. If the bug was a regression in a delivered requirement, the fix is back-linked to that requirement so the closed issue still shows the defect was caught.
Late morning — adding a feature
Now the planned work. A feature begins as a requirement and runs through the autonomous development loop.
/requirement → /warp-drive. /requirement writes the requirement issue — description, testable acceptance criteria as checkboxes, priority — and links it to its parent capability via Part of #NN. When the requirement is labelled approved, /warp-drive picks it up and runs the full cycle:
discover → plan → chunk → code → document → test → commit → report → merge/PR → (promote) → continue
The inner loop (code → document → test → commit → report) repeats once per commit-sized chunk (default ≤ 3 acceptance criteria each). The seams here are phase boundaries enforced by hooks: you cannot commit before the docs are updated, and you cannot end the session with an unfiled chunk report. The state machine, not goodwill, keeps the loop honest.
This is also where a larger requirement hands off to a capability above it: a cap issue groups related requirements, and a business-case sits above the capability to justify the investment. The chain business-case → cap → req → warp-drive is how a strategic decision becomes running code.
The same task at two automation levels
The same feature task looks materially different depending on the automation level, which is why the day can't be told as a single canonical flow. Automation levels map to permission profiles: L1 supervised, L2 trusted, L3 autonomous (/automation level N).
| L1 — supervised | L3 — autonomous | |
|---|---|---|
| Start work | You run /start-work yourself | warp-drive auto-creates feature/issue-NN-… |
| Decisions | Prompts you for plan review and most steps | Logs the plan inline and proceeds; only stops for genuine project decisions (architecture, ambiguity, new deps, scope) |
| Merge | Opens a PR for you to review and merge | Direct-merges to the main branch with the configured strategy |
| Continue | Asks "continue to next task?" | Auto-continues to the next approved item |
RDB-away mode is the third axis. When you step away from the desk, /rdb on routes every decision to Telegram (ask_remote) instead of the terminal — so an L3 session can run unattended and still reach you for the rare call that genuinely needs a human. Saying "I'm going AFK" is treated as /rdb on.
The honest takeaway: L1 is a conversation, L3 is a delegation, and RDB is what makes L3 safe to walk away from. Picking the level is the workday decision.
Early afternoon — updating documentation
The feature isn't done until its docs are. BoB treats documentation as part of the definition of done, with three tools that read one declarative target so they converge instead of fighting (see Why doc-bootstrap works the way it does).
/doc-audit → /doc-sync (or /doc-bootstrap).
/doc-auditmeasures drift read-only — it grades each docaligned/needs-update/archiveand writes a dated report underdocs/audits/./doc-syncapplies the mechanical fixes the audit found — counts, cross-links, naming normalization — and surfaces judgment calls (archival, ambiguity) for review rather than auto-applying them./doc-bootstrapis the authoring sibling: on a brownfield project with little or no documentation, it generates the net-new, code-grounded content needed to reach the documentation target.
The seam is measure → fix → author: /doc-audit produces the report /doc-sync consumes, and /doc-bootstrap fills the gaps neither can fix mechanically. Docs publish on ship, so a red docs gate blocks the merge for everyone — "fix the docs later" is not an available move.
Mid-afternoon — parallel work
When several approved items are independent, the day stops being sequential. BoB fans the work out across isolated git worktrees and tmux windows.
cdfork --from-issues (or swarm). cdfork fork --from-issues reads the approved queue and spins up one /warp-drive session per issue, each in its own worktree so the sessions can't step on each other. swarm wraps the whole loop — decompose → approve → capped dispatch → gate → integrate → summary — as a single command.
The critical seam here is the pinch point. Anything that serializes — lockfiles, migrations, shared config, compiled assets, the deploy itself — must not be fanned out, or parallel sessions will collide. Those issues are labelled serial-only so --from-issues excludes them from the fan-out. Knowing what can't go parallel is the actual skill; the fan-out is the easy part.
Late afternoon — working on the farm
Some work belongs on another machine — a long warp-drive run, or work that needs a heavier box. BoB's fleet is a registry of machines (machines.json) with roles like dev-laptop and farm-worker; farm-01 is the worker.
ssh farm-01 → remote warp-drive → scripts/fleet/audit.js. You SSH to the farm, start (or resume) a warp-drive session there, and observe the whole fleet from wherever you are:
scripts/fleet/audit.js snapshotpublishes this machine's project / provision / health condition to a snapshot file.scripts/fleet/audit.js pull <machine>runs the audit on a remote machine over Tailscale SSH and brings the result back.scripts/fleet/audit.js viewaggregates live and last-known-cached state across the fleet, marking anything stale or unreachable.
Each snapshot also grades every managed project's dev / test / deploy readiness statically — without ever running a dev server or a deploy, because an audit must stay cheap. The seam is machine boundary as a first-class handoff: work, state, and health cross between machines over Tailscale, and the audit is how you trust a machine you aren't sitting at.
Fleet friction worth noticing. Inbound audits need the target to accept SSH. macOS ships with Remote Login off, so a farm-to-Mac pull fails until Remote Login is enabled on the Mac — a one-time seam that bites exactly once. → filed as #855 (detect the unreachable Mac and emit the enable-Remote-Login fix).
End of day — wrap-up
The day closes by turning what happened into durable record — and, crucially, by turning the day's friction into filed work.
/session-summary → /journal → /retrospective.
/session-summaryfiles a session-summary issue: what was completed (requirements and fixed bugs as first-class items), and token usage for the session./journalcapturesdecisionandlessonissues — the why behind a call, and the systemic gaps a bug or a snag revealed./retrospective(a registry command) steps back over a longer arc to capture what should change about the process itself.
The seam that matters most here is the one back into tomorrow: friction becomes backlog. A clumsy handoff, a manual step, a surprising default — each is filed as a decision, lesson, or todo issue rather than left as a complaint in prose. That is what makes this page an introspection instrument and not just a tour: the honest narration of the seams is the input to the next day's work.
The seam map
Strip away the clock and the day is a chain of handoffs. Each arrow is a point where one command's output is the next command's input:
Triage: /standup ──▶ /what-next ──▶ (approved requirement)
Bug: /report-bug ──▶ /start-work ──▶ fix ──▶ /commit ──▶ /finish-work
Feature: /requirement ──▶ /warp-drive ──▶ merge/PR
Strategy: /business-case ──▶ /capability ──▶ /requirement ──▶ /warp-drive
Use case: /use-case ──▶ (cap | req) ──▶ ... "Realizes #NN"
Docs: /doc-audit ──▶ /doc-sync | /doc-bootstrap
Parallel: cdfork --from-issues ──▶ N × /warp-drive (serial-only excluded)
Fleet: ssh farm-01 ──▶ /warp-drive ──▶ fleet/audit.js snapshot | pull | view
Wrap: /session-summary ──▶ /journal ──▶ /retrospectiveThe spine handoff — the one the whole product hierarchy is built around — reads:
use-case → cap → req → warp-drive → finish-work → session-summary
A scenario (use-case) decomposes into a capability or requirement; an approved requirement is picked up by warp-drive; the finished work merges via finish-work; and the session is recorded in a session-summary. Every seam in that chain is a GitHub Issue link (Part of #NN, Realizes #NN), so the trail is queryable, not narrative-only.
The friction margin (introspection layer)
This is the page's introspection output: telling the workday honestly surfaces where the seams between commands are clumsy, manual, or surprising — and that friction becomes filed backlog, not prose that dies in a doc. The pass below mined every seam in this narrative (and the friction observed actually running a warp-drive session to write these pages) into candidate work, tracked under area:developer-journey and traced to use-case #840.
This section — and the inline "friction worth noticing" callouts above — is the internal introspection layer, wrapped in
<!-- friction:TYPE -->markers (#844). The showcase render (scripts/render-scenarios.js --mode showcase) strips these blocks for an outsider-facing read; the introspection render keeps them. One source, two audiences — no forked copies.
| Seam | Observation | Type | Issue |
|---|---|---|---|
| Bug fix · commit-gate | Blocks the whole compound Bash call on a commit-verb substring (it blocked filing these very issues) | pain-point | #858 |
| Feature add · commit→report | -F/--body-file commits don't auto-advance warp-drive state | automation-opportunity | #851 |
| Morning triage · ritual | /standup & /retrospective are registry-only — half-available on fresh projects | candidate-feature | #852 |
| Morning triage · awareness | No signal at the seam that a named command is unprovisioned here | candidate-feature | #854 |
| Feature add · dev-up | Two dev-up entrypoints diverge on a no-dev-environment repo | pain-point | #853 |
| Farm/fleet · audit | macOS Remote Login off by default → farm-to-Mac pull fails silently | automation-opportunity | #855 |
| Parallel · CLI aliases | cd* aliases live in dotfiles, outside the repo (not reproducible/groundable) | pain-point | #856 |
| End of day · promote | scripts/deploy.sh (BOB_SOURCE→BOB_HOME) isn't modelled as the repo's promotion target | candidate-feature | #857 |
Folded (captured, not separately filed): the "friction becomes backlog" discipline is realized by this pass itself (#845); the observation that the seam map / handoff chain is hand-maintained folds into the freshness work — #846 (/update-journey regenerates it) and #843 (the drift-check guards every named surface). Dropped: none — every seam produced actionable work.
First-pass tally: 8 filed, 2 folded, 0 dropped — clearing the use-case's ≥ 8-issue introspection target.
Where this page goes next
This is the narrative spine. Three companion pieces keep it honest and turn it into leverage, tracked under the area:developer-journey workstream:
- Code-grounding + CI drift-check — every command, flag, and count the page names is verified against shipped surfaces, and CI flags drift so the page can't quietly become fiction. This guard ships:
make check-scenarios-drift(part ofmake check) re-grounds every backticked slash command, script path, flag, and surface count in this page against the live inventory. When it fails, rename the reference to a shipped surface — or, if you are deliberately naming something a sibling requirement will add (like/update-journeybelow), declare it in the page'sdrift-allowcomment. See Verification & Testing System. - Two renders from one source — a polished showcase for outsiders and an annotated "friction margin" for the maintainer, so the page never has to choose between honest and impressive.
- A freshness mechanism —
/update-journeyrefreshes this page from git history and the live surface inventory: it restamps the stamped counts and date above and surfaces newly-shipped commands/skills/agents for the narrative, mirroring howstory/index.html+/update-storystay current. Both are thin callers over the shared narrative-from-git engine.
Between refreshes, the discipline stays manual: when a seam in this page stops matching reality, that mismatch is itself a filed issue — which is the whole point.