@a5c-ai/babysitter-gemini-cli 5.0.1-staging.686c8b317 → 5.0.1-staging.7495ef6c9fa0

package/README.md

@@ -4,10 +4,10 @@ Orchestrate complex, multi-step workflows with event-sourced state management, h
 
 ## Prerequisites
 
-Install the Babysitter SDK CLI:
+Install the Babysitter CLI once. The `babysitter` command is backed by the SDK and exposes the canonical harness/plugin installer used in tests:
 
 ```bash
-npm install -g @a5c-ai/babysitter-sdk
+npm install -g @a5c-ai/babysitter
 ```
 
 ## Installation — Gemini CLI
@@ -19,6 +19,13 @@ babysitter-gemini-cli install --global
 
 Restart Gemini CLI to pick up the installed plugin.
 
+For scriptable installs, prefer the SDK helper shape:
+
+```bash
+babysitter harness:install-plugin <harness>
+babysitter harness:install-plugin <harness> --workspace /path/to/repo
+```
+
 ## What's Included
 
 - **Skills**: babysit

package/bin/install-shared.js

@@ -104,7 +104,7 @@ function ensureMarketplaceEntry(marketplacePath, pluginRoot) {
     name: PLUGIN_NAME,
     source: relSource,
     description: "Orchestrate complex, multi-step workflows with event-sourced state management, hook-based extensibility, and human-in-the-loop approval",
-    version: "5.0.1-staging.686c8b317",
+    version: "5.0.1-staging.7495ef6c9fa0",
     author: { name: "a5c.ai" },
   };
   if (idx >= 0) marketplace.plugins[idx] = entry;

package/commands/call.toml

@@ -1,3 +1,3 @@
 description = "Orchestrate a babysitter run. use this command to start babysitting a complex workflow."
 
-prompt = "Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md)."
+prompt = "Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md). Then continue executing the returned instructions in this same turn. Do not stop after the Skill tool returns; carry the requested run through to completion proof.\n\nUser arguments for this command:\n\n$ARGUMENTS"

package/commands/help.toml

@@ -1,3 +1,3 @@
 description = "help and documentation for babysitter command usage, processes, skills, agents, and methodologies. use this command to understand how to use babysitter effectively."
 
