Skip to content

lyddonb/bstack

v0.2.0MIT

Beau's rigorous agent workflow. beau-mode routes each task to a playbook and the principles; skills for understanding (how, why, teach, recall), proof (verify-work, create- and maintain-verification-skill, swarm), design and planning (architect, arena, technical-writing), review and trails (interrogate, show-me-your-work), and improvement (reflect, correct, unslop) do the steps. Adapted from Lauren Tan's pstack to work in any agent.

architect

Design before code. Ground in the affected systems, sketch types and signatures in at least two structurally different shapes (via arena), pick one, implement against it, and scrap it when friction shows the shape is wrong. Use for /architect, "design this", or work where jumping to code would lock in the wrong shape.

arena

Run N parallel candidates at the same task (ideally on different models), have a judge on another model score them against a rubric, pick a base, and graft the best parts of the others into it. Use for /arena, "arena this", "throw it in the arena", or when one attempt at a non-trivial artifact (a design, an API, a doc, a tricky function) would lock in the wrong shape.

beau-mode

Beau's way of doing engineering work with an agent. It picks a playbook, applies named principles, verifies on the real artifact, keeps a decision trail, and writes plain replies. Use for /beau-mode, "beau mode", or any non-trivial engineering task (a bug, a feature, a refactor, a perf problem, an investigation, a prototype, a skill edit, or an unattended run). Skip it for casual questions and one-line answers.

correct

Find the mistakes agents keep repeating in this repo and make each one impossible. Tries architecture first, then types, then a lint or CI check whose error names the fix, then a test, and docs last, and proves each new check fails on a real past mistake. Use for /correct, "agents keep doing X", or after correcting the same mistake twice.

create-verification-skill

Generate a project-local verify-<app> skill that launches the real app, drives it like a user through a control CLI, captures evidence, and keeps a feature map. Any stack or surface. Use for /create-verification-skill, "make a control skill for this repo", or when a project has no scripted way to prove behavior.

figure-it-out

Design a rigorous, auditable playbook for work no standard playbook fits (a large migration, an ambitious multi-part change, or anything the human will review after stepping away), then run it as a hypothesis loop with a decision trail. Use for "figure it out", large or cross-cutting changes, or overnight and unattended work.

how

Explain how a subsystem, feature or code path works, at the level a senior engineer needs before changing it, covering runtime flow, key concepts, where things live and gotchas. Use for "how does X work", walkthroughs before a change, onboarding to unfamiliar code, and "where should this live" or "which layer owns this" questions.

interrogate

Adversarial multi-model review of a diff, branch or PR. Several independent reviewers try to break it, then a lead reviewer sorts findings into act on, consider, noted and dismissed. Use for "interrogate", "adversarial review", "tear this apart", "stress test this change", "find blind spots", or before shipping a contested or risky change.

maintain-verification-skill

Periodic pass that keeps a project's verification skill and feature map honest. Read-only subagents check each feature against source, one live session drives every feature, and at most one PR ships proven corrections. Use for /maintain-verification-skill, "audit the verify skill", "is the feature map still right", or as a daily scheduled task.

recall

Rebuild the user's recent context on a topic from their own agent transcripts, the PRs, tickets and reports around it, and live git state, then return a short brief and the next move. Use for "recall my work on X", "catch me up on X", "where did I leave off", before starting or resuming work.

reflect

Mine the current session for durable lessons and turn each one into a concrete, approved edit to a skill, playbook or principle, or a backlog item. Three independent reviewers read the transcript, a synthesizer sorts their findings, and nothing changes without the user's approval. Use when the user says reflect, "capture what we learned", or "so the next run doesn't repeat this".

show-me-your-work

Keep a reviewable decision trail for long, unattended or multi-phase work (one TSV row per decision with what, why, evidence and result), then audit it against the transcript and have a different model flag what deserves attention. Use for /show-me-your-work, "keep a decision log", autonomous or overnight runs, or "catch me up on what you did".

swarm

Fan out N parallel workers (local subagents, or cloud agents where your tool has them), wait for all of them, and return one consolidated report. Use for /swarm, "swarm this", parallel coverage of many slices, races of N attempts at one brief, live-verification lanes, fuzzing, or collecting enough perf samples to trust a number.

teach

Explain a body of work plainly so a person actually understands it, by running the how and why skills and weaving what they find into one clear, layered explanation with diagrams that build up step by step. Use for "teach me this", "help me really understand X", "explain this change or subsystem to me", or "prove to me this approach is better".

technical-writing

Layered technical-writing standard (Diátaxis structure, Google developer style sentences, Simplified Technical English instruction rules, Global English syntax). Use for /technical-writing, README-driven planning, or when writing or reviewing docs, READMEs, RFCs, design docs, plans, PR descriptions or commit messages.

unslop

Cut AI writing tells from prose, such as filler, inflated vocabulary, em dashes, rule-of-three padding, chatbot phrases, vague metaphors, over-compression. Use when writing or reviewing any prose (replies, docs, READMEs, PR descriptions, commit messages, skill files), or when asked to unslop, tighten or de-AI text.

verify-work

Prove a change works by checking the real artifact (run the feature, read the actual value, drive the real surface) and return VERIFIED, NOT VERIFIED or INCONCLUSIVE with evidence. Use before saying any task is done, when asked "does it work", "prove it", "verify", or when a claim rests on "it compiles" or "tests pass".

why

Find out why code is the way it is (design rationale, past decisions, regressions, where a threshold came from) by searching git, PRs and every connected ticket, doc, chat and observability tool in parallel, and return a cited, confidence-tiered answer. Use for "why does X work this way" or "why did we pick Y". Use how for what code does.