| name | gob-background-jobs |
| description | Use when user requests "parallel" commands, running multiple builds/tests simultaneously, or long-running tasks. Use `gob add` instead of parallel Bash tool calls - gob provides job management, output capture, and proper process control. |
Managing Background Jobs with gob
Overview
gob (Background Job Manager) runs tasks asynchronously while keeping context free. Essential for builds, tests, dev servers, and any long-running commands.
When to use:
- User explicitly asks for "parallel" or "simultaneous" commands → use
gob addfor each - Long-running command that would block context → use
gob add - Multiple independent commands to run at once → use
gob addfor each
Why 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.
CRITICAL: Parallel Command Requests
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.
Core Concepts
The Problem Without gob
# ❌ BLOCKS: Claude Code waits for this to finish
npm run build
npm test
npm run lint
# Total time: Sequential, slow, context locked
The Solution With 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.
Sequential Execution
Use sequential execution when:
- A command must complete before the next one starts
- Result of one command needed for the next
- Order matters
- Examples:
build→test,compile→verify, database migrations → seed data
Pattern: Sequential with Await
# 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
Process
- Dispatch:
gob add <command>→ returns job ID immediately - Await:
gob await <job_id>→ streams output, returns exit code - Check result: If exit code is 0, continue. If non-zero, handle error
- Next command: Only run next command if previous succeeded
Key Points
- One await per command: Always explicitly wait for sequential commands
- Check exit codes: Know if a command succeeded or failed
- Error handling: Stop on first failure or continue gracefully
- Clear naming: Use descriptive job names in comments
Parallel Execution
Use parallel execution when:
- Commands are independent (don't depend on each other's output)
- Running them together is faster than sequential
- Examples: lint + typecheck, test suite 1 + test suite 2, API build + UI build
Pattern 1: Start All, Await All
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 addthree times → all three start in parallelgob await-any→ waits for whichever finishes first, returns result- Call
await-anythree times total to wait for all three jobs
Pattern 2: Specific Job Await
Good 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
Pattern 3: Parallel Build Steps
# 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
Key Points
- Independence: Jobs truly don't depend on each other
- Dispatch first: Start all jobs before awaiting any
- await-any: Call once per job when using this pattern
- gob list: Check job status anytime with
gob list - Latency: Parallel jobs reduce total time significantly
Common Patterns
Pattern: Long Test Run
# 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
Job Management
View Job Status
gob list
Get Job Output
# Wait for job and stream output
gob await <job_id>
# Returns exit code (0 = success, non-zero = failure)
Stop a Job
# Graceful stop (allows cleanup)
gob stop <job_id>
# Force kill (immediate termination)
gob stop --force <job_id>
Restart a Job
# Stop and restart a specific job
gob restart <job_id>
Remove a Job
# Remove a stopped job from list
gob remove <job_id>
Real-Time Monitoring
# Watch jobs as they run
watch gob list
# Or check once
gob list
Best Practices
✅ DO
- Use
gob addfor all long-running commands (builds, tests, servers) - Dispatch all parallel jobs before awaiting any (maximizes concurrency)
- Check exit codes after sequential operations
- Use descriptive comments to explain job purpose
- Clean up stopped jobs periodically with
gob remove - Monitor with
gob listif uncertain about job status - Use
--prompt-onlywith CLI tools (smaller output)
❌ DON'T
- Don't use
npm run build &- Usegob add npm run buildinstead - Don't use
command &-gobhandles backgrounding - Don't forget to await sequential commands - Result matters
- Don't mix bash backgrounding with gob - Creates confusion
- Don't await the same job twice - Job completes once
- Don't ignore exit codes - Errors need handling
- Don't let job list grow unbounded - Remove completed jobs
Conditional Parallel Execution
# 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