@a5c-ai/babysitter-opencode 5.0.0 → 5.0.1-staging.016f0b0e8119

package/commands/retrospect.md

@@ -1,55 +1,55 @@
----
-description: Analysis for a run and its results, process, suggestions for process improvements, process optimizations, fixes, etc. for the next runs.
-argument-hint: "[run-id...] [--all] Specific run IDs, --all for all runs, or defaults to latest"
-allowed-tools: Read, Grep, Write, Task, Bash, Edit, Grep, Glob, WebFetch, WebSearch, Search, AskUserQuestion, TodoWrite, TodoRead, Skill, BashOutput, KillShell, MultiEdit, LS
----
-
-Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md).
-
-create and run a retrospect process:
-
-### Run Selection
-
-- `--all` or "all runs": list all completed/failed runs and analyze collectively
-- Multiple run IDs: analyze each specified run
-- Single run ID or no ID: existing behavior (latest run)
-- In interactive mode with no run specified: ask user whether to analyze latest, select specific runs, or all runs
-
-### Cross-Run Analysis (multi-run mode)
-
-When analyzing multiple runs, the retrospect process should additionally cover:
-- Common failure patterns across runs
-- Velocity trends (tasks/time across runs)
-- Process evolution (how processes changed)
-- Repeated breakpoint patterns
-- Aggregate quality metrics
-
-implementations notes (for the process):
-- The process should analyze the run, the process that was followed, and provide suggestions for improvements, optimizations, and fixes.
-- The process should such have many breakpoints where the user can steer the process, provide feedback, and make decisions about how to proceed with the retrospect.
-- The process should be designed to be flexible and adaptable to different types of runs, projects, and goals, and should be able to provide insights and suggestions that are relevant and actionable for the user. (modification to the process, skills, etc.)
-- The process should be designed to be iterative, allowing the user to go through multiple rounds of analysis and improvement, and should be able to track the changes and improvements made over time.
-- The process should cover:
-    - Analysis of the run and its results, including what went well, what didn't go well, and what could be improved.
-    - Analysis of the process that was followed, including what steps were taken, what tools were used, and how effective they were.
-    - Suggestions for improvements, optimizations, and fixes for both the run and the process.
-    - Implementing the improvements, optimizations, and fixes, and tracking the changes made over time.
-### Cleanup Suggestion
-
-After retrospect analysis, suggest running `/babysitter:cleanup` to clean up old run data and reclaim disk space.
-
-    - Ending by explicitly prompting the user to contribute back -- even just reporting an issue is valuable, they don't need to implement the fix themselves. After analysis, display a clear call-to-action:
-
-      "You've identified [specific insight/improvement]. This could help other babysitter users too. Run `/babysitter:contrib` to share it upstream -- you can either report it as an issue or submit a PR with the fix."
-
-      Route to the specific contrib workflow based on what the user wants to do:
-
-      **Just reporting (no code changes needed):**
-      - Found a bug or weakness in a process -> `/babysitter:contrib bug report: [description of what went wrong]`
-      - Found missing or confusing documentation -> `/babysitter:contrib documentation question: [what was unclear]`
-      - Have an idea for improvement but don't want to implement it -> `/babysitter:contrib feature request: [description]`
-
-      **Contributing code changes:**
-      - Process/skill/agent improvements -> `/babysitter:contrib library contribution: [description]`
-      - Bug fixes in SDK or CLI -> `/babysitter:contrib bugfix: [description]`
-      - Plugin instruction improvements -> `/babysitter:contrib library contribution: improved [plugin-name] [install|configure|uninstall] instructions`
+---
+description: Analysis for a run and its results, process, suggestions for process improvements, process optimizations, fixes, etc. for the next runs.
+argument-hint: "[run-id...] [--all] Specific run IDs, --all for all runs, or defaults to latest"
+allowed-tools: Read, Grep, Write, Task, Bash, Edit, Grep, Glob, WebFetch, WebSearch, Search, AskUserQuestion, TodoWrite, TodoRead, Skill, BashOutput, KillShell, MultiEdit, LS
+---
+
+Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md).
+
+create and run a retrospect process:
+
+### Run Selection
+
+- `--all` or "all runs": list all completed/failed runs and analyze collectively
+- Multiple run IDs: analyze each specified run
+- Single run ID or no ID: existing behavior (latest run)
+- In interactive mode with no run specified: ask user whether to analyze latest, select specific runs, or all runs
+
+### Cross-Run Analysis (multi-run mode)
+
+When analyzing multiple runs, the retrospect process should additionally cover:
+- Common failure patterns across runs
+- Velocity trends (tasks/time across runs)
+- Process evolution (how processes changed)
+- Repeated breakpoint patterns
+- Aggregate quality metrics
+
+implementations notes (for the process):
+- The process should analyze the run, the process that was followed, and provide suggestions for improvements, optimizations, and fixes.
+- The process should such have many breakpoints where the user can steer the process, provide feedback, and make decisions about how to proceed with the retrospect.
+- The process should be designed to be flexible and adaptable to different types of runs, projects, and goals, and should be able to provide insights and suggestions that are relevant and actionable for the user. (modification to the process, skills, etc.)
+- The process should be designed to be iterative, allowing the user to go through multiple rounds of analysis and improvement, and should be able to track the changes and improvements made over time.
+- The process should cover:
+    - Analysis of the run and its results, including what went well, what didn't go well, and what could be improved.
+    - Analysis of the process that was followed, including what steps were taken, what tools were used, and how effective they were.
+    - Suggestions for improvements, optimizations, and fixes for both the run and the process.
+    - Implementing the improvements, optimizations, and fixes, and tracking the changes made over time.
+### Cleanup Suggestion
+
+After retrospect analysis, suggest running `/babysitter:cleanup` to clean up old run data and reclaim disk space.
+
+    - Ending by explicitly prompting the user to contribute back -- even just reporting an issue is valuable, they don't need to implement the fix themselves. After analysis, display a clear call-to-action:
+
+      "You've identified [specific insight/improvement]. This could help other babysitter users too. Run `/babysitter:contrib` to share it upstream -- you can either report it as an issue or submit a PR with the fix."
+
+      Route to the specific contrib workflow based on what the user wants to do:
+
+      **Just reporting (no code changes needed):**
+      - Found a bug or weakness in a process -> `/babysitter:contrib bug report: [description of what went wrong]`
+      - Found missing or confusing documentation -> `/babysitter:contrib documentation question: [what was unclear]`
+      - Have an idea for improvement but don't want to implement it -> `/babysitter:contrib feature request: [description]`
+
+      **Contributing code changes:**
+      - Process/skill/agent improvements -> `/babysitter:contrib library contribution: [description]`
+      - Bug fixes in SDK or CLI -> `/babysitter:contrib bugfix: [description]`
+      - Plugin instruction improvements -> `/babysitter:contrib library contribution: improved [plugin-name] [install|configure|uninstall] instructions`

