Spawn bb threads with the bb-subagents skill

Where this fits

You're inside a long-running bb session, and the user says "launch a bb thread on the payments repo with Codex at high reasoning." A correct spawn requires the project path, provider, model ID, reasoning level, service tier, and worktree — and bb will not infer the project from your current thread. bb-subagents gives your agent a precise recipe for that spawn, so it doesn't guess flags or silently launch into the wrong context. It is deliberately narrow: handle the spawn, report the thread ID, stop.

Why agents benefit

• Encodes the default worker (Codex gpt-5.6-sol, --reasoning-level high, --service-tier fast) so agents don't have to reconstruct it from past sessions.
• Forces an explicit --project, preventing the CLI from placing the thread in an unexpected directory.
• Eliminates scope creep: no thread open, --split, or focus commands after spawn — just launch and report.
• Provides a simple escalation path (xhigh) for larger refactors while keeping the default safe.
• Gives agents a decision rule for provider/model lookup, avoiding hallucinated IDs.

Practical scenarios

Spawning the default thread for a bugfix

User: "spawn a bb thread to fix the auth timeout." Agent reads the skill, uses the default Codex model with high reasoning and fast tier, passes the project explicitly, and reports the new thread ID without switching focus.

Bumping effort for a cross-module refactor

User: "launch a bb session on the monorepo with xhigh reasoning." The agent keeps the default provider/tier but raises reasoning to xhigh, as the skill suggests for larger refactors. It spawns, returns the ID, and waits.

Distinguishing bb threads from other CLI agents

User: "run Codex CLI in bb" vs "use Cursor Task on this file." bb-subagents is only for spawning bb worker threads; codex-subagent handles plain Codex CLI and launch-subagent handles Cursor Task. Choosing the right skill prevents invoking the wrong runtime.

Add it to your agent workflow

Install with:

npx skills add davidondrej/skills --skill bb-subagents

Then tell your agent to invoke the skill whenever a bb thread spawn is requested:

User: "spawn a bb thread on api-gateway with Grok"
Agent: Check bb-subagents, look up the latest Grok model ID, then run:
bb thread spawn --project api-gateway --provider grok \
  --model <looked-up-model> --reasoning-level high --service-tier fast
Report the new thread ID only.

Compare before adopting

Before wiring this in, compare it with alternatives. Check quality signals: does the skill pin model IDs that match your bb CLI's current catalog? The default gpt-5.6-sol may need updating as versions shift. Look at maintenance freshness: is the repo updated when bb's CLI changes? Compare with bb-cli for status/tell/wait/automations, and with codex-subagent/launch-subagent if your flow is Codex CLI or Cursor Task, not bb threads. Also assess workflow fit: do you want a strict spawn-only skill, or a broader session manager? This one is deliberately minimal, and that is its value.

Why it is worth tracking

bb-subagents is a focused recipe skill, not a platform, and that focus is a good sign: it solves one recurring failure point — spawning bb threads with the right context and stopping. The project has strong community traction (3,828 stars) and is maintained as a small reusable skill rather than a monolith. Track it when you start using bb as your agent runtime, and check back when bb changes its CLI or model defaults. You can see community notes and update signals on the skill's OpenAgentSkill page at https://www.openagentskill.com/skills/davidondrej-bb-subagents to decide when to re-evaluate. For now, it is a low-cost, high-clarity addition to any agent that launches bb threads.