@a5c-ai/babysitter-gemini-cli 5.0.1-staging.d8bdfcceaf4a → 5.0.1-staging.daf8e165bc4a

package/bin/install-shared.js

@@ -29,7 +29,7 @@ function writeFileIfChanged(filePath, contents) {
   try {
     const existing = fs.readFileSync(filePath, 'utf8');
     if (existing === contents) return false;
-  } catch {}
+  } catch (e) { process.stderr.write('[extension-mux] file read failed for ' + filePath + ', overwriting: ' + (e instanceof Error ? e.message : String(e)) + '\n'); }
   fs.mkdirSync(path.dirname(filePath), { recursive: true });
   fs.writeFileSync(filePath, contents);
   return true;
@@ -82,7 +82,7 @@ function writeJson(filePath, value) {
 function ensureExecutable(filePath) {
   try {
     fs.chmodSync(filePath, 0o755);
-  } catch {}
+  } catch (e) { process.stderr.write('[extension-mux] chmod failed for ' + filePath + ': ' + (e instanceof Error ? e.message : String(e)) + '\n'); }
 }
 
 function normalizeMarketplaceSourcePath(source, marketplacePath) {
@@ -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.d8bdfcceaf4a",
+    version: "5.0.1-staging.daf8e165bc4a",
     author: { name: "a5c.ai" },
   };
   if (idx >= 0) marketplace.plugins[idx] = entry;