package/commands/user-install.md

@@ -1,11 +1,11 @@
----
-description: Set up babysitter for yourself. Guides you through onboarding — installs dependencies, interviews you about your specialties and preferences, builds your user profile, and configures the best tools for your workflow.
-argument-hint: Specific instructions for the run.
-allowed-tools: Read, Grep, Write, Task, Bash, Edit, Grep, Glob, WebFetch, WebSearch, Search, AskUserQuestion, TodoWrite, TodoRead, Skill, BashOutput, KillShell, MultiEdit, LS
----
-
-Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md).
-
+---
+description: Set up babysitter for yourself. Guides you through onboarding — installs dependencies, interviews you about your specialties and preferences, builds your user profile, and configures the best tools for your workflow.
+argument-hint: Specific instructions for the run.
+allowed-tools: Read, Grep, Write, Task, Bash, Edit, Grep, Glob, WebFetch, WebSearch, Search, AskUserQuestion, TodoWrite, TodoRead, Skill, BashOutput, KillShell, MultiEdit, LS
+---
+
+Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md).
+
 Before using the process library, resolve the active library root through the SDK CLI. If no binding exists yet, initialize the shared global SDK binding with:
 
 ```bash
@@ -13,5 +13,5 @@ babysitter process-library:active --json
 ```
 
 Then use the `cradle/user-install` process from the active process library.
