be

Be

Take a task to a shipped, reviewed PR. Unlike /do (autonomous start to finish), /be opens with a short interview — and is then fully autonomous, exactly like /do, from §1 onward. The interview is the only place /be asks the user anything; after it, make sensible defaults and keep moving — no further AskUserQuestion, no stopping between steps. The single exception is the optional plan-review pause in §1, and only when "plan first" was chosen. Concise by design — defer mechanics to the skills it calls.

Autonomy doesn't inherit — propagate it to every subagent you delegate to. When you hand work to a fresh subagent (a §2 package build, a §5 "finish the ship" CI+gate+cleanup pass), its prompt must say execute now; do not wait for confirmation, do not ask me to "say go" — a subagent starts without your interview's "no stopping between steps" contract, so a prompt that merely lays out a plan gets a plan back (zero tool uses) instead of done work, and you're the one who has to type "go." Bake the directive into the delegation, and if a subagent still returns a plan-and-waits with no tool uses, resume it with "execute now" rather than surfacing the stall to the user.

Requires Claude Code's Skill tool (the debate reviewers it calls are Workflow-backed).

0. Interview (the differentiator)

Before any work, ask the user via AskUserQuestion (one call, batched):

• Plan first? — write the plan as an Atlas note (docs/atlas/src/content/atlas/<slug>.mdx) for review before implementing, or implement straight. Default: straight, unless the task is large/ambiguous. (If the prompt already points at an existing Atlas note or legacy docs/plans/*.html, skip this question — that file is the plan of record; reuse it.)
• Task kind — bug fix · feature/new behavior · refactor/chore. This sets the test strategy (see §2).
• Ultracode? — include this question only when no system-reminder says ultracode is on. Remind the user that /be runs richer with ultracode (deeper review fan-out, adversarial verification of each finding) and ask whether to proceed on the standard pass or pause so they can enable it. Options: Proceed (standard pass) / I'll enable ultracode first. If they pick the latter, stop and let them turn it on, then re-run.

Add a question only when something material is genuinely unclear — don't pad. Honor anything the user already pinned in the prompt instead of re-asking. This single AskUserQuestion call is your one and only chance to ask — surface every clarification you need now (including the ultracode check above), because everything after this is autonomous.

1. Set up

• git fetch origin; branch off origin/<default> (git symbolic-ref --short refs/remotes/origin/HEAD). Feature branches only — never commit to master.
• Read .agency/do.md for the project's check / fmt / test / ci commands and its ## PR evidence section. Reuse them throughout.
• If "plan first" (or working off an existing plan): the plan of record is an Atlas note (docs/atlas/src/content/atlas/<slug>.mdx). Load /atlas (Skill tool) for the note mechanics — frontmatter, the component kit, just atlas::build + staging dist/, and the Code-tab + htmlpreview share links. Set kind: to match the §0 task (bug/feature; else analysis/reference) and status: proposed. The plan itself must: (a) stay high-level — user- and architecture-focused (what changes + the shape: seam, data flow, trade-offs and alternatives), with no implementation dump (no line-level code, file-by-file lists, or signatures; the how is §2's job); (b) carry a UI prototype (<AtlasMockup> or inline JSX) if the change has any on-screen surface, so the user judges look-and-feel before code; (c) ground every load-bearing low-level fact against the installed code before asserting it — staying high-level (a) does not license guessing. A pinned dependency version (read the lockfile, not the ^range), a third-party library's emitted markup / attribute / API shape, a test-environment strategy (a unit env or a needed dep), a framework runtime behavior (e.g. does a coarse SolidJS store reader coalesce same-shape deltas, or does Solid flush every write? — a load-bearing reactivity/coalescing fact you reproduce empirically against the installed source, never deduce from first principles) — each is a fact the how in §2 will be built on, so verify the few the plan leans on the same way §2 gets ground truth (read the lockfile / the package's vitest.config.ts / the actual emitted DOM / a throwaway repro of the reactive path), don't recall it from training. A plan that asserts [email protected] emits class="footnote-ref", test it under happy-dom when the lockfile says 1.4.0, the marker is a bare data-footnote-ref, and the package keeps a deliberate node-only env with no happy-dom is wrong, not merely detailed — it forces an implementation-time reconciliation and ships a false published note. Self-check before presenting — rework until all hold; don't make the user be the linter: high-level ✓, prototype-if-visual ✓, facts-grounded ✓, renders clean ✓. Then push the branch and hand it over for review via the Code tab and the htmlpreview link — do not use plan mode; wait for the user's reply, incorporate feedback (rebuild + push each round), and resume only on their go. This is the one sanctioned pause. The plan ships in the PR. (A legacy docs/plans/*.html plan stays HTML — edit it in place.)

2. Implement

Honor the design philosophy first. Before writing code, re-read .claude/rules/conventions.md → Design philosophy (fail-fast / no-fallbacks · electricity boundaries · reuse the existing source of truth) and state in the plan or PR body how this change honors each. A fallback path, a new override knob, a domain-agnostic helper folded into an app module, or a hand-rolled mechanism that duplicates an existing one (.gitignore, an extension/MIME table, a library) is a defect to fix now — not a follow-up the review gauntlet should have to catch.

• Bug: reproduce before you theorize or fix — start from facts, not a story about the bug. Where it runs: pu box, not locally — building, running the repro (just test-quick/just dev-auto/a scripted repro), and any "let me SEE it" check are heavy work, and reproduction is the §5 venue gate fired early. Whenever systemctl --user is-active kolu is active (the normal case) that work belongs on an ephemeral pu box, never on the user's machine: a pile-up of local builds + e2e runs OOM-killed production kolu.service once, and a broad pkill -f <substring> to clean up OOM'd processes killed it again — its nix-store process matched the substring. Load /dev-server §0 before launching/building/repro-ing anything, and never pkill -f by any command substring — resolve PIDs by remembered port, or just let the pu box go. (1) Get ground truth from the running system; observe the real symptom, don't trust a description of it. (2) Pin the one hard, observable fact the bug produces — a wrong value, an error, a state that can't legally happen (e.g. "the client SHA stays 7deb397 across reloads"). (3) Build a reproduction that exhibits that exact fact and is red on the current code — a failing e2e test via the /test harness when it can express the bug, otherwise a scripted repro. A repro that passes / converges / "works" is not a reproduction: if it doesn't show the symptom the repro is wrong — fix the repro, never conclude "no bug" from it. (4) Only now fix, until that same repro flips green. No fix without a reproduction that was first red for the real reason. The fix must make the feature work, not disappear: disabling it, defaulting it off, or routing the affected platform onto a degraded path is the no-fallbacks violation from §2's design-philosophy clause wearing a bug-fix hat — a mitigation, not a fix, and a defect to reject now, never to ship or post as "verified." If the only remedy you can find removes or degrades the behavior, you haven't understood the bug yet — keep digging (fork the upstream dependency if that's what a real fix needs) before you settle.
• Feature / new behavior: write the covering test (e2e/integration/unit as fits) before or alongside the change.
• Refactor/chore: no test-first requirement; rely on existing coverage.

Sync the docs. Read .agency/do.md for its ## Documentation section — a principle (discover the stale docs, don't recall a checklist), not a fixed file list. Updating the README + Atlas and stopping there is the exact pattern-match-a-couple-and-skip-the-rest trap it warns against. So grep every doc surface for the term you touched — the command, flag, type, or word — across README.md, every packages/*/README.md, website/ (the kolu.dev marketing pages, e.g. src/pages/*.astro, which hand-list commands and carry "next up is X" prose that goes false), and docs/atlas/. For each hit, either edit it or record why it's still accurate — "I updated the README" is not a doc-sync until the changed package's README and every user-facing marketing surface were each grepped and resolved. The docs commit rides the same review gauntlet as the code. Skip only when the change is genuinely doc-neutral.

Add a changelog entry. For any user-facing change, append one line to website/src/content/changelog/unreleased.mdx under the right ### heading — Added / Fixed / Changed / Heads-up (the editorial home for disruptive changes: a removed feature, a changed default, a migration). Create the heading if a freshly-reset section doesn't have it yet. Write it as prose a user reads, not a commit subject — no PR link yet (the PR doesn't exist until §3; you backfill the link there). Skip only whe

Content truncated.