-prompt = "## if no arguments provided:\n\nshow this message:\n\n```\nWelcome to the Babysitter Help Center! Here you can find documentation and guidance on how to use Babysitter effectively.\n\nDocumentation: Explore our comprehensive documentation to understand Babysitter's features, processes, skills, agents, and methodologies. Read the Docs: https://github.com/a5c-ai/babysitter\n\nOr ask specific questions about commands, processes, skills, agents, methodologies, domains, specialities to get targeted help.\n\nJust type /babysitter:help followed by your question or the topic you want to learn more about.\n\n\nPRIMARY COMMANDS\n================\n\n/babysitter:call [input]\n  Start a babysitter-orchestrated run. Babysitter analyzes your request, interviews you\n  to gather requirements, selects or creates the best process definition (from 50+\n  domain-specific processes covering science, business, engineering, and more), then\n  executes it step by step with breakpoints where you can steer direction.\n\n  How it works: The babysitter skill reads your input, explores the process library to\n  find matching processes, interviews you to refine scope, creates an SDK run with\n  run:create, and orchestrates iterations with run:iterate -- dispatching tasks,\n  handling breakpoints, and posting results until the run completes or you pause it.\n\n  Example: /babysitter:call migrate our Express.js REST API to Fastify, keeping all\n  existing routes and middleware behavior identical, with integration tests proving\n  parity\n\n\n/babysitter:resume [run id or name]\n  Resume a paused or interrupted babysitter run. If you don't specify a run, babysitter\n  discovers all runs under .a5c/runs/, shows their status (created, waiting, completed,\n  failed), and suggests which incomplete run to pick up based on its process, pending\n  effects, and last activity.\n\n  How it works: Reads run metadata and journal, rebuilds state cache if stale, identifies\n  pending effects (breakpoints awaiting approval, tasks needing results), and continues\n  orchestration from exactly where it left off -- no work is repeated thanks to the\n  replay engine.\n\n  Example: /babysitter:resume\n  (discovers runs and offers: \"Run abc123 is waiting on a breakpoint in the 'review\n  test results' phase of your API migration -- resume this one?\")\n\n\n/babysitter:yolo [input]\n  Start a babysitter run in fully autonomous mode. Identical to /call but all breakpoints\n  are auto-approved and no user interaction is requested. The babysitter makes every\n  decision on its own until the run completes or hits a critical failure it can't recover\n  from. Best for well-understood tasks where you trust the process.\n\n  How it works: Same orchestration as /call, but the process context is configured to\n  skip breakpoint effects -- instead of pausing for human approval, each breakpoint\n  resolves immediately with an auto-approve result.\n\n  Example: /babysitter:yolo add comprehensive unit tests for all functions in\n  src/utils/ using vitest with >90% branch coverage\n\n\n/babysitter:plan [input]\n  Generate a detailed execution plan without running anything. Babysitter goes through\n  the full interview and process selection flow, designs the process definition with\n  all tasks, breakpoints, and dependencies, but stops before creating the actual SDK run.\n  You get a complete plan you can review, modify, or execute later with /call.\n\n  How it works: Runs the babysitter skill's planning phase only -- analyzes input,\n  matches to domain processes, interviews for requirements, then outputs the process\n  definition file and a human-readable execution plan showing each phase, task, and\n  decision point.\n\n  Example: /babysitter:plan redesign our database schema to support multi-tenancy,\n  migrate existing data, and update all queries -- I want to review the plan before\n  we touch anything\n\n\n/babysitter:forever [input]\n  Start a babysitter run that loops indefinitely with sleep intervals. Designed for\n  ongoing operational tasks: monitoring, periodic maintenance, continuous improvement,\n  or recurring workflows. The process uses an infinite loop with ctx.sleepUntil() to\n  pause between iterations.\n\n  How it works: Creates a process definition with a while(true) loop. Each cycle performs\n  the task (e.g., check metrics, process tickets, run audits), then calls ctx.sleepUntil()\n  to pause for a configured interval. The run stays in \"waiting\" state during sleep and\n  resumes automatically when the sleep expires on the next orchestration iteration.\n\n  Example: /babysitter:forever every 4 hours, check our GitHub issues labeled \"bug\",\n  attempt to reproduce and fix any that look straightforward, and submit PRs for the fixes\n\n\nSECONDARY COMMANDS\n==================\n\n/babysitter:doctor [issue]\n  Run a comprehensive 10-point health check on a babysitter run. Inspects journal\n  integrity (checksum verification, sequence gaps, timestamp ordering), state cache\n  consistency, stuck/errored effects, stale locks, session state, log files, disk usage,\n  process validation, and hook execution health. Produces a structured diagnostic report\n  with PASS/WARN/FAIL status per check and specific fix commands.\n\n  If no run ID is provided, automatically targets the most recent run. Can also diagnose\n  environment-wide issues like missing CLI, unregistered hooks, or plugin problems.\n\n  Example: /babysitter:doctor\n  (checks the latest run: \"CRITICAL -- Check 5 Lock Status: FAIL -- stale lock detected,\n  process 12847 is no longer running. Fix: rm .a5c/runs/abc123/run.lock\")\n\n\n/babysitter:assimilate [target]\n  Convert an external methodology, AI coding harness, or specification into native\n  babysitter process definitions. Takes a GitHub repo URL, harness name, or spec file\n  and produces a complete process package with skills/ and agents/ directories.\n\n  Two workflows available:\n  - Methodology assimilation: clones the repo, learns its procedures and commands,\n    converts manual flows into babysitter processes with refactored skills and agents\n  - Harness integration: wires babysitter's SDK into a specific AI coding tool\n    (codex, opencode, gemini-cli, antigravity, etc.) so it can orchestrate runs\n\n  Example: /babysitter:assimilate https://github.com/some-org/their-deployment-playbook\n  (clones the repo, analyzes their deployment procedures, and generates babysitter\n  processes that replicate the same workflow with proper task definitions and breakpoints)\n\n\n/babysitter:user-install\n  First-time onboarding for new babysitter users. Installs dependencies, runs an\n  interactive interview about your development specialties, preferred tools, coding\n  style, and how much autonomy you want babysitter to have. Builds a user profile\n  stored at ~/.a5c/user-profile.json that personalizes future runs.\n\n  Uses the cradle/user-install process which covers: dependency verification, user\n  interview (expertise areas, preferred languages, IDE, terminal setup), profile\n  generation, tool configuration, and optional global plugin installation.\n\n  Example: /babysitter:user-install\n  (walks you through: \"What's your primary programming language? What frameworks do\n  you use most? Do you prefer babysitter to auto-approve routine tasks or always ask?\")\n\n\n/babysitter:project-install\n  Onboard a new or existing project for babysitter orchestration. Researches the\n  codebase (reads package.json, scans directory structure, identifies frameworks and\n  patterns), interviews you about project goals and workflows, generates a project\n  profile at .a5c/project-profile.json, and optionally sets up CI/CD integration.\n\n  Uses the cradle/project-install process which covers: codebase analysis, project\n  interview, profile creation, recommended plugin installation, hook configuration,\n  and optional CI pipeline setup.\n\n  Example: /babysitter:project-install\n  (scans your repo: \"I see this is a Next.js 16 app with Tailwind, using vitest for\n  tests and PostgreSQL. What are your main development goals for this project?\")\n\n\n/babysitter:retrospect [run id or name]\n  Analyze a completed run to extract lessons and improve future runs. Reviews what\n  happened (journal events, task results, timing, errors), evaluates the process that\n  was followed, and suggests concrete improvements to process definitions, skills,\n  and agents. Interactive -- multiple breakpoints let you steer the analysis and\n  decide which improvements to implement.\n\n  Covers: run result analysis, process effectiveness review, improvement suggestions,\n  implementation of changes, and routing to /contrib if improvements belong in the\n  shared process library.\n\n  Example: /babysitter:retrospect\n  (analyzes the last run: \"The API migration run completed but the 'verify parity'\n  phase took 8 iterations because test assertions were too brittle. Suggestion: add\n  a fuzzy comparison step before strict assertion. Implement this fix?\")\n\n\n/babysitter:plugins [action]\n  Manage babysitter plugins: list installed plugins, browse marketplaces, install,\n  update, configure, uninstall, or create new plugins. Plugins are version-managed\n  instruction packages (not executable code) that guide the agent through install,\n  configure, and uninstall steps via markdown files.\n\n  Without arguments: shows installed plugins (name, version, marketplace, dates) and\n  available marketplaces. With arguments: routes to the specific action.\n\n  Key actions:\n  - install <name> --global|--project: fetch install.md from marketplace and execute\n  - configure <name> --global|--project: fetch configure.md and walk through options\n  - update <name> --global|--project: resolve migration chain via BFS and apply steps\n  - uninstall <name> --global|--project: fetch uninstall.md and execute removal\n  - create: scaffold a new plugin package with the meta/plugin-creation process\n\n  Example: /babysitter:plugins install sound-hooks --project\n  (fetches sound-hooks from marketplace, reads install.md, walks you through player\n  detection, sound selection, hook configuration, and registers in plugin-registry.json)\n\n\n/babysitter:contrib [feedback]\n  Submit feedback or contribute to the babysitter project. Routes to the appropriate\n  workflow based on what you want to do:\n\n  Issue-based (opens GitHub issue in a5c-ai/babysitter):\n  - Bug report: describe a bug in the SDK, CLI, or process library\n  - Feature request: propose a new feature or enhancement\n  - Documentation question: flag undocumented behavior or missing docs\n\n  PR-based (forks repo, creates branch, submits PR):\n  - Bugfix: you already have a fix ready\n  - Feature implementation: you've built a new feature\n  - Library contribution: new or improved process/skill/agent for the library\n  - Harness integration: CI/CD or IDE integration\n\n  Without arguments: shows all contribution types and helps you pick the right one.\n  Breakpoints are placed before all GitHub actions (fork, star, PR, issue) so you\n  can review before anything is submitted.\n\n  Example: /babysitter:contrib bug report: plugin:update-registry fails when the\n  marketplace hasn't been cloned yet, even though the registry update doesn't need\n  marketplace access\n\n\n/babysitter:observe\n  Launch the babysitter observer dashboard -- a real-time web UI that monitors active\n  and past runs. Displays task progress, journal events, orchestration state, and\n  effect status in your browser. Useful when running /yolo or /forever to watch\n  progress without interrupting the run.\n\n  How it works: Runs npx @a5c-ai/babysitter-observer-dashboard@latest which watches\n  the .a5c/runs/ directory (or a parent directory containing multiple projects) and\n  serves a live dashboard. The process is blocking -- it runs until you stop it, and\n  it prints the local URL to share with the user.\n\n  Example: /babysitter:observe\n  (opens browser showing all runs with live-updating task\n  status, journal event stream, and effect resolution timeline)\n```\n\n## if arguments provided:\n\nif the argument is \"command [command name]\", \"process [process name]\", \"skill [skill name]\", \"agent [agent name]\", or \"methodology [methodology name]\", then show the detailed documentation for that specific command, process, skill, agent, or methodology after reading the relevant files."
+prompt = "## if no arguments provided:\n\nshow this message:\n\n```\nWelcome to the Babysitter Help Center! Here you can find documentation and guidance on how to use Babysitter effectively.\n\nDocumentation: Explore our comprehensive documentation to understand Babysitter's features, processes, skills, agents, and methodologies. Read the Docs: https://github.com/a5c-ai/babysitter\n\nOr ask specific questions about commands, processes, skills, agents, methodologies, domains, specialities to get targeted help.\n\nJust type /babysitter:help followed by your question or the topic you want to learn more about.\n\n\nPRIMARY COMMANDS\n================\n\n/babysitter:call [input]\n  Start a babysitter-orchestrated run. Babysitter analyzes your request, interviews you\n  to gather requirements, selects or creates the best process definition (from 50+\n  domain-specific processes covering science, business, engineering, and more), then\n  executes it step by step with breakpoints where you can steer direction.\n\n  How it works: The babysitter skill reads your input, explores the process library to\n  find matching processes, interviews you to refine scope, creates an SDK run with\n  run:create, and orchestrates iterations with run:iterate -- dispatching tasks,\n  handling breakpoints, and posting results until the run completes or you pause it.\n\n  Example: /babysitter:call migrate our Express.js REST API to Fastify, keeping all\n  existing routes and middleware behavior identical, with integration tests proving\n  parity\n\n\n/babysitter:resume [run id or name]\n  Resume a paused or interrupted babysitter run. If you don't specify a run, babysitter\n  discovers all runs under .a5c/runs/, shows their status (created, waiting, completed,\n  failed), and suggests which incomplete run to pick up based on its process, pending\n  effects, and last activity.\n\n  How it works: Reads run metadata and journal, rebuilds state cache if stale, identifies\n  pending effects (breakpoints awaiting approval, tasks needing results), and continues\n  orchestration from exactly where it left off -- no work is repeated thanks to the\n  replay engine.\n\n  Example: /babysitter:resume\n  (discovers runs and offers: \"Run abc123 is waiting on a breakpoint in the 'review\n  test results' phase of your API migration -- resume this one?\")\n\n\n/babysitter:yolo [input]\n  Start a babysitter run in fully autonomous mode. Identical to /call but all breakpoints\n  are auto-approved and no user interaction is requested. The babysitter makes every\n  decision on its own until the run completes or hits a critical failure it can't recover\n  from. Best for well-understood tasks where you trust the process.\n\n  How it works: Same orchestration as /call, but the process context is configured to\n  skip breakpoint effects -- instead of pausing for human approval, each breakpoint\n  resolves immediately with an auto-approve result.\n\n  Example: /babysitter:yolo add comprehensive unit tests for all functions in\n  src/utils/ using vitest with >90% branch coverage\n\n\n/babysitter:plan [input]\n  Generate a detailed execution plan without running anything. Babysitter goes through\n  the full interview and process selection flow, designs the process definition with\n  all tasks, breakpoints, and dependencies, but stops before creating the actual SDK run.\n  You get a complete plan you can review, modify, or execute later with /call.\n\n  How it works: Runs the babysitter skill's planning phase only -- analyzes input,\n  matches to domain processes, interviews for requirements, then outputs the process\n  definition file and a human-readable execution plan showing each phase, task, and\n  decision point.\n\n  Example: /babysitter:plan redesign our database schema to support multi-tenancy,\n  migrate existing data, and update all queries -- I want to review the plan before\n  we touch anything\n\n\n/babysitter:forever [input]\n  Start a babysitter run that loops indefinitely with sleep intervals. Designed for\n  ongoing operational tasks: monitoring, periodic maintenance, continuous improvement,\n  or recurring workflows. The process uses an infinite loop with ctx.sleepUntil() to\n  pause between iterations.\n\n  How it works: Creates a process definition with a while(true) loop. Each cycle performs\n  the task (e.g., check metrics, process tickets, run audits), then calls ctx.sleepUntil()\n  to pause for a configured interval. The run stays in \"waiting\" state during sleep and\n  resumes automatically when the sleep expires on the next orchestration iteration.\n\n  Example: /babysitter:forever every 4 hours, check our GitHub issues labeled \"bug\",\n  attempt to reproduce and fix any that look straightforward, and submit PRs for the fixes\n\n\nSECONDARY COMMANDS\n==================\n\n/babysitter:doctor [issue]\n  Run a comprehensive 10-point health check on a babysitter run. Inspects journal\n  integrity (checksum verification, sequence gaps, timestamp ordering), state cache\n  consistency, stuck/errored effects, stale locks, session state, log files, disk usage,\n  process validation, and hook execution health. Produces a structured diagnostic report\n  with PASS/WARN/FAIL status per check and specific fix commands.\n\n  If no run ID is provided, automatically targets the most recent run. Can also diagnose\n  environment-wide issues like missing CLI, unregistered hooks, or plugin problems.\n\n  Example: /babysitter:doctor\n  (checks the latest run: \"CRITICAL -- Check 5 Lock Status: FAIL -- stale lock detected,\n  process 12847 is no longer running. Fix: rm .a5c/runs/abc123/run.lock\")\n\n\n/babysitter:assimilate [target]\n  Convert an external methodology, AI coding harness, or specification into native\n  babysitter process definitions. Takes a GitHub repo URL, harness name, or spec file\n  and produces a complete process package with skills/ and agents/ directories.\n\n  Two workflows available:\n  - Methodology assimilation: clones the repo, learns its procedures and commands,\n    converts manual flows into babysitter processes with refactored skills and agents\n  - Harness integration: wires babysitter's SDK into a specific AI coding tool\n    (codex, opencode, gemini-cli, antigravity, etc.) so it can orchestrate runs\n\n  Example: /babysitter:assimilate https://github.com/some-org/their-deployment-playbook\n  (clones the repo, analyzes their deployment procedures, and generates babysitter\n  processes that replicate the same workflow with proper task definitions and breakpoints)\n\n\n/babysitter:user-install\n  First-time onboarding for new babysitter users. Installs dependencies, runs an\n  interactive interview about your development specialties, preferred tools, coding\n  style, and how much autonomy you want babysitter to have. Builds a user profile\n  stored at ~/.a5c/user-profile.json that personalizes future runs.\n\n  Uses the cradle/user-install process which covers: dependency verification, user\n  interview (expertise areas, preferred languages, IDE, terminal setup), profile\n  generation, tool configuration, and optional global plugin installation.\n\n  Example: /babysitter:user-install\n  (walks you through: \"What's your primary programming language? What frameworks do\n  you use most? Do you prefer babysitter to auto-approve routine tasks or always ask?\")\n\n\n/babysitter:project-install\n  Onboard a new or existing project for babysitter orchestration. Researches the\n  codebase (reads package.json, scans directory structure, identifies frameworks and\n  patterns), interviews you about project goals and workflows, generates a project\n  profile at .a5c/project-profile.json, and optionally sets up CI/CD integration.\n\n  Uses the cradle/project-install process which covers: codebase analysis, project\n  interview, profile creation, recommended plugin installation, hook configuration,\n  and optional CI pipeline setup.\n\n  Example: /babysitter:project-install\n  (scans your repo: \"I see this is a Next.js 16 app with Tailwind, using vitest for\n  tests and PostgreSQL. What are your main development goals for this project?\")\n\n\n/babysitter:retrospect [run id or name]\n  Analyze a completed run to extract lessons and improve future runs. Reviews what\n  happened (journal events, task results, timing, errors), evaluates the process that\n  was followed, and suggests concrete improvements to process definitions, skills,\n  and agents. Interactive -- multiple breakpoints let you steer the analysis and\n  decide which improvements to implement.\n\n  Covers: run result analysis, process effectiveness review, improvement suggestions,\n  implementation of changes, and routing to /contrib if improvements belong in the\n  shared process library.\n\n  Example: /babysitter:retrospect\n  (analyzes the last run: \"The API migration run completed but the 'verify parity'\n  phase took 8 iterations because test assertions were too brittle. Suggestion: add\n  a fuzzy comparison step before strict assertion. Implement this fix?\")\n\n\n/babysitter:plugins [action]\n  Manage babysitter plugins: list installed plugins, browse marketplaces, install,\n  update, configure, uninstall, or create new plugins. Plugins are version-managed\n  instruction packages (not executable code) that guide the agent through install,\n  configure, and uninstall steps via markdown files.\n\n  Without arguments: shows installed plugins (name, version, marketplace, dates) and\n  available marketplaces. With arguments: routes to the specific action.\n\n  Key actions:\n  - install <name> --global|--project: fetch install.md from marketplace and execute\n  - configure <name> --global|--project: fetch configure.md and walk through options\n  - update <name> --global|--project: resolve migration chain via BFS and apply steps\n  - uninstall <name> --global|--project: fetch uninstall.md and execute removal\n  - create: scaffold a new plugin package with the meta/plugin-creation process\n\n  Example: /babysitter:plugins install sound-hooks --project\n  (fetches sound-hooks from marketplace, reads install.md, walks you through player\n  detection, sound selection, hook configuration, and registers in plugin-registry.json)\n\n\n/babysitter:contrib [feedback]\n  Submit feedback or contribute to the babysitter project. Routes to the appropriate\n  workflow based on what you want to do:\n\n  Issue-based (opens GitHub issue in a5c-ai/babysitter):\n  - Bug report: describe a bug in the SDK, CLI, or process library\n  - Feature request: propose a new feature or enhancement\n  - Documentation question: flag undocumented behavior or missing docs\n\n  PR-based (forks repo, creates branch, submits PR):\n  - Bugfix: you already have a fix ready\n  - Feature implementation: you've built a new feature\n  - Library contribution: new or improved process/skill/agent for the library\n  - Harness integration: CI/CD or IDE integration\n\n  Without arguments: shows all contribution types and helps you pick the right one.\n  Breakpoints are placed before all GitHub actions (fork, star, PR, issue) so you\n  can review before anything is submitted.\n\n  Example: /babysitter:contrib bug report: plugin:update-registry fails when the\n  marketplace hasn't been cloned yet, even though the registry update doesn't need\n  marketplace access\n\n\n/babysitter:observe\n  Launch the babysitter observer dashboard -- a real-time web UI that monitors active\n  and past runs. Displays task progress, journal events, orchestration state, and\n  effect status in your browser. Useful when running /yolo or /forever to watch\n  progress without interrupting the run.\n\n  How it works: Runs npx @a5c-ai/babysitter-observer-dashboard@latest which watches\n  the .a5c/runs/ directory (or a parent directory containing multiple projects) and\n  serves a live dashboard. The process is blocking -- it runs until you stop it, and\n  it prints the local URL to share with the user. Do not use `babysitter observe`\n  as a fallback; the core Babysitter CLI does not expose that subcommand.\n\n  Example: /babysitter:observe\n  (opens browser showing all runs with live-updating task\n  status, journal event stream, and effect resolution timeline)\n```\n\n## if arguments provided:\n\nif the argument is \"command [command name]\", \"process [process name]\", \"skill [skill name]\", \"agent [agent name]\", or \"methodology [methodology name]\", then show the detailed documentation for that specific command, process, skill, agent, or methodology after reading the relevant files."

