Use when user requests "parallel" commands, running multiple builds/tests simultaneously, or long-running tasks...
gobgob (Background Job Manager) runs tasks asynchronously while keeping context free. Essential for builds, tests, dev servers, and any long-running commands.
When to use:
gob add for eachgob addgob add for eachWhy gob over parallel Bash tool calls: gob provides job IDs, output capture, status monitoring, and proper process control. Parallel Bash calls just fire and forget.
When user says "run X and Y in parallel" or "run two parallel builds":
# ✅ CORRECT: Use gob add for each command
gob add pnpm build
gob add pnpm build
# Then await results
gob await-any
gob await-any
# ❌ WRONG: Do NOT use parallel Bash tool calls
# Bash(pnpm build) + Bash(pnpm build) in same message
Why this matters: Parallel Bash tool calls work but provide no job management. gob gives you job IDs, status checks, output streaming, and the ability to stop/restart jobs.
gob# ❌ BLOCKS: Claude Code waits for this to finish
npm run build
npm test
npm run lint
# Total time: Sequential, slow, context locked
gob# ✅ DISPATCHES: Returns immediately with job IDs
gob add npm run build # Job #1
gob add npm test # Job #2
gob add npm run lint # Job #3
# Continue working while jobs run...
# Then collect results when ready
Key insight: gob add starts a job and returns immediately. You never wait. You work. You collect results later.
Use sequential execution when:
build → test, compile → verify, database migrations → seed data# Dispatch first command
JOB_ID=$(gob add make build)
# Wait for it (blocks here, but only here)
gob await $JOB_ID
# If it passed, dispatch next
JOB_ID_2=$(gob add npm test)
gob await $JOB_ID_2
# Result known, proceed
gob add <command> → returns job ID immediatelygob await <job_id> → streams output, returns exit codeUse parallel execution when:
Good when you have a few known parallel tasks:
# Dispatch all jobs
gob add npm run lint
gob add npm run typecheck
gob add npm test
# Collect results (order doesn't matter)
gob await-any
gob await-any
gob await-any
How it works:
gob add three times → all three start in parallelgob await-any → waits for whichever finishes first, returns resultawait-any three times total to wait for all three jobsGood when you need specific jobs' results:
# Dispatch parallel jobs
LINT_JOB=$(gob add npm run lint)
TYPE_JOB=$(gob add npm run typecheck)
TEST_JOB=$(gob add npm test)
# Wait for specific jobs
gob await $LINT_JOB
gob await $TYPE_JOB
gob await $TEST_JOB
# Check all passed before proceeding
# Dispatch parallel compilation tasks
gob add npm run build:frontend
gob add npm run build:backend
gob add npm run build:types
# Wait for all to complete
gob await-any
gob await-any
gob await-any
# All complete, package everything
gob add npm run package
gob list# Start expensive test suite
TEST_JOB=$(gob add npm run test:integration)
# Implement feature or write docs
# (Tests run in background)
# Check if done:
gob list # See status
# Wait for completion:
gob await $TEST_JOB
gob list
# Wait for job and stream output
gob await <job_id>
# Returns exit code (0 = success, non-zero = failure)
# Graceful stop (allows cleanup)
gob stop <job_id>
# Force kill (immediate termination)
gob stop --force <job_id>
# Stop and restart a specific job
gob restart <job_id>
# Remove a stopped job from list
gob remove <job_id>
# Watch jobs as they run
watch gob list
# Or check once
gob list
gob add for all long-running commands (builds, tests, servers)gob removegob list if uncertain about job status--prompt-only with CLI tools (smaller output)npm run build & - Use gob add npm run build insteadcommand & - gob handles backgrounding# Phase 1: Build must complete first
gob add npm run build
gob await-any
# Phase 2: Run quality checks in parallel (only if build succeeded)
gob add npm run lint
gob add npm run typecheck
gob add npm test
# Phase 3: Wait for all quality checks
gob await-any
gob await-any
gob await-any
# Phase 4: Package only if all checks pass
gob add npm run package
