Using BuilderOS

Route by the requested result, keeping the person's scope, supplied inputs, output destination and existing authorization. Requests unrelated to product work use the session's other capabilities.

Mode. A guide, diagnosis, recommendation, PRD, spec edit, plan or review is standalone unless lifecycle execution was requested: no phase files, no logged override. The boundary, and where shared resources and scripts resolve from the real installation, are in operating modes. Read state and session briefing for lifecycle routing or status; a standalone answer loads neither the initiatives nor the schema.

Procedure

1. Read the context the request needs. A lifecycle or status request reads the active initiative and briefs from project memory (scripts/bos.mjs brief computes it where commands run). A standalone question reads what affects the answer. Done when you know whether BuilderOS memory exists and what the request touches in it.
2. Run the watch below against the request. Done when every check that applies is named in at most two lines, or none applies.
3. Choose the smallest useful route from the table. State it briefly when useful and start; ask only when a material ambiguity remains after reading the inputs, since an authorized task needs no repeated confirmation. Done when one route is chosen.
4. Run the selected skill, passing the request and inputs verbatim and loading extra methods only for parts of the request they answer. A recommendation to build starts nothing by itself. Done when the routed skill is running.

Watch While Working

In a project with BuilderOS memory, check every product request against it before doing the work, say what you find in at most two lines, then continue. On a real project these checks would have caught scope built against the phase 2 and 3 conditions, a pilot that never started while features kept shipping, and a PRODUCT.md still describing the idea stage:

• Contradiction. The request goes against an accepted decision in decisions/, a PRODUCT.md non-goal, a condition a phase artifact set ("no further scope until the pilot passes", a kill criterion) or the active spec's or build plan's out-of-scope. Name the file and line, then ask one pressure-testing round question: keep the condition, supersede it on the record, or open a new initiative for the request, as a change when its solution is already fixed, so the cheap path stays inside BuilderOS. New scope after the build plan is accepted becomes its own initiative or a recorded amendment.
• Stale truth. What the person just decided makes PRODUCT.md, ROADMAP.md, the spec or an evidence file wrong (a stage, a non-goal, a "Next" item already built, a superseded preference). Update it in the same step, or name it when the update is outside the authorized scope.
• Shaky ground. The request builds on an [assumption:unvalidated] or a deferred branch whose test never ran. Name it and the cheapest test.
• Unread result. A shipped change whose outcome metric nobody has read, or a launch or pilot whose start conditions are still open, when the request is more work in the same area. Say the measurement comes first, or why it can wait.
• Someone else's initiative. The briefing shows the active initiative claimed by another person. Say who and since when, and ask whether to work on it anyway: their release, or a take-over with the reason (claim --take --reason), keeps two sessions from writing one state. When you start lifecycle work on an unclaimed initiative where commands run, claim it for the person (claim --by "{person}").
• Code before an accepted plan. The request asks for product code in an initiative whose build plan is not accepted yet ("skip the rest, just write it"). This one is a gate: write no code. In one message name what the gate still needs and offer the paths, with a recommendation: finish it (often one short round), run the work as a change when the solution is already fixed, or record an override with the person's own reason through the script (record {phase} --override "reason"), visible in every briefing, then build. The person's decision to skip is a reason to log: code built past an unrecorded gate is how a project ends up with features its own phase 2 said not to build.

The briefing's Attention line covers what the files decide mechanically; the first five need judgment. They inform the request without blocking it, and each is raised once per session.

Routes

Evidence and gate skills support the selected work; a standalone answer stays standalone. Load pressure-testing to interview the person: a brainstorm, a requested critique, or a material unresolved assumption.

Capabilities

files.read supplies context; without it, work from supplied material and name the gap. shell.exec runs the briefing; without it, read the relevant memory directly.

Watch for

Output Contract

An ambiguous request gets the route and its reason, then the blocking choice; an obvious one goes straight to its result. ## ROUTE CHOSEN is an optional routing marker, separate from phase completion evidence.