brothersbe

Use when someone is adding risk and evidence checks to a repository that has never had them, or is checking whether an existing installation is actually wired up. Inspects the repository for readiness, proposes a configuration, and reports what is present, what is missing and what it could not check. Dry run by default. Invoke as /brothersbe:adopt.

Use when someone is deciding or reviewing the shape of a system before it gets built: what it is for, how the process runs, what the architecture and the data model look like, and how it will be verified. Runs the six design phases in order, each gating the next, and checks the dossier for the artifacts the tier requires. Fires on the work itself: start already routes into it once kickoff has scored the intake, so nothing needs to be typed to reach it.

Use when someone wants to hand this change's ownership to another named human, or when a receiver wants to inspect and accept or reject a handover already prepared for them. Runs the status and worktree checks first, then prepares (or reads) 12-handover.json through the sbe handover engine and renders the concise handover summary a receiver needs, never the project's whole history. Invoke as /brothersbe:handover.

Use when someone asks how this system works or which command or skill to use. Explains in plain language how a change earns its evidence and its approval, points to the three entry skills, and only then offers the full map of specialist skills and commands. Invoke as /brothersbe:help.

Use before designing or writing anything, when a backend, infrastructure, or data engineering change has not had its ground mapped yet and nobody has named what will verify it before it begins. Classifies the work profile, maps the ground (git state, disk, the repo's own build and test commands), scores the intake into a tier, and names the checks that will verify the work before the work begins. Fires on the work itself, the same way start already routes into it, so nothing needs to be typed to reach it.

Use when a lesson from an incident, a repeated correction, a review finding or a measured outcome should become a shared rule, or when a session wants to propose an amendment to the laws. Proposes; it never lands a change to shared behavior. Invoke as /brothersbe:learn.

Use when someone asks what to do next in their work. Evaluates a fixed priority ladder against observable state and returns exactly one recommended action with a one sentence reason, never a menu of options. Invoke as /brothersbe:next.

Use when someone is changing an API response or request shape, an event or message contract, a partner or third party integration, a retry, timeout, or idempotency path, a queue consumer, a service boundary, a warehouse model, a SQL transformation, a dbt model, an ELT or ingestion step, a table schema, or a backfill, or when they ask whether a change will break something and what proof a reviewer will want. Fires on the work itself, with nothing started and no command learned. No BrotherSBE session, dossier, or setup required.

Use when reviewing a diff, a pull request, or a colleague's change against the design it claims to implement. Runs the deterministic reviewer route to decide who looks, dispatches only the read-only specialists it names, normalizes and deduplicates every finding into the landed schema, and returns a fixed summary (ready or not, mechanical counts, the lenses used, blockers, improvements, pre-existing issues, one next action) with detail underneath. Invoke as /brothersbe:review.

Use when a vague stakeholder ask needs to become a measurable specification with acceptance criteria, when requirements are being written or challenged before build, or when a dataset is being prepared and handed to a data scientist or analyst and its grain, keys, snapshot, and known limits must be declared. Fires on the work itself, with nothing started and no command learned. Never chooses, tunes, or interprets a model.

Use as the single entry point when someone wants to begin or resume work and does not know, or does not care, which command comes next. Detects existing state, resumes it when found, and otherwise asks for the outcome in plain language and routes into the next step. Invoke as /brothersbe:start.

Use when someone wants to know where their work stands. Wraps the status command and the fence registry, and reframes the raw output as a plain answer with one next action, with technical detail kept below the summary rather than leading it. Invoke as /brothersbe:status.

Use when work is about to be called done, a figure that could reach a decision has been produced, a schema migration is part of the change, the change touches money or a partner path, or a verification plan is being written. Runs the hard gates and reports PASS, FAIL or NO-DATA with the evidence each verdict actually read. Invoke as /brothersbe:verify.

Use when a plan already exists and its tasks are ready to be built, not just recommended or designed. Reads the engine's JSON state, briefs and starts one to three independent ready tasks, dispatches each to an implementation-worker subagent inside the worktree already opened, verifies the result and finishes, and hands a claimed task to a human on request. Fires on the work itself: start already routes into it once a plan is ready, so nothing needs to be typed to reach it.