# Jamon's "babysitter" skill ... for Gunship Origins work, but have your agent adapt for your own usage

> Source: <https://gist.github.com/jamonholmgren/2fd1230855402ff158470ddb3c17941d>
> Published: 2026-10-05 15:04:16+00:00

|  | --- | 
|  | name: gso-babysit-external-agents | 
|  | description: Hand Gunship Origins implementation, research, or planning to a cheap in-process babysitter (Sonnet in Claude Code, Terra in Codex) that drives external Jam Session agents (Muse, Cursor Grok, Grok, Devin, and others) from a written plan, so the interactive session keeps its context for Jamon. Use when Jamon asks for a babysitter, cheap agent babysitter, or external agents to do work while he keeps talking with the lead. Do not use for a short task the lead can finish directly, the night-shift queue, or a single summoned agent. | 
|  | --- | 
|  | # Babysit External Agents | 
|  | The interactive session is the supervisor in `$jamsession-orchestrate-agent-work`; the babysitter is its manager; Jam Session agents are workers. This skill adds the Gunship shape. Use concise plain English at every level and require it of every agent. | 
|  | ## Lead: before launch | 
|  | 1. Record Jamon's decisions and the authorized scope in the task worksheet first. The lead owns that worksheet's decision log; the babysitter appends only to its progress or evidence section. | 
|  | 2. Check the repository state the workers will inherit: uncommitted human edits, partial renames, known breakage, an open Godot editor. Put what you find in the plan. | 
|  | 3. Write `.agents/scratch/YYYY-MM/<task>/PLAN.md` (or `BRIEF.md` for research or planning). It must stand alone: | 
|  | - Authorized scope, plus an explicit list of what is not authorized. | 
|  | - Inherited state, and what workers must preserve (Jamon's uncommitted edits, files never to touch). | 
|  | - Ordered steps. Each step lists exact files, the change, the order and behavior checks to report back, done checks, and the local commit message. | 
|  | - The provider assignment table: implementer and a reviewer from a different provider for each step. Use Jamon's named providers; otherwise choose with `$jamsession-model-recommendations`. | 
|  | - The text every worker prompt must carry, and the text every reviewer prompt must carry. | 
|  | - Validation commands: lint, project load, docs lint, focused tests, and 2P pairs as `$gso-test-change` selects. Name the known inherited failures. | 
|  | - Commit authority (local commits on the current branch, never push, unless Jamon says otherwise) and the `REPORT.md` path. | 
|  | 4. Launch one background babysitter: Claude Code uses the Agent tool with `model: sonnet`; Codex uses a Terra subagent. Its prompt points at the plan and the required skills, and asks for a short final summary. Give it nothing the plan does not already hold. | 
|  | ## Babysitter rules (put them in its prompt) | 
|  | - Run `jamsession status` and `jamsession models <provider>` first. Record an unavailable provider in `REPORT.md`; never substitute one silently. | 
|  | - Write shared worker prompt text once (`common.md`, `reviewer-common.md`) and add each step's spec to it. | 
|  | - Run one write-capable worker per checkout at a time. Read-only research or review may run in parallel. Run each long `jamsession run` in the background, with output written to the scratch folder, and wait for its completion notice. | 
|  | - Verify every worker claim with its own diff, grep, and gate runs before accepting the step. Make tiny verified fixes itself; send larger ones back to the same worker session. | 
|  | - Treat HEAD moving, or files changing, as Jamon working in parallel. Never revert, restore, reset, or use bare stash. | 
|  | - Keep `REPORT.md` current after each step: sessions, commits, gates, review findings and how they were handled, and questions for Jamon. | 
|  | ## Lead: while it runs | 
|  | - Read `REPORT.md` and `git log` for status. Never read the babysitter's transcript file. | 
|  | - To add or change scope, record the decision in the worksheet, then message the running babysitter (`SendMessage` in Claude Code). Do not start a second writer in the same checkout. | 
|  | - A second babysitter may run at the same time only when it is read-only, or owns separate files or a separate workspace. | 
|  | - If the harness flags a babysitter (for example a security warning), inspect its prompts, worker output, `REPORT.md`, and `git log` before relaying anything to Jamon. | 
|  | - Relay results in a few lines: commits, gates, findings, and the questions only Jamon can answer. |