-
-When the run completes, end with a friendly message that includes a polite and humorous ask to star the repo on GitHub: https://github.com/a5c-ai/babysitter
+
+When the run completes, end with a friendly message that includes a polite and humorous ask to star the repo on GitHub: https://github.com/a5c-ai/babysitter

package/commands/yolo.md

@@ -4,4 +4,8 @@ argument-hint: Specific instructions for the run.
 allowed-tools: Read, Grep, Write, Task, Bash, Edit, Grep, Glob, WebFetch, WebSearch, Search, AskUserQuestion, TodoWrite, TodoRead, Skill, BashOutput, KillShell, MultiEdit, LS
 ---
 
-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.
+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.
+
+User arguments for this command:
+
+$ARGUMENTS

package/hooks/babysitter-proxied-stop-hook.sh

@@ -0,0 +1,3 @@
+#!/bin/bash
+set -euo pipefail
+babysitter hook:run --harness unified --hook-type stop --json

package/hooks/hooks.json

@@ -26,14 +26,6 @@
         "timeoutMs": 30000
       }
     ],
-    "session.idle": [
-      {
-        "type": "command",
-        "script": "./hooks/babysitter-proxied-session-idle.js",
-        "description": "babysitter SessionIdle hook",
-        "timeoutMs": 30000
-      }
-    ],
     "shell.env": [
       {
         "type": "command",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@a5c-ai/babysitter-opencode",
-  "version": "5.0.0",
+  "version": "5.0.1-staging.016f0b0e8119",
   "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",
@@ -8,8 +8,7 @@
     "postinstall": "node bin/install.js",
     "preuninstall": "node bin/uninstall.js",
     "team:install": "node scripts/team-install.js",
-    "test": "node test/integration.test.js",
-    "sync:commands": "node scripts/sync-command-docs.cjs"
+    "test": "node test/integration.test.js"
   },
   "bin": {
     "babysitter-opencode": "bin/cli.js"
@@ -36,7 +35,7 @@
     "access": "public"
   },
   "dependencies": {
-    "@a5c-ai/babysitter-sdk": "5.0.0"
+    "@a5c-ai/babysitter-sdk": "5.0.1-staging.016f0b0e8119"
   },
   "repository": {
     "type": "git",

package/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "babysitter",
-  "version": "5.0.0",
+  "version": "5.0.1-staging.016f0b0e8119",
   "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/scripts/publish-from-tag.mjs

@@ -1,12 +1,41 @@
 #!/usr/bin/env node
 import { spawnSync } from 'node:child_process';
+import { readFileSync } from 'node:fs';
 
-function run(command, args) {
-  const result = spawnSync(command, args, { stdio: 'inherit' });
-  if (result.status !== 0) process.exit(result.status || 1);
+function run(command, args, options = {}) {
+  const result = spawnSync(command, args, { stdio: options.stdio || 'inherit', encoding: options.encoding });
+  if (result.status !== 0 && !options.allowFailure) process.exit(result.status || 1);
+  return result;
 }
 
+function npmView(packageSpec) {
+  return run('npm', ['view', packageSpec, 'version'], { allowFailure: true, stdio: 'pipe', encoding: 'utf8' }).status === 0;
+}
+
+const pkg = JSON.parse(readFileSync('package.json', 'utf8'));
 const ref = process.env.GITHUB_REF_NAME || '';
 const branch = ref.split('/')[1] || 'develop';
 const tag = branch === 'main' ? 'latest' : branch;
+
+if (!process.env.NODE_AUTH_TOKEN) {
+  console.log('NODE_AUTH_TOKEN is not configured; skipping npm publish.');
+  process.exit(0);
+}
+
+if (npmView(pkg.name + '@' + pkg.version)) {
+  console.log(pkg.name + '@' + pkg.version + ' already exists; ensuring dist-tag ' + tag + '.');
+  run('npm', ['dist-tag', 'add', pkg.name + '@' + pkg.version, tag], { allowFailure: true });
+  process.exit(0);
+}
+
+for (const field of ['dependencies', 'peerDependencies', 'optionalDependencies']) {
+  for (const [name, version] of Object.entries(pkg[field] || {})) {
+    if (!name.startsWith('@a5c-ai/') || version.startsWith('^') || version.startsWith('~') || version === '*' || version.startsWith('workspace:')) continue;
+    if (!npmView(name + '@' + version)) {
+      console.log('Required internal dependency ' + name + '@' + version + ' is not published yet; skipping npm publish.');
+      process.exit(0);
+    }
+  }
+}
+
 run('npm', ['publish', '--access', 'public', '--tag', tag]);

package/skills/accomplish-status/SKILL.md

@@ -29,7 +29,7 @@ Where `OPENCODE_CONFIG_DIR` is resolved from the `OPENCODE_CONFIG_DIR` environme
 Read the SDK version from `versions.json` to ensure version compatibility:
 
 ```bash
-SDK_VERSION=$(node -e "try{const fs=require('fs');const probes=['./plugins/babysitter-opencode/versions.json','./node_modules/@a5c-ai/babysitter-opencode/versions.json'];for(const probe of probes){if(fs.existsSync(probe)){console.log(JSON.parse(fs.readFileSync(probe,'utf8')).sdkVersion||'latest');process.exit(0)}}console.log('latest')}catch{console.log('latest')}")
+SDK_VERSION=$(node -e "try{const fs=require('fs');const probes=['./plugins/babysitter-unified/versions.json','./node_modules/@a5c-ai/babysitter-opencode/versions.json'];for(const probe of probes){if(fs.existsSync(probe)){console.log(JSON.parse(fs.readFileSync(probe,'utf8')).sdkVersion||'latest');process.exit(0)}}console.log('latest')}catch{console.log('latest')}")
 npm i -g @a5c-ai/babysitter-sdk@$SDK_VERSION
 
 CLI="npx -y @a5c-ai/babysitter-sdk@$SDK_VERSION"

package/skills/babysit/SKILL.md

@@ -1,11 +1,12 @@
 ---
 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.)
 ---
 
 # 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.
 
 ## Dependencies
 
@@ -14,7 +15,7 @@ Orchestrate `.a5c/runs/<runId>/` through iterative execution.
 Read the SDK version from `versions.json` to ensure version compatibility:
 
 ```bash
-SDK_VERSION=$(node -e "try{const fs=require('fs');const probes=['./plugins/babysitter-opencode/versions.json','./node_modules/@a5c-ai/babysitter-opencode/versions.json'];for(const probe of probes){if(fs.existsSync(probe)){console.log(JSON.parse(fs.readFileSync(probe,'utf8')).sdkVersion||'latest');process.exit(0)}}console.log('latest')}catch{console.log('latest')}")
+SDK_VERSION=$(node -e "try{const fs=require('fs');const probes=['./plugins/babysitter-unified/versions.json','./node_modules/@a5c-ai/babysitter-opencode/versions.json'];for(const probe of probes){if(fs.existsSync(probe)){console.log(JSON.parse(fs.readFileSync(probe,'utf8')).sdkVersion||'latest');process.exit(0)}}console.log('latest')}catch{console.log('latest')}")
 
 npm i -g @a5c-ai/babysitter-sdk@$SDK_VERSION
 CLI="npx -y @a5c-ai/babysitter-sdk@$SDK_VERSION"

package/skills/call/SKILL.md

@@ -5,4 +5,8 @@ description: Orchestrate a babysitter run. use this command to start babysitting
 
 # call
 
-Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md).
+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.
+
+User arguments for this command:
+
+$ARGUMENTS

package/skills/cleanup/SKILL.md

@@ -11,11 +11,33 @@ Create and run a cleanup process using the process at `skills\babysit\process\cr
 
 Implementation notes (for the process):
 - Parse arguments for `--dry-run` flag (if present, set dryRun: true in inputs) and `--keep-days N` (default: 7)
-- The process scans .a5c/runs/ for completed/failed runs, aggregates insights, writes summaries, then removes old data
-- Always show the user what will be removed before removing (in interactive mode via breakpoints)
-- In non-interactive mode (yolo), proceed with cleanup using defaults
-- The insights file goes to docs/run-history-insights.md
-- Only remove terminal runs (completed/failed) older than the keep-days threshold
-- Never remove active/in-progress runs
-- Remove orphaned process files not referenced by remaining runs
-- After cleanup, show remaining run count and disk usage
+
+CRITICAL: The cleanup MUST follow this exact phase order. Do NOT delete any run before Phase 2 completes.
+
+Phase 1 — Scan:
+- Scan .a5c/runs/ for all runs
+- Classify each as terminal (completed/failed) or active (in-progress/created)
+- Identify terminal runs older than the keep-days threshold as removal candidates
+- Never mark active/in-progress runs for removal
+- Count and report: total runs, terminal, active, removal candidates, disk usage
+
+Phase 2 — Aggregate insights (BEFORE any deletion):
+- For EVERY removal candidate, read its run.json and journal/ events
+- Extract: processId, prompt, status, event count, created date, task summaries
+- Group by process type and extract patterns (retry counts, convergence behavior, failure modes)
+- Append a new dated section to docs/run-history-insights.md with:
+  - Summary statistics (runs removed, disk freed, runs retained)
+  - Run categories with counts and descriptions
+  - Key patterns observed (multi-batch convergence, retry behavior, etc.)
+  - What worked well / what didn't from the run data
+- This file MUST be written and verified before proceeding to Phase 3
+
+Phase 3 — Confirm removal:
+- In interactive mode, show the user what will be removed via a breakpoint
+- In non-interactive mode (yolo), proceed with defaults
+- In dry-run mode, stop here and show what would be removed
+
+Phase 4 — Remove:
+- Delete the terminal runs older than keep-days threshold
+- Identify and remove orphaned process files not referenced by remaining runs
+- Show remaining run count and disk usage after cleanup

package/skills/contrib/SKILL.md

@@ -5,30 +5,30 @@ description: Submit feedback or contribute to babysitter project
 
 # contrib
 
-Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md).
-
-## Process Routing
-
+Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md).
+
+## Process Routing
+
 Contribution processes live under the active process library's `cradle/` directory. Resolve the active library root with `babysitter process-library:active --json` and route based on arguments:
-
-### Issue-based (opens a GitHub issue in a5c-ai/babysitter)
- * **Bug report** → `cradle/bug-report.js#process` — Report a bug in the SDK, CLI, process library, etc.
- * **Feature request** → `cradle/feature-request.js#process` — Request a new feature or enhancement
- * **Documentation question** → `cradle/documentation-question.js#process` — Ask about undocumented behavior or missing docs
-
-### PR-based (forks repo, creates branch, submits PR to a5c-ai/babysitter)
- * **Bugfix** → `cradle/bugfix.js#process` — User already has the fix for a bug
- * **Feature implementation** → `cradle/feature-implementation-contribute.js#process` — User already has a feature implementation
- * **Harness integration** → `cradle/feature-harness-integration-contribute.js#process` — User has a harness (CI/CD, IDE, editor) integration
- * **Library contribution** → `cradle/library-contribution.js#process` — New or improved process/skill/subagent for the library
- * **Documentation answer** → `cradle/documentation-contribute-answer.js#process` — User has an answer for an unanswered docs question
-
-### Router (when arguments are empty or general)
- * **Contribute** → `cradle/contribute.js#process` — Explains contribution types and routes to the specific process
-
-## Contribution Rules
-
- * PR-based contributions: fork the babysitter repo (a5c-ai/babysitter) for the user, ask to star if not already starred, perform changes, submit PR
- * Issue-based contributions: gather details, search for duplicates, review, then open an issue in a5c-ai/babysitter
- * Add breakpoints (permissions) before ALL gh actions (fork, star, submit PR/issue) to allow user review and cancellation
+
+### Issue-based (opens a GitHub issue in a5c-ai/babysitter)
+ * **Bug report** → `cradle/bug-report.js#process` — Report a bug in the SDK, CLI, process library, etc.
+ * **Feature request** → `cradle/feature-request.js#process` — Request a new feature or enhancement
+ * **Documentation question** → `cradle/documentation-question.js#process` — Ask about undocumented behavior or missing docs
+
+### PR-based (forks repo, creates branch, submits PR to a5c-ai/babysitter)
+ * **Bugfix** → `cradle/bugfix.js#process` — User already has the fix for a bug
+ * **Feature implementation** → `cradle/feature-implementation-contribute.js#process` — User already has a feature implementation
+ * **Harness integration** → `cradle/feature-harness-integration-contribute.js#process` — User has a harness (CI/CD, IDE, editor) integration
+ * **Library contribution** → `cradle/library-contribution.js#process` — New or improved process/skill/subagent for the library
+ * **Documentation answer** → `cradle/documentation-contribute-answer.js#process` — User has an answer for an unanswered docs question
+
+### Router (when arguments are empty or general)
+ * **Contribute** → `cradle/contribute.js#process` — Explains contribution types and routes to the specific process
+
+## Contribution Rules
+
+ * PR-based contributions: fork the babysitter repo (a5c-ai/babysitter) for the user, ask to star if not already starred, perform changes, submit PR
+ * Issue-based contributions: gather details, search for duplicates, review, then open an issue in a5c-ai/babysitter
+ * Add breakpoints (permissions) before ALL gh actions (fork, star, submit PR/issue) to allow user review and cancellation
  * If arguments are empty: use the `contribute.js` router process to show options and route accordingly

package/skills/doctor/SKILL.md

@@ -157,7 +157,6 @@ If it exists:
 **Goal:** Inspect babysitter session files for health and detect runaway loops.
 
 - Search for session state files using Glob:
-  - `plugins/babysitter/skills/babysit/state/*.md`
   - `.a5c/state/*.md`
   - `.a5c/state/*.json`
 - For each session state file found:
@@ -261,7 +260,7 @@ Mark as PASS if total size < 500MB and no files > 10MB. Mark as WARN if total si
 
 ### 10a. Hook Registration
 
-- Locate the plugin root. Check for `CLAUDE_PLUGIN_ROOT` env var, or search for `plugins/babysitter/hooks/hooks.json` by walking up from the current directory.
+- Locate the plugin root. Check for `CLAUDE_PLUGIN_ROOT` env var first, or search for a babysitter `hooks.json` by walking up from the current directory.
 - If found, read `hooks.json` and verify:
   - A `Stop` hook entry exists with a command referencing `babysitter-stop-hook.sh`.
   - A `SessionStart` hook entry exists with a command referencing `babysitter-session-start-hook.sh`.
@@ -316,7 +315,7 @@ If the stop hook shows NO evidence of execution (no log entries, no journal even
 
 Perform these diagnostic steps in order and report the first failure found:
 
-1. **Plugin not installed**: Check if `plugins/babysitter/` exists relative to the project root and if `CLAUDE_PLUGIN_ROOT` is set. If the plugin directory doesn't exist, report: "Plugin not installed — the babysitter plugin directory is missing."
+1. **Plugin not installed**: Check if `CLAUDE_PLUGIN_ROOT` is set or if a babysitter plugin directory exists relative to the project root. If neither exists, report: "Plugin not installed — the babysitter plugin directory is missing."
 
 2. **Plugin not enabled**: Check for Claude settings files:
    - `~/.claude/settings.json` — look for `babysitter` in `enabledPlugins`.

package/skills/help/SKILL.md

@@ -234,7 +234,8 @@ SECONDARY COMMANDS
   How it works: Runs npx @a5c-ai/babysitter-observer-dashboard@latest which watches
   the .a5c/runs/ directory (or a parent directory containing multiple projects) and
   serves a live dashboard. The process is blocking -- it runs until you stop it, and
-  it prints the local URL to share with the user.
+  it prints the local URL to share with the user. Do not use `babysitter observe`
+  as a fallback; the core Babysitter CLI does not expose that subcommand.
 
   Example: /babysitter:observe
   (opens browser showing all runs with live-updating task

package/skills/observe/SKILL.md

@@ -8,6 +8,11 @@ description: Launch the babysitter observer dashboard. Installs and runs the rea
 Run the babysitter observer dashboard:
 
 1. 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.
-2. Launch the dashboard: `npx -y @a5c-ai/babysitter-observer-dashboard@latest --watch-dir <dir>`
+2. Launch the standalone dashboard package: `npx -y @a5c-ai/babysitter-observer-dashboard@latest --watch-dir <dir>`.
 3. This is a blocking process — it will keep running until stopped.
 4. Report the URL printed by the dashboard to the user, then open it in the browser.
+
+Do not fall back to `babysitter observe`; the core Babysitter CLI does not expose
+that subcommand. Some harness runtimes may provide a separate
+`agent-platform observe` surface, but this skill uses the verified standalone
+dashboard package.