@@ -147,7 +147,7 @@ function resolveCliCommand(packageRoot) {
   const versionsPath = path.join(packageRoot, 'versions.json');
   const versions = readJson(versionsPath) || {};
   const ver = versions.sdkVersion || 'latest';
-  return `npx -y @a5c-ai/babysitter-sdk@${ver}`;
+  return `npm exec --yes --package @a5c-ai/babysitter-sdk@${ver} -- babysitter`;
 }
 
 function runCli(packageRoot, cliArgs, options = {}) {

package/commands/blueprints.toml

@@ -0,0 +1,3 @@
+description = "manage Babysitter blueprints. Use this command to list installed blueprints, browse marketplaces, install, update, uninstall, configure, or create a new blueprint."
+
+prompt = "This command installs and manages Babysitter blueprints. A blueprint is a version-managed package of contextual instructions or deterministic Babysitter processes, not a conventional software plugin.\n\nIf the command is run without arguments, list installed blueprints with their name, version, marketplace, installation date, and last update date. Also list configured marketplaces and show how to add the default marketplace when none exist.\n\nBlueprints can be installed at two scopes:\n\n- **global** (`--global`): stored under `~/.a5c/`, available for all projects\n- **project** (`--project`): stored under `<projectDir>/.a5c/`, project-specific\n\n## Marketplace Management\n\nMarketplaces are git repositories containing a `marketplace.json` manifest and blueprint package directories. The SDK clones new marketplaces to `.a5c/blueprints/marketplaces/` for the selected scope and reads legacy `.a5c/marketplaces/` clones for compatibility.\n\n### Add a marketplace\n\n```bash\nbabysitter blueprint:add-marketplace --marketplace-url <url> [--marketplace-path <relative-path>] [--marketplace-branch <ref>] [--force] --global|--project [--json]\n```\n\n### Update a marketplace\n\n```bash\nbabysitter blueprint:update-marketplace --marketplace-name <name> [--marketplace-branch <ref>] --global|--project [--json]\n```\n\n### List blueprints in a marketplace\n\n```bash\nbabysitter blueprint:list-plugins --marketplace-name <name> --global|--project [--json]\n```\n\n## Blueprint Lifecycle\n\nFor `blueprint:install`, `blueprint:update`, `blueprint:configure`, and `blueprint:list-plugins`, the `--marketplace-name` flag is auto-detected when only one marketplace is cloned for the selected scope.\n\n```bash\nbabysitter blueprint:install --plugin-name <name> [--marketplace-name <mp>] --global|--project [--json]\nbabysitter blueprint:update --plugin-name <name> --marketplace-name <mp> --global|--project [--json]\nbabysitter blueprint:configure --plugin-name <name> --marketplace-name <mp> --global|--project [--json]\nbabysitter blueprint:uninstall --plugin-name <name> --marketplace-name <mp> --global|--project [--json]\n```\n\nThe `--plugin-name` flag is preserved for CLI compatibility with existing marketplace manifests. User-facing docs should call the installable a blueprint.\n\n## Registry Management\n\n```bash\nbabysitter blueprint:list-installed --global|--project [--json]\nbabysitter blueprint:update-registry --plugin-name <name> --plugin-version <ver> --marketplace-name <mp> --global|--project [--json]\nbabysitter blueprint:remove-from-registry --plugin-name <name> --global|--project [--json]\n```\n\n## Deprecated Aliases\n\nThe old `plugin:*` commands remain available as deprecated aliases for one release. Prefer `blueprint:*` in new docs, skills, and process instructions.\n\n## Agent Plugins Are Separate\n\nDo not rename or reinterpret agent harness plugins while handling blueprints. `CLAUDE_PLUGIN_ROOT`, `PI_PLUGIN_ROOT`, `.claude/plugins/`, hooks-mux, extension-mux, and agent plugin manifests stay plugin-specific."

package/commands/check-forbidden-markers.toml

@@ -0,0 +1,3 @@
+description = "Pre-deploy gate that scans built JS chunks for forbidden substring markers (saga-era / obsolete code paths) listed in a project-local forbidden-markers.txt"
+
+prompt = "Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md). Compose the gate from the shared helper at `library/processes/shared/forbidden-markers-scanner.js` (issue #477).\n\n## What this gate does\n\nReads a list of literal substring markers from `scripts/forbidden-markers.txt` (blank lines and `#`-prefixed comments stripped) and greps every `.js` chunk under `.vercel/output/static/_next/static/chunks/` (Next.js / Vercel default; configurable) for any occurrence. Reports structured hits per `(marker, chunk)` pair with occurrence counts. Designed to chain between `vercel build --prod` and `vercel deploy --prod`.\n\nUse this gate when a refactor or restart-from-baseline replaced load-bearing code paths and you need a structural guarantee the obsolete symbols never re-ship. Burned-in evidence: cookbook VI-9 / VI-12 near-miss revivals during the 2026-05 iOS-Safari saga; the prototype lives at `cookbook/scripts/check-no-forbidden.mjs` and shipped two upstream contributions before being generalized as this gate.\n\n## When to use\n\n- **Pre-deploy.** Insert after build, before deploy. Block the deploy when `ok: false`.\n- **Post-restart.** After a baseline rollback + step-by-step re-add, snapshot the saga-era markers in `forbidden-markers.txt` and let CI hold the line.\n- **Post-refactor.** When old helper / handler / module names must not coexist with the new ones in the same bundle.\n\n## Expected config locations\n\n- `scripts/forbidden-markers.txt` — one marker per line, `#` for comments. The list is the contract; the gate is mechanical. Commit this file to source control.\n- `.vercel/output/static/_next/static/chunks/` — default scan target. Override for non-Vercel frameworks via the `--chunks-dir` flag or the `chunksDir` task input.\n\nA missing markers file is a no-op (`ok: true`, `reason: 'missing-markers-file'`) — misconfiguration is never a deploy block. A missing chunks directory is likewise a no-op (`reason: 'missing-chunks-dir'`) so the gate is safe to chain into `check:all` before the build runs.\n\n## Exit semantics\n\n| Reason                  | `ok`   | Deploy decision                |\n|-------------------------|--------|--------------------------------|\n| `missing-markers-file`  | true   | Pass (no gate active)          |\n| `missing-chunks-dir`    | true   | Pass (run before build)        |\n| `empty-markers`         | true   | Pass (list is empty)           |\n| `no-chunks`             | true   | Pass (nothing to scan)         |\n| `clean`                 | true   | Pass — proceed to deploy       |\n| `hits`                  | false  | **BLOCK** — surface hits, ask for triage |\n\nFor each hit, the gate emits `{ marker, chunk, count }` so the operator sees the exact marker string, the absolute chunk path, and the number of occurrences in that chunk. Multiple hits across chunks for the same marker are reported separately.\n\n## Programmatic surface\n\n```js\nimport { scanForbiddenMarkers, checkForbiddenMarkersTask } from '@a5c-ai/babysitter-library/processes/shared';\n\n// Direct call:\nconst result = await scanForbiddenMarkers({\n  markersFile: 'scripts/forbidden-markers.txt',\n  chunksDir:   '.vercel/output/static/_next/static/chunks',\n});\nif (!result.ok) {\n  // result.hits: Array<{ marker, chunk, count }>\n  // result.reason === 'hits'\n  process.exit(1);\n}\n\n// Or dispatched as a babysitter task:\nconst gate = await ctx.task(checkForbiddenMarkersTask, {\n  projectDir: '.',\n  // markersFile / chunksDir are inferred from projectDir if omitted\n});\n```\n\n## Reference\n\n- Issue: https://github.com/a5c-ai/babysitter/issues/477\n- Helper module: `library/processes/shared/forbidden-markers-scanner.js`\n- Origin (cookbook prototype): `cookbook/scripts/check-no-forbidden.mjs` (81 lines)"

package/commands/cleanup.toml

@@ -1,3 +1,3 @@
 description = "Clean up .a5c/runs and .a5c/processes directories. Aggregates insights from completed/failed runs into docs/run-history-insights.md, then removes old run data and orphaned process files."
 
-prompt = "Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md).\n\nCreate and run a cleanup process using the process at `skills\\babysit\\process\\cradle\\cleanup-runs.js/processes/cleanup-runs.js`.\n\nImplementation notes (for the process):\n- Parse arguments for `--dry-run` flag (if present, set dryRun: true in inputs) and `--keep-days N` (default: 7)\n\nCRITICAL: The cleanup MUST follow this exact phase order. Do NOT delete any run before Phase 2 completes.\n\nPhase 1 — Scan:\n- Scan .a5c/runs/ for all runs\n- Classify each as terminal (completed/failed) or active (in-progress/created)\n- Identify terminal runs older than the keep-days threshold as removal candidates\n- Never mark active/in-progress runs for removal\n- Count and report: total runs, terminal, active, removal candidates, disk usage\n\nPhase 2 — Aggregate insights (BEFORE any deletion):\n- For EVERY removal candidate, read its run.json and journal/ events\n- Extract: processId, prompt, status, event count, created date, task summaries\n- Group by process type and extract patterns (retry counts, convergence behavior, failure modes)\n- Append a new dated section to docs/run-history-insights.md with:\n  - Summary statistics (runs removed, disk freed, runs retained)\n  - Run categories with counts and descriptions\n  - Key patterns observed (multi-batch convergence, retry behavior, etc.)\n  - What worked well / what didn't from the run data\n- This file MUST be written and verified before proceeding to Phase 3\n\nPhase 3 — Confirm removal:\n- In interactive mode, show the user what will be removed via a breakpoint\n- In non-interactive mode (yolo), proceed with defaults\n- In dry-run mode, stop here and show what would be removed\n\nPhase 4 — Remove:\n- Delete the terminal runs older than keep-days threshold\n- Identify and remove orphaned process files not referenced by remaining runs\n- Show remaining run count and disk usage after cleanup"
+prompt = "Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md).\n\nResolve the active process library with:\n\n```bash\nbabysitter process-library:active --json\n```\n\nRead `binding.dir` from that JSON and create/run the cleanup process from `cradle/cleanup-runs.js#process` relative to that active library root. Do not use plugin-cache-relative cradle paths.\n\nImplementation notes (for the process):\n- Parse arguments for `--dry-run` flag (if present, set dryRun: true in inputs) and `--keep-days N` (default: 7)\n\nCRITICAL: The cleanup MUST follow this exact phase order. Do NOT delete any run before Phase 2 completes.\n\nPhase 1 — Scan:\n- Scan .a5c/runs/ for all runs\n- Classify each as terminal (completed/failed) or active (in-progress/created)\n- Identify terminal runs older than the keep-days threshold as removal candidates\n- Never mark active/in-progress runs for removal\n- Count and report: total runs, terminal, active, removal candidates, disk usage\n\nPhase 2 — Aggregate insights (BEFORE any deletion):\n- For EVERY removal candidate, read its run.json and journal/ events\n- Extract: processId, prompt, status, event count, created date, task summaries\n- Group by process type and extract patterns (retry counts, convergence behavior, failure modes)\n- Append a new dated section to docs/run-history-insights.md with:\n  - Summary statistics (runs removed, disk freed, runs retained)\n  - Run categories with counts and descriptions\n  - Key patterns observed (multi-batch convergence, retry behavior, etc.)\n  - What worked well / what didn't from the run data\n- This file MUST be written and verified before proceeding to Phase 3\n\nPhase 3 — Confirm removal:\n- In interactive mode, show the user what will be removed via a breakpoint\n- In non-interactive mode (yolo), proceed with defaults\n- In dry-run mode, stop here and show what would be removed\n\nPhase 4 — Remove:\n- Delete the terminal runs older than keep-days threshold\n- Identify and remove orphaned process files not referenced by remaining runs\n- Show remaining run count and disk usage after cleanup"

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. 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."
+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:blueprints [action]\n  Manage Babysitter blueprints: list installed blueprints, browse marketplaces,\n  install, update, configure, uninstall, or create new blueprints. Blueprints are\n  version-managed instruction packages or process bundles that guide the agent\n  through install, configure, and uninstall steps.\n\n  Without arguments: shows installed blueprints (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 blueprint package\n\n  Example: /babysitter:blueprints 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 the blueprint)\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/plan.toml

@@ -1,3 +1,3 @@
 description = "Plan a babysitter run. use this command to plan a complex workflow, without actually running it."
 
-prompt = "Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md). focus on creating the best process possible, but without creating and running the actual run."
+prompt = "Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md). Focus on creating the best process possible, but without creating and running the actual run.\n\nBefore drafting the process, run Phase 0 -- REUSE-AUDIT: extract keyword nouns and verbs from the request, scan for matching existing migrations, API routes, environment variables, SDK dependencies, and imports, honor `.a5c/reuse-audit.json` when present, and put a `Reuse-audit findings (REVIEW BEFORE PROCEEDING)` block before Phase 1 of the plan.\n\n## Process Shape Selection\n\nChoose the process shape before authoring `process.js`:\n\n- Use a flat phase list when the spec is well-defined, the work is wiring or composition, the bug class is already known if this is a fix, and execution should proceed sequentially through clear phases.\n- Use a HYPOTHESES tree when the bug class is unknown, forensics are required, multiple causal models compete, and each hypothesis needs its own observations, falsifying observations, and follow-up phases.\n- Rule of thumb: if the first phase is \"investigate\", use HYPOTHESES-tree mode. If the first phase is \"implement X\", use flat-phase-list mode."

package/commands/plugins.toml

@@ -1,3 +1,3 @@
-description = "manage babysitter plugins. use this command to see the list of installed babysitter plugins, their status, and manage them (install, update, uninstall, list from marketplace, add marketplace, configure plugin, create new plugin, etc)."
+description = "deprecated alias for the Babysitter blueprints command. Use /babysitter:blueprints for marketplace installables."
 
-prompt = "This command installs and manages plugins for babysitter. A plugin is a version-managed package of contextual instructions (for install, uninstall, configure, and update/migrate between versions), not a conventional software plugin.\n\nif the command is run without arguments, it lists all installed plugins with their name, version, marketplace, installation date, and last update date. as well as marketplaces added to the system. and instructions on how to install new plugins from marketplaces.\nif there are no marketplaces added, add the default marketplace:\n```bash\nbabysitter plugin:add-marketplace --marketplace-url https://github.com/a5c-ai/babysitter --marketplace-path plugins/a5c/marketplace/marketplace.json --global --json\n```\n\nPlugins can be installed at two scopes:\n- **global** (`--global`): stored under `~/.a5c/`, available for all projects\n- **project** (`--project`): stored under `<projectDir>/.a5c/`, project-specific\n\n## Marketplace Management\n\nMarketplaces are git repositories containing a `marketplace.json` manifest and plugin package directories. The SDK clones them locally with `--depth 1`.\n\n**Storage locations:**\n- Global: `~/.a5c/marketplaces/<name>/`\n- Project: `<projectDir>/.a5c/marketplaces/<name>/`\n\nThe marketplace name is derived from the git URL's last path segment (stripping `.git` suffix and trailing slashes).\n\n### Adding a marketplace\n\n```bash\nbabysitter plugin:add-marketplace --marketplace-url <url> [--marketplace-path <relative-path>] [--marketplace-branch <ref>] [--force] --global|--project [--json]\n```\n\nClones the marketplace repository to the local marketplaces directory. Use `--marketplace-path` to specify the relative path to `marketplace.json` within the repo (for monorepos or repos where the manifest is not at the root). Use `--marketplace-branch` to clone a specific branch, tag, or ref (defaults to the repo's default branch). Use `--force` to replace an existing marketplace clone (deletes and re-clones).\n\n### Updating a marketplace\n\n```bash\nbabysitter plugin:update-marketplace --marketplace-name <name> [--marketplace-branch <ref>] --global|--project [--json]\n```\n\nRuns `git pull` on the local marketplace clone to fetch latest changes. Use `--marketplace-branch` to switch to a different branch before pulling (works even with shallow clones).\n\n### Listing plugins in a marketplace\n\n```bash\nbabysitter plugin:list-plugins --marketplace-name <name> --global|--project [--json]\n```\n\nReads the `marketplace.json` manifest and returns all available plugins sorted alphabetically by name. Each entry includes: name, description, latestVersion, versions array, packagePath, tags, and author.\n\n## Plugin Installation\n\n**Note:** For `plugin:install`, `plugin:update`, `plugin:configure`, and `plugin:list-plugins`, the `--marketplace-name` flag is auto-detected when only one marketplace is cloned for the given scope. You can omit it if there's only one marketplace.\n\n### Flow\n\n1. Update the marketplace: `babysitter plugin:update-marketplace --marketplace-name <name> --global|--project`\n2. Check current state: `babysitter plugin:list-installed --global|--project` to see installed plugins and versions\n3. Install the plugin:\n\n```bash\nbabysitter plugin:install --plugin-name <name> [--marketplace-name <mp>] --global|--project [--json]\n```\n\nThis command resolves the plugin package path from the marketplace manifest, reads `install.md` from the plugin package directory, and returns the installation instructions. If an `install-process.js` file exists, the instructions may reference it as an automated install process.\n\n4. The agent performs the installation steps as defined in `install.md`\n5. The agent updates the registry:\n\n```bash\nbabysitter plugin:update-registry --plugin-name <name> --plugin-version <ver> --marketplace-name <mp> --global|--project [--json]\n```\n\n## Plugin Update (with migrations)\n\n```bash\nbabysitter plugin:update --plugin-name <name> --marketplace-name <mp> --global|--project [--json]\n```\n\nThis command:\n1. Reads the currently installed version from the registry\n2. Resolves the latest version from the marketplace manifest\n3. Looks in the plugin package's `migrations/` directory for migration files\n4. Uses BFS over the migration graph to find the shortest path from the installed version to the target version\n5. Returns the ordered migration instructions (content of each migration file in sequence)\n\n**Migration filename format:** `<fromVersion>_to_<toVersion>.<ext>` where:\n- Versions may contain alphanumerics, dots, dashes (e.g. `1.0.0`, `2.0.0-beta`)\n- Extensions: `.md` for markdown instructions, `.js` for executable process files\n- Examples: `1.0.0_to_1.1.0.md`, `2.0.0-beta_to_2.0.0.js`\n\nAfter performing the migration steps, update the registry:\n\n```bash\nbabysitter plugin:update-registry --plugin-name <name> --plugin-version <new-ver> --marketplace-name <mp> --global|--project [--json]\n```\n\n## Plugin Uninstallation\n\n```bash\nbabysitter plugin:uninstall --plugin-name <name> --marketplace-name <mp> --global|--project [--json]\n```\n\nReads `uninstall.md` from the plugin package directory and returns the uninstall instructions. After performing the uninstall steps, remove from registry:\n\n```bash\nbabysitter plugin:remove-from-registry --plugin-name <name> --global|--project [--json]\n```\n\n## Plugin Configuration\n\n```bash\nbabysitter plugin:configure --plugin-name <name> --marketplace-name <mp> --global|--project [--json]\n```\n\nReads `configure.md` from the plugin package directory and returns configuration instructions.\n\n## Registry Management\n\nThe plugin registry (`plugin-registry.json`) tracks installed plugins with schema version `2026.01.plugin-registry-v1`. Writes use atomic file operations (temp + rename) for crash safety.\n\n**Storage locations:**\n- Global: `~/.a5c/plugin-registry.json`\n- Project: `<projectDir>/.a5c/plugin-registry.json`\n\n### List installed plugins\n\n```bash\nbabysitter plugin:list-installed --global|--project [--json]\n```\n\nReturns all installed plugins sorted alphabetically. In `--json` mode, returns an array of registry entries. In human mode, displays a formatted table with name, version, marketplace, and timestamps.\n\n### Remove from registry\n\n```bash\nbabysitter plugin:remove-from-registry --plugin-name <name> --global|--project [--json]\n```\n\nRemoves a plugin entry from the registry. Returns error if the plugin is not present.\n\n## Plugin Creation\n\nTo create a new plugin package from scratch, use the `meta/plugin-creation` babysitter process. This process guides you through requirements analysis, structure design, instruction authoring, optional process file generation, validation, and marketplace integration.\n\n### Using the plugin creation process\n\nOrchestrate a babysitter run with the plugin creation process:\n\n```bash\n# Create inputs file\ncat > /tmp/plugin-inputs.json << 'EOF'\n{\n  \"pluginName\": \"my-plugin\",\n  \"description\": \"What the plugin does — be specific about install/configure/uninstall behavior\",\n  \"scope\": \"project\",\n  \"outputDir\": \"./plugins\",\n  \"components\": {\n    \"installProcess\": false,\n    \"configureProcess\": false,\n    \"uninstallProcess\": false,\n    \"migrations\": false,\n    \"processFiles\": false\n  },\n  \"marketplace\": {\n    \"name\": \"my-marketplace\",\n    \"author\": \"my-org\",\n    \"tags\": [\"category1\", \"category2\"]\n  }\n}\nEOF\n\n# Create and run\nbabysitter run:create \\\n  --process-id meta/plugin-creation \\\n  --entry library/specializations/meta/plugin-creation.js#process \\\n  --inputs /tmp/plugin-inputs.json \\\n  --prompt \"Create a new babysitter plugin package\" \\\n  --json\n```\n\n### What the process generates\n\nThe process creates a complete plugin package directory:\n\n| File | Description |\n|------|-------------|\n| `install.md` | Agent-readable installation instructions with numbered steps |\n| `uninstall.md` | Reversal instructions for clean removal |\n| `configure.md` | Configuration options table and adjustment instructions |\n| `install-process.js` | *(optional)* Automated babysitter process for complex install steps |\n| `configure-process.js` | *(optional)* Automated configuration process |\n| `process/main.js` | *(optional)* Main process the plugin contributes |\n| `marketplace-entry.json` | Ready-to-use marketplace.json entry for publishing |\n\n### Process phases\n\n1. **Requirements Analysis** — Analyzes plugin purpose, prerequisites, config options, file structure\n2. **Structure Design** — Plans directory layout and file inventory (with review breakpoint)\n3. **Instruction Authoring** — Writes install.md, uninstall.md, configure.md\n4. **Process Files** — Creates optional babysitter process files (install-process.js, configure-process.js, process/main.js)\n5. **Validation** — Verifies package completeness, instruction quality, path correctness\n6. **Marketplace Integration** — Generates marketplace.json entry for publishing\n\n### Quick creation (without orchestration)\n\nFor simple plugins that only need instruction files, you can create the package manually following the structure below and the [Plugin Author Guide](docs/plugins/plugin-author-guide.md).\n\n## Plugin Package Structure\n\n```\nmy-plugin/\n  package.json         # Optional (name field used as plugin ID, falls back to directory name)\n  install.md           # Markdown instructions for installation\n  uninstall.md         # Markdown instructions for removal\n  configure.md         # Markdown instructions for configuration\n  install-process.js   # Optional automated install process\n  uninstall-process.js # Optional automated uninstall process\n  configure-process.js # Optional automated configure process\n  migrations/          # Version migration files\n    1.0.0_to_1.1.0.md\n    1.1.0_to_2.0.0.js\n  process/             # Process definition files (collected recursively)\n    main.js\n```\n\n## All CLI Commands Summary\n\nAll commands accept `--json` for machine-readable output and `--global|--project`.\n\n| Command | Required Flags | Description |\n|---------|---------------|-------------|\n| `plugin:add-marketplace` | `--marketplace-url`, `--global\\|--project` [`--marketplace-path`, `--marketplace-branch`, `--force`] | Clone a marketplace repository |\n| `plugin:update-marketplace` | `--marketplace-name`, `--global\\|--project` [`--marketplace-branch`] | Pull latest marketplace changes (optionally switch branch) |\n| `plugin:list-plugins` | `--marketplace-name`, `--global\\|--project` | List available plugins in a marketplace |\n| `plugin:install` | `--plugin-name`, `--marketplace-name`, `--global\\|--project` | Get install instructions for a plugin |\n| `plugin:uninstall` | `--plugin-name`, `--marketplace-name`, `--global\\|--project` | Get uninstall instructions for a plugin |\n| `plugin:update` | `--plugin-name`, `--marketplace-name`, `--global\\|--project` | Resolve migration chain and get update instructions |\n| `plugin:configure` | `--plugin-name`, `--marketplace-name`, `--global\\|--project` | Get configuration instructions for a plugin |\n| `plugin:list-installed` | `--global\\|--project` | List all installed plugins |\n| `plugin:update-registry` | `--plugin-name`, `--plugin-version`, `--marketplace-name`, `--global\\|--project` | Register or update a plugin entry |\n| `plugin:remove-from-registry` | `--plugin-name`, `--global\\|--project` | Remove a plugin entry from the registry |\n\n## After Plugin Work: Contribute Back\n\nAfter working with plugins, prompt the user to share improvements or report issues:\n\n- **Improved a plugin's install/configure/uninstall instructions**: `/babysitter:contrib library contribution: improved [plugin-name] [install|configure|uninstall] instructions`\n- **Created a new plugin**: `/babysitter:contrib library contribution: new plugin [plugin-name] -- [description]`\n- **Found a bug in a plugin or the plugin system**: `/babysitter:contrib bug report: [description, e.g. \"plugin:update-registry fails when marketplace hasn't been cloned\"]`\n- **Plugin install/configure instructions were confusing or wrong**: `/babysitter:contrib bug report: [plugin-name] install instructions [description of what was wrong]`\n- **Have an idea for a new plugin**: `/babysitter:contrib feature request: plugin idea -- [description]`\n\nEven reporting that a plugin's instructions were unclear helps improve it for the next user."
+prompt = "This command is a deprecated alias for `/babysitter:blueprints`.\n\nFor Babysitter marketplace installables, use blueprints terminology and the `babysitter blueprint:*` CLI command family:\n\n```bash\nbabysitter blueprint:list-installed --global|--project [--json]\nbabysitter blueprint:add-marketplace --marketplace-url <url> [--marketplace-path <relative-path>] --global|--project [--json]\nbabysitter blueprint:list-plugins --marketplace-name <name> --global|--project [--json]\nbabysitter blueprint:install --plugin-name <name> [--marketplace-name <mp>] --global|--project [--json]\nbabysitter blueprint:update --plugin-name <name> [--marketplace-name <mp>] --global|--project [--json]\nbabysitter blueprint:configure --plugin-name <name> [--marketplace-name <mp>] --global|--project [--json]\nbabysitter blueprint:uninstall --plugin-name <name> [--marketplace-name <mp>] --global|--project [--json]\n```\n\nThe `--plugin-name` flag remains for CLI compatibility with existing marketplace manifests. Describe the installable as a blueprint in user-facing text.\n\nAgent harness plugins are not renamed. `CLAUDE_PLUGIN_ROOT`, `PI_PLUGIN_ROOT`, `.claude/plugins/`, hooks-mux, extension-mux, and agent plugin manifests remain plugin concepts."

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 = "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"
+prompt = "Run the Babysitter orchestration instructions directly through the CLI, without any user interaction or breakpoints. Use Bash to run `babysitter instructions:babysit-skill --harness gemini-cli --no-interactive`, 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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@a5c-ai/babysitter-gemini-cli",
-  "version": "5.0.1-staging.d8bdfcceaf4a",
+  "version": "5.0.1-staging.daf8e165bc4a",
   "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.d8bdfcceaf4a"
+    "@a5c-ai/babysitter-sdk": "5.0.1-staging.daf8e165bc4a"
   },
   "repository": {
     "type": "git",

package/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "babysitter",
-  "version": "5.0.1-staging.d8bdfcceaf4a",
+  "version": "5.0.1-staging.daf8e165bc4a",
   "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",
@@ -18,7 +18,9 @@
   },
   "commands": [
     "commands/assimilate.toml",
+    "commands/blueprints.toml",
     "commands/call.toml",
+    "commands/check-forbidden-markers.toml",
     "commands/cleanup.toml",
     "commands/contrib.toml",
     "commands/doctor.toml",

package/skills/babysit/SKILL.md

@@ -27,15 +27,19 @@ or remove only the scratch data you created before returning.
 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')}")
+SDK_VERSION=$(node -e "try{console.log(JSON.parse(require('fs').readFileSync('${GEMINI_EXTENSION_PATH}/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@latest
 
-CLI="npx -y @a5c-ai/babysitter-sdk@$SDK_VERSION"
+if command -v babysitter >/dev/null 2>&1 && babysitter --version >/dev/null 2>&1; then
+  CLI="babysitter"
+else
+  CLI="npm exec --yes --package @a5c-ai/babysitter-sdk@$SDK_VERSION -- babysitter"
+fi
 ```
 
 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.
+If a stale or broken global shim fails with `MODULE_NOT_FOUND`, repair it with `npm rm -g @a5c-ai/babysitter @a5c-ai/babysitter-sdk && npm i -g @a5c-ai/babysitter-sdk@$SDK_VERSION`, then re-run `babysitter --version`.
 
 ### jq
 
@@ -46,13 +50,13 @@ Make sure `jq` is installed and available in the path. If not, install it.
 Run the following command to get full instructions:
 
 ```bash
-$CLI instructions:babysit-skill --harness claude-code --interactive
+$CLI instructions:babysit-skill --harness gemini-cli --interactive
 ```
 
 For non-interactive mode (running with `-p` flag or no AskUserQuestion tool):
 
 ```bash
-$CLI instructions:babysit-skill --harness claude-code --no-interactive
+$CLI instructions:babysit-skill --harness gemini-cli --no-interactive
 ```
 
 Follow the instructions returned by the command above to orchestrate the run.

package/versions.json

@@ -1,4 +1,4 @@
 {
-  "sdkVersion": "5.0.1-staging.d8bdfcceaf4a",
-  "extensionVersion": "5.0.1-staging.d8bdfcceaf4a"
+  "sdkVersion": "5.0.1-staging.daf8e165bc4a",
+  "extensionVersion": "5.0.1-staging.daf8e165bc4a"
 }