package/commands/observe.toml

@@ -1,3 +1,3 @@
 description = "Launch the babysitter observer dashboard. Installs and runs the real-time observer UI that watches babysitter runs, displaying task progress, journal events, and orchestration state in your browser."
 
-prompt = "Run the babysitter observer dashboard:\n\n1. Determine the watch directory — this is usually the project's container directory (the parent of the project dir), or the current working directory if not specified.\n2. Launch the dashboard: `npx -y @a5c-ai/babysitter-observer-dashboard@latest --watch-dir <dir>`\n3. This is a blocking process — it will keep running until stopped.\n4. Report the URL printed by the dashboard to the user, then open it in the browser."
+prompt = "Run the babysitter observer dashboard:\n\n1. Determine the watch directory — this is usually the project's container directory (the parent of the project dir), or the current working directory if not specified.\n2. Launch the standalone dashboard package: `npx -y @a5c-ai/babysitter-observer-dashboard@latest --watch-dir <dir>`.\n3. This is a blocking process — it will keep running until stopped.\n4. Report the URL printed by the dashboard to the user, then open it in the browser.\n\nDo not fall back to `babysitter observe`; the core Babysitter CLI does not expose\nthat subcommand. Some harness runtimes may provide a separate\n`agent-platform observe` surface, but this skill uses the verified standalone\ndashboard package."

package/commands/yolo.toml

@@ -1,3 +1,3 @@
 description = "Orchestrate a babysitter run. use this command to start babysitting a complex workflow in a non-interactive mode, without any user interaction or breakpoints in the run."
 
-prompt = "Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md). but without any user interaction or breakpoints in the run."
+prompt = "Run the Babysitter orchestration instructions directly through the CLI, without any user interaction or breakpoints. In Claude Code, use Bash to run `babysitter instructions:babysit-skill --harness claude-code --no-interactive`; in Codex, run `babysitter instructions:babysit-skill --harness codex --no-interactive`; in other harnesses, use the same command with that harness id. Then follow the returned instructions in this same turn until completion proof is produced. Do not stop after reading the instructions, do not invoke the Skill tool first, and use the non-interactive/no-breakpoints path when the instructions offer a mode choice.\n\nUser arguments for this command:\n\n$ARGUMENTS"

package/hooks/hooks.json

@@ -7,7 +7,7 @@
           {
             "name": "babysitter-session-start",
             "type": "command",
-            "command": "npx -y -p @a5c-ai/hooks-mux-cli -c \"a5c-hooks-mux invoke --adapter gemini --handler 'bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-session-start.sh' --json\"",
+            "command": "a5c-hooks-mux invoke --adapter gemini --handler \"bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-session-start.sh\" --json",
             "timeout": 30000,
             "description": "babysitter SessionStart hook"
           }
