Feature request: `boost detach` / `boost attach` — async background commands for AI agents

[guysoft]

Hi team - opening this as a discussion-friendly proposal. Happy to iterate
on the shape before any code lands.

Right now, every boost-rewritten command blocks the agent, though, if we want to go faster, perhaps we could do stuff in parallel. Moreover, you could forward the output elsewhere for analysis, or for the agent to look at it when they have fresh context after compaction, or a sub agent. A 30-second
npm ci is 30 seconds the agent can't read code, plan, or run anything
else. Add two verbs - detach and attach — and the same agent runs
three builds in parallel, then collects results when they're done:

The idea of how a flow would look, the letters are ids of a run, you can teh attack to an existing run.

you could also add attach --tail, agents seem to assume --tail in commands form what I saw working on GuyIDE.

$ boost detach "npm ci"     → abc123
$ boost detach "pytest"     → def456
$ boost detach "cargo test" → ghi789

# agent reads code, plans, writes a patch... all three commands run concurrently

$ boost attach abc123 && boost attach def456 && boost attach ghi789

Wall-clock goes from sum-of-durations to max-of-durations. This is the
same background-execution pattern that makes Cursor feel fast, but for
every boost-supported agent (Claude Code, Codex, Gemini CLI, OpenCode).

CLI interface

Command	Purpose
boost detach [--timeout N] "<cmd>"	Start in background, return job_id as JSON. Per-job watchdog default 10 min; override with --timeout N (seconds) or disable with --timeout 0.
boost attach <id>	Block until done, print job_id + status + exit_code + duration as JSON. By default the output is metadata-only (small) - pass --tail N, --grep PATTERN, --stderr, or --full to include captured output.
boost attach --last	Attach to the most recently started job (useful when the agent's context dropped the job_id).
boost jobs [--prune <duration>]	List active and recent jobs as JSON; --prune 7d removes job records older than the given age.
boost kill <id>	Terminate a running job. Idempotent - killing an already-finished job is a no-op.

Live streaming (attach --stream) is a natural v2 - out of scope here to
keep v1 small.

Why detach / attach

screen, tmux, and docker attach already make this verb pair
familiar. Two verbs, one happy path - easier for agents to learn than a
larger surface.

Agent integration

Two layers, mirroring how boost already ships skills:

• BOOST.md gains one extra line (~30 tokens, always-on):

  For commands >~5 seconds, prefer boost detach "<cmd>" then
  boost attach <id>. See boost skill detach for the full pattern.

• BOOST_DETACH.md is the on-demand skill loaded via
  boost skill detach. It covers the parallel pattern, output flags,
  timeouts, and a short anti-patterns list. Draft ready to share as a
  follow-up comment if there's interest.

Where the value lands

• Parallel builds/tests at no extra agent cognitive load
• Default 10-minute timeout kills hung commands automatically, can be changed of course
• Purely additive - no existing command behavior changes; doesn't touch
  boost rewrite or per-tool filters
• Could optionally flow into the existing boost query history so
  detached jobs show up alongside synchronous ones

A few things worth discussing

1. Query integration: should detached jobs be visible to
   boost query alongside synchronous commands, or stay in a separate
   listing surfaced only by boost jobs?
2. Auto-detach: should boost rewrite ever auto-detach known-long
   commands (npm ci, pytest, cargo build) without explicit agent opt-in,
   or keep this strictly agent-directed for v1?
3. Cleanup: auto-prune completed jobs after some default age, or
   leave it to a boost jobs --prune <duration> the user runs?
4. Skill loading: is boost skill detach the right surface, or
   should the detach instructions be embedded into the main
   boost skill output as a section?

No strong opinions on these - happy to follow your call.

Out of scope for v1 but you may want -

• Live streaming (attach --stream)
• Auto-detach heuristics
• Cross-machine job persistence
• Concurrent-job limits

---

Happy to follow up with the full BOOST_DETACH.md skill draft, storage
and timeout design notes, and a phased implementation sketch once the
shape is acknowledged. Thanks for considering!