bob

name

bob

description

Proactively offload lighter bounded side jobs to a lower model through the Bob pi extension so the costly main agent keeps context clean. Use often for work that is useful but not worth main-model context/reasoning: file discovery, first-pass review, summarization, simple investigation, verification advice, or small mechanical edits when explicitly safe. Always provide enough context because Bob may not have the main agent's full context.

Bob Skill

Use bob_delegate proactively to offload lighter bounded work to the configured lower model. The purpose is to reduce main-model cost and keep the main session context clean: side investigations, discovery, first-pass reviews, and other non-core work should happen in Bob's collapsed worker branch.

Bob has two modes:

• Synchronous/default: blocks the main session briefly and returns a handoff immediately after the worker branch is collapsed. Use when the result affects the next main-thread decision, plan, or edit.
• Asynchronous/explicit: starts a background lower-model side job in an isolated session, lets the main agent continue, then reports back later with a compact rapport. Use only for independent advisory side work.

Async vs sync governance

Use this decision rule before every delegation:

Can the main agent continue productively if the Bob result arrives late?

• Yes → async is allowed, but must be explicit (async: true). The task is advisory and cannot invalidate the main thread.
• No → use the default sync path (async: false) or do not delegate. The task is a blocking dependency.

Async delegation is only for related-but-non-impacting side work:

• independent reconnaissance
• documentation inventory
• background review of already completed changes
• broad advisory risk scans
• summarizing unrelated docs/logs
• finding possible follow-ups while the main agent works elsewhere

Async can be used strategically for parallelism: delegate focused side tasks in clearly separated areas, then keep the main agent working on the demanding main-thread task in a different area. This is only safe when the side tasks have explicit scopes and cannot collide with the main task or each other.

Use synchronous delegation for anything that affects the main thread:

• choosing between implementation paths
• locating the exact file/function before editing
• validating a plan before coding
• reviewing the same diff/files the main agent is about to modify
• determining whether a change is safe
• any result that would change what the main agent does next

Do not launch async Bob on the same files/problem the main agent is actively editing. That creates stale rapports, duplicate reasoning, and extra main-session reconciliation.

When launching one or more async tasks, include an explicit scope boundary:

• Area/files Bob may inspect.
• Area/files Bob must avoid because the main agent owns them.
• Whether the result is advisory or blocking.
• Whether stale findings are acceptable.

Good parallel async pattern:

bob_delegate({
  task: "Goal: audit docs references for routes.csv. Scope: docs/prompts only. Avoid index.ts and lib/*.ts because main agent is editing runtime code. Advisory only; report broken references and suggested doc edits compactly. Stale findings are acceptable.",
  mode: "analysis",
  allowEdits: false,
  async: true
})

Bad parallel async pattern:

bob_delegate({ task: "Inspect the same retrieval code I am refactoring and tell me what to change." })

If several async tasks are launched, each must have a disjoint scope and should return a compact handle-like report that the main agent can review later without stopping the main thread.

Critical context rule: Bob does not inherit the main agent's full working context or loaded skills. Every delegated task must be self-contained enough to succeed without relying on unstated conversation details.

Critical skill rule: If the delegated task requires an existing agent skill, include the absolute path to that skill's SKILL.md in the Bob task and instruct Bob to read it first. If the skill references relative resources, tell Bob to resolve them relative to the skill directory.

Critical reporting rule: Bob must report back compactly. The main agent should be able to quickly see what was done, what changed, what was read, what failed, and what to do next without inspecting the raw worker branch.

Use Bob for

• File discovery and route mapping
• First-pass code review or diff review
• Summarizing docs, logs, or prior findings
• Focused investigation of a small bug area
• Verification/test command suggestions
• Any side job that is useful but should not pollute main context
• Small mechanical edits only when clearly safe and explicitly allowed

Do not use Bob for

• High-risk architecture decisions
• Security-sensitive changes
• Broad refactors without a tight scope
• Database migrations or production deployment steps
• Tasks requiring user judgment or credentials

Context packet requirement

When delegating, include a compact context packet in the task string:

• Goal: what Bob must accomplish
• Required skills: absolute SKILL.md paths, if any; instruct Bob to read and follow them first
• Relevant files/paths already known
• Scope: allowed area/files and avoided area/files
• Mode semantics: advisory async or blocking sync
• Current hypothesis or constraints
• What is allowed, especially whether edits are allowed
• Expected compact report/handoff format
• Staleness/race tolerance for async tasks
• Verification command(s), if known

Standard task packet template:

Goal: <what Bob must accomplish>

Required skills:
- Read and follow /absolute/path/to/SKILL.md before acting.

Context:
- <relevant background, hypotheses, constraints>

Scope:
- Allowed: <files/areas Bob may inspect or edit>
- Avoid: <files/areas owned by the main agent or other side jobs>

Mode semantics:
- Advisory async: result may arrive later and should not block main-thread work.
- Blocking sync: result affects current plan/edit/final answer; use async:false.

Permissions:
- Edits: allowed | not allowed

Expected handoff:
- Outcome
- Files read/changed
- Validation
- Blockers
- Staleness/race risk
- Recommended next action

Bad delegation:

bob_delegate({ task: "review this", mode: "review" })

Good delegation:

bob_delegate({
  task: "Goal: review the current auth diff for obvious bugs. Context: we changed apps/web/src/auth/session.ts to alter JWT expiry handling; user is worried about regressions. Scope: inspect git diff and nearby tests only. Do not edit files. Report back compactly with: what you checked, issues found, files read, missing tests, and exact verification commands.",
  mode: "review",
  allowEdits: false
})

Tool pattern

Default to no edits:

bob_delegate({
  task: "Goal: find the files involved in X and summarize likely change points. Context: <include relevant feature/module/user request details>. Required skills: if applicable, read /absolute/path/to/SKILL.md first and follow it. Scope: discovery only; do not edit. Output: files, why they matter, recommended next step.",
  mode: "analysis",
  allowEdits: false
})

For review:

bob_delegate({
  task: "Goal: review the current diff for obvious bugs and missing tests. Context: <summarize what the main agent changed and why>. Scope: git diff plus directly related files. Do not edit. Output: prioritized issues and verification commands.",
  mode: "review",
  allowEdits: false
})

For safe mechanical edits only:

bob_delegate({
  task: "Goal: rename helper oldName to newName. Context: helper is local to path/to/file.ts and direct references are expected only in path/to/folder. Scope: mechanical rename only; no behavior changes. Edits allowed. Output: changed files and validation command.",
  mode: "edit",
  allowEdits: true
})

Main-agent responsibilities

• Use Bob often for bounded lower-complexity side jobs instead of spending main-model effort.
• Sync is the default.
• Use async: true only for genuinely independent side jobs where stale findings are acceptable.
• Keep async: false whenever the result can affect the current plan, file selection, edit, or final answer.
• Use Bob to keep the main context clean; avoid pulling noisy side investigation into the main branch.
• Keep Bob tasks bounded, specific, and self-contained.
• For async parallel work, define disjoint scopes so side jobs do not overlap with the main edit path or each other.
• Include enough context for Bob to succeed without hidden conversation state.
• If a task depends on a skill the main agent knows about, pass the absolute SKILL.md path in the task and explicitly tell Bob to read it first.
• Ask Bob for a compact report: what was done, files read/changed, validation, blockers, next action.
• Inspect the handoff before acting on it.
• Verify any Bob edits yourself with appropriate tests/typecheck.
• Do not delegate final judgment; Bob is a worker, not the owner.