@@ -20,7 +20,7 @@
           {
             "name": "babysitter-user-prompt-submit",
             "type": "command",
-            "command": "npx -y -p @a5c-ai/hooks-mux-cli -c \"a5c-hooks-mux invoke --adapter gemini --handler 'bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-user-prompt-submit.sh' --json\"",
+            "command": "a5c-hooks-mux invoke --adapter gemini --handler \"bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-user-prompt-submit.sh\" --json",
             "timeout": 30000,
             "description": "babysitter UserPromptSubmit hook"
           }
@@ -33,7 +33,7 @@
           {
             "name": "babysitter-pre-tool-use",
             "type": "command",
-            "command": "npx -y -p @a5c-ai/hooks-mux-cli -c \"a5c-hooks-mux invoke --adapter gemini --handler 'bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-before-tool.sh' --json\"",
+            "command": "a5c-hooks-mux invoke --adapter gemini --handler \"bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-before-tool.sh\" --json",
             "timeout": 30000,
             "description": "babysitter PreToolUse hook"
           }
@@ -46,7 +46,7 @@
           {
             "name": "babysitter-post-tool-use",
             "type": "command",
-            "command": "npx -y -p @a5c-ai/hooks-mux-cli -c \"a5c-hooks-mux invoke --adapter gemini --handler 'bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-after-tool.sh' --json\"",
+            "command": "a5c-hooks-mux invoke --adapter gemini --handler \"bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-after-tool.sh\" --json",
             "timeout": 30000,
             "description": "babysitter PostToolUse hook"
           }
