| name | pour |
| description | Pour a beads workflow formula — turn a recipe into a linked, gated molecule of beads issues with one command. Walks the user through picking a formula (project, engagement, braynee-release) and supplying its vars, then runs `bd mol pour`. Use when the user says "pour", "start a project", "new client engagement", "ship a release", "kick off X", "spin up a workflow", or "/braynee:pour".
|
| argument-hint | [project | engagement | braynee-release] (or no args to pick from a menu) |
| allowed-tools | Bash(bd:*) |
Pour — beads workflow formula launcher
Formulas are recipes for multi-step work. bd mol pour <formula> creates
the whole molecule of linked, gated beads issues in one shot — no manual
bd create / bd dep add sequence.
This skill is the friendly menu in front of that command. It picks the
formula, collects the vars via AskUserQuestion, dry-runs first to confirm,
then pours for real.
Available formulas (canonical)
Always re-list with bd formula list before showing the user — formulas
can be added or removed.
| Formula | Use when |
|---|
| project | Your own work. Internal projects, no client coordination. 4 steps: scope → build → qa → ship. |
| engagement | Paid client work. 7 steps: discovery → scope → build → qa → review → ship → handoff. Two human gates (discovery, review). |
| braynee-release | Shipping a new braynee plugin version. 4 steps: selftest → sandbox → deploy-cache → bump. No PR. |
Workflow
1. Pick a formula
- If the user passed an argument (
/braynee:pour engagement), use that.
- Otherwise call
bd formula list to show the live list, then use
AskUserQuestion to ask which one.
2. Show what it does, then collect vars
- Run
bd formula show <name> so the user can see the steps and vars
before they commit.
- Use AskUserQuestion to collect each required var. Mark optional vars as
such — let the user skip them.
Required vars per formula (verify with bd formula show — this is a
quick reference, the formula files are authoritative):
| Formula | Required | Optional |
|---|
| project | name, deliverable | — |
| engagement | client, deliverable | reference |
| braynee-release | version (semver X.Y.Z) | — |
3. Dry-run first
ALWAYS dry-run before pouring for real:
bd mol pour <formula> --var key="value" ... --dry-run
Show the list of issues that would be created. Ask the user to confirm
before re-running without --dry-run.
4. Pour for real
On confirmation, drop --dry-run:
bd mol pour <formula> --var key="value" ...
Report the molecule ID and the IDs of the newly-ready issues. Suggest the
user run bd ready to see what's actionable now.
After pouring
The molecule's issues are real beads issues — they work with everything
beads already does:
bd ready shows unblocked issues (only the first step + any non-gated
parallel steps will appear).bd update <id> --claim claims one to work on.- Human gates need
bd gate resolve <id> when the human checkpoint
(discovery call held, client signed off, etc.) is done.
- Timer /
gh:run gates auto-advance via the braynee beads-gate-check
Stop hook — no manual polling.
Var quoting reminders
PowerShell and bash both expand differently. The pattern that works
everywhere:
bd mol pour engagement \
--var client="Acme Co" \
--var deliverable="Mastra RAG agent over their docs"
If a var value contains a quote, switch the outer quoting style or
escape with \". Watch for stray semicolons in step descriptions —
beads will accept them but they look weird in bd show <id>.
When NOT to use this skill
- If the user is working a single discrete task,
bd create directly is
lighter than pouring a whole molecule.
- If the formula concept doesn't fit — they want a one-off issue, not a
recipe — don't force a formula.
Formulas are for recurring shapes of work. Use them when you'd
otherwise be typing the same bd create sequence for the third time.