@@ -59,7 +59,7 @@
           {
             "name": "babysitter-pre-compact",
             "type": "command",
-            "command": "npx -y -p @a5c-ai/hooks-mux-cli -c \"a5c-hooks-mux invoke --adapter gemini --handler 'bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-pre-compact.sh' --json\"",
+            "command": "a5c-hooks-mux invoke --adapter gemini --handler \"bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-pre-compact.sh\" --json",
             "timeout": 30000,
             "description": "babysitter PreCompact hook"
           }
@@ -72,7 +72,7 @@
           {
             "name": "babysitter-after-agent",
             "type": "command",
-            "command": "npx -y -p @a5c-ai/hooks-mux-cli -c \"a5c-hooks-mux invoke --adapter gemini --handler 'bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-after-agent.sh' --json\"",
+            "command": "a5c-hooks-mux invoke --adapter gemini --handler \"bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-after-agent.sh\" --json",
             "timeout": 30000,
             "description": "babysitter AfterAgent hook"
           }
@@ -85,7 +85,7 @@
           {
             "name": "babysitter-session-end",
             "type": "command",
-            "command": "npx -y -p @a5c-ai/hooks-mux-cli -c \"a5c-hooks-mux invoke --adapter gemini --handler 'bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-session-end.sh' --json\"",
+            "command": "a5c-hooks-mux invoke --adapter gemini --handler \"bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-session-end.sh\" --json",
             "timeout": 30000,
             "description": "babysitter SessionEnd hook"
           }
@@ -98,7 +98,7 @@
           {
             "name": "babysitter-session-idle",
             "type": "command",
-            "command": "npx -y -p @a5c-ai/hooks-mux-cli -c \"a5c-hooks-mux invoke --adapter gemini --handler 'bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-session-idle.sh' --json\"",
+            "command": "a5c-hooks-mux invoke --adapter gemini --handler \"bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-session-idle.sh\" --json",
             "timeout": 30000,
             "description": "babysitter SessionIdle hook"
           }
@@ -111,7 +111,7 @@
           {
             "name": "babysitter-shell-env",
             "type": "command",
-            "command": "npx -y -p @a5c-ai/hooks-mux-cli -c \"a5c-hooks-mux invoke --adapter gemini --handler 'bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-shell-env.sh' --json\"",
+            "command": "a5c-hooks-mux invoke --adapter gemini --handler \"bash ${GEMINI_EXTENSION_PATH}/hooks/babysitter-proxied-shell-env.sh\" --json",
             "timeout": 30000,
             "description": "babysitter ShellEnv hook"
           }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@a5c-ai/babysitter-gemini-cli",
-  "version": "5.0.1-staging.686c8b317",
+  "version": "5.0.1-staging.7495ef6c9fa0",
   "description": "Orchestrate complex, multi-step workflows with event-sourced state management, hook-based extensibility, and human-in-the-loop approval",
   "scripts": {
     "deploy": "npm publish --access public",
@@ -34,7 +34,7 @@
     "access": "public"
   },
   "dependencies": {
-    "@a5c-ai/babysitter-sdk": "5.0.1-staging.686c8b317"
+    "@a5c-ai/babysitter-sdk": "5.0.1-staging.7495ef6c9fa0"
   },
   "repository": {
     "type": "git",

package/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "babysitter",
-  "version": "5.0.1-staging.686c8b317",
+  "version": "5.0.1-staging.7495ef6c9fa0",
   "description": "Orchestrate complex, multi-step workflows with event-sourced state management, hook-based extensibility, and human-in-the-loop approval",
   "author": "a5c.ai",
   "license": "MIT",

package/skills/babysit/SKILL.md

@@ -1,13 +1,24 @@
 ---
 name: babysit
-description: Orchestrate via @babysitter. Use this skill when asked to babysit a run, orchestrate a process or whenever it is called explicitly. (babysit, babysitter, orchestrate, orchestrate a run, workflow, etc.)
+description: Execute via @babysitter. Use this skill when asked to babysit a task, do anything that is structured process-driven (even a loop) or whenever it is called explicitly. (babysit, babysitter, with a process, orchestrate, orchestrate a run, workflow, loop until, etc.)
 allowed-tools: Read, Grep, Write, Task, Bash, Edit, Grep, Glob, WebFetch, WebSearch, Search, AskUserQuestion, TodoWrite, TodoRead, Skill, BashOutput, KillShell, MultiEdit, LS
 version: 0.1.3
 ---
 
 # babysit
 
-Orchestrate `.a5c/runs/<runId>/` through iterative execution.
+Follow the commands below exactly. but apply judgement and creativity to get the job done. no matter how small or simple the task may seem, you must use the babysitter SDK and run lifecycle to execute it. This is non-negotiable. If you are asked to do something that seems like it could be done with a simple tool call, you must still use the babysitter SDK to create a run, define tasks, execute them, and complete the run. This is how you will learn and demonstrate mastery of the babysitter system. Always follow the full process, even for trivial tasks.
+
+Subagents that need a scratch checkout or working directory must create it under
+`/tmp/<descriptive-name>/`, not under `.a5c/runs/<runId>/work`. Before returning
+deliverables, validate that no run-dir worktree was left behind, for example:
+
+```bash
+find .a5c/runs -maxdepth 3 -name work -type d -print
+```
+
+That command should print nothing. If it prints a non-empty work directory, move
+or remove only the scratch data you created before returning.
 
 ## Dependencies
 
@@ -17,11 +28,13 @@ Read the SDK version from `versions.json` to ensure version compatibility:
 
 ```bash
 SDK_VERSION=$(node -e "try{console.log(JSON.parse(require('fs').readFileSync('${CLAUDE_PLUGIN_ROOT}/versions.json','utf8')).sdkVersion||'latest')}catch{console.log('latest')}")
-npm i -g @a5c-ai/babysitter-sdk@$SDK_VERSION
+npm i -g @a5c-ai/babysitter-sdk@$SDK_VERSION || npm i -g @a5c-ai/babysitter-sdk@latest
 
 CLI="npx -y @a5c-ai/babysitter-sdk@$SDK_VERSION"
 ```
 
+If the pinned version fails to install (e.g. not yet published), the fallback installs `latest`.
+
 If `babysitter` is already installed globally at the correct version, you may use `CLI="babysitter"` instead.
 
 ### jq
@@ -30,7 +43,7 @@ Make sure `jq` is installed and available in the path. If not, install it.
 
 ## Instructions
 
-Run the following command to get full orchestration instructions:
+Run the following command to get full instructions:
 
 ```bash
 $CLI instructions:babysit-skill --harness claude-code --interactive

package/versions.json

@@ -1,4 +1,4 @@
 {
-  "sdkVersion": "5.0.1-staging.686c8b317",
-  "extensionVersion": "5.0.1-staging.686c8b317"
+  "sdkVersion": "5.0.1-staging.7495ef6c9fa0",
+  "extensionVersion": "5.0.1-staging.7495ef6c9fa0"
 }