@a5c-ai/babysitter-github 5.0.1-staging.d73033a7 → 5.0.1-staging.d8bdfcceaf4a

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`.
@@ -363,13 +362,13 @@ Mark as FAIL if:
 - Parse the output and inspect the `resolvedFrom` field. Classify as follows:
   - `resolvedFrom: "pid-marker"` → mark as PASS ("Session ID derives from the live Claude Code ancestor process -- authoritative").
   - `resolvedFrom: "env-file"` → mark as PASS with a note ("CLAUDE_ENV_FILE was used; typically healthy").
-  - `resolvedFrom: "env-var"` → mark as WARN ("`BABYSITTER_SESSION_ID` is set without a corroborating PID marker. Likely stale from a prior Claude Code session -- see GitHub issue #130").
-    - Remediation: run `babysitter session:cleanup` and start a fresh Claude Code session, or `unset BABYSITTER_SESSION_ID` before invoking babysitter.
+  - `resolvedFrom: "env-var"` → mark as WARN ("`AGENT_SESSION_ID` is set without a corroborating PID marker. Likely stale from a prior Claude Code session -- see GitHub issue #130").
+    - Remediation: run `babysitter session:cleanup` and start a fresh Claude Code session, or `unset AGENT_SESSION_ID` before invoking babysitter.
   - `resolvedFrom: "none"` → mark as ERROR ("No session ID resolvable. Either no session-start hook fired, or the ancestor walk failed").
 
 **Env-var shadow check:**
 - Independently inspect `envVarPresent` and `envVarMatches` in the output.
-- If `envVarPresent && !envVarMatches`, mark as WARN ("`BABYSITTER_SESSION_ID` in env does not match the resolved session ID; a stale value is shadowing the authoritative one. Unset the env var").
+- If `envVarPresent && !envVarMatches`, mark as WARN ("`AGENT_SESSION_ID` in env does not match the resolved session ID; a stale value is shadowing the authoritative one. Unset the env var").
 
 ---
 
@@ -391,7 +390,7 @@ Mark as FAIL if:
 
 - Enumerate files in `~/.a5c/` matching the pattern `current-session-*-pid-*`.
 - Count markers per harness (derived from the filename).
-- If more than one live marker exists for the same harness, mark as INFO ("Multiple live Claude Code / harness sessions detected; ensure each shell scopes `BABYSITTER_SESSION_ID` appropriately -- the PID marker handles this automatically").
+- If more than one live marker exists for the same harness, mark as INFO ("Multiple live Claude Code / harness sessions detected; ensure each shell scopes `AGENT_SESSION_ID` appropriately -- the PID marker handles this automatically").
 - Otherwise mark as PASS.
 
 ---
@@ -502,7 +501,7 @@ babysitter session:cleanup --dry-run   # preview
 babysitter session:cleanup             # apply
 
 # 2. Unset a stale env var
-unset BABYSITTER_SESSION_ID
+unset AGENT_SESSION_ID
 
 # 3. Re-bind a run explicitly if needed
 babysitter session:resume --session-id <fresh-id> --state-dir ~/.a5c --run-id <runId> --runs-dir .a5c/runs

package/skills/forever/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: forever
+description: Use this command to start babysitting a never-ending babysitter run.
+---
+
+# forever
+
+Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md). but create a process that uses an infinte loop and a ctx.sleep to create a never-ending babysitter loop. an example of such process is a daily process that reads new support ticket every day and tries to resolve them, then sleeps for 4 hours and repeats the process.

package/skills/help/SKILL.md

@@ -231,9 +231,11 @@ SECONDARY COMMANDS
   effect status in your browser. Useful when running /yolo or /forever to watch
   progress without interrupting the run.
 
-  How it works: Runs npx @yoavmayer/babysitter-observer-dashboard@latest which watches
+  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.
+  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. 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. Open the browser at the URL printed by the dashboard.
+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.

package/skills/plugins/SKILL.md

@@ -0,0 +1,257 @@
+---
+name: plugins
+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).
+---
+
+# plugins
+
+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.
+
+if 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.
+if there are no marketplaces added, add the default marketplace:
+```bash
+babysitter plugin:add-marketplace --marketplace-url https://github.com/a5c-ai/babysitter --marketplace-path plugins/a5c/marketplace/marketplace.json --global --json
+```
+
+Plugins can be installed at two scopes:
+- **global** (`--global`): stored under `~/.a5c/`, available for all projects
+- **project** (`--project`): stored under `<projectDir>/.a5c/`, project-specific
+
+## Marketplace Management
+
+Marketplaces are git repositories containing a `marketplace.json` manifest and plugin package directories. The SDK clones them locally with `--depth 1`.
+
+**Storage locations:**
+- Global: `~/.a5c/marketplaces/<name>/`
+- Project: `<projectDir>/.a5c/marketplaces/<name>/`
+
+The marketplace name is derived from the git URL's last path segment (stripping `.git` suffix and trailing slashes).
+
+### Adding a marketplace
+
+```bash
+babysitter plugin:add-marketplace --marketplace-url <url> [--marketplace-path <relative-path>] [--marketplace-branch <ref>] [--force] --global|--project [--json]
+```
+
+Clones 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).
+
+### Updating a marketplace
+
+```bash
+babysitter plugin:update-marketplace --marketplace-name <name> [--marketplace-branch <ref>] --global|--project [--json]
+```
+
+Runs `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).
+
+### Listing plugins in a marketplace
+
+```bash
+babysitter plugin:list-plugins --marketplace-name <name> --global|--project [--json]
+```
+
+Reads 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.
+
+## Plugin Installation
+
+**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.
+
+### Flow
+
+1. Update the marketplace: `babysitter plugin:update-marketplace --marketplace-name <name> --global|--project`
+2. Check current state: `babysitter plugin:list-installed --global|--project` to see installed plugins and versions
+3. Install the plugin:
+
+```bash
+babysitter plugin:install --plugin-name <name> [--marketplace-name <mp>] --global|--project [--json]
+```
+
+This 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.
+
+4. The agent performs the installation steps as defined in `install.md`
+5. The agent updates the registry:
+
+```bash
+babysitter plugin:update-registry --plugin-name <name> --plugin-version <ver> --marketplace-name <mp> --global|--project [--json]
+```
+
+## Plugin Update (with migrations)
+
+```bash
+babysitter plugin:update --plugin-name <name> --marketplace-name <mp> --global|--project [--json]
+```
+
+This command:
+1. Reads the currently installed version from the registry
+2. Resolves the latest version from the marketplace manifest
+3. Looks in the plugin package's `migrations/` directory for migration files
+4. Uses BFS over the migration graph to find the shortest path from the installed version to the target version
+5. Returns the ordered migration instructions (content of each migration file in sequence)
+
+**Migration filename format:** `<fromVersion>_to_<toVersion>.<ext>` where:
+- Versions may contain alphanumerics, dots, dashes (e.g. `1.0.0`, `2.0.0-beta`)
+- Extensions: `.md` for markdown instructions, `.js` for executable process files
+- Examples: `1.0.0_to_1.1.0.md`, `2.0.0-beta_to_2.0.0.js`
+
+After performing the migration steps, update the registry:
+
+```bash
+babysitter plugin:update-registry --plugin-name <name> --plugin-version <new-ver> --marketplace-name <mp> --global|--project [--json]
+```
+
+## Plugin Uninstallation
+
+```bash
+babysitter plugin:uninstall --plugin-name <name> --marketplace-name <mp> --global|--project [--json]
+```
+
+Reads `uninstall.md` from the plugin package directory and returns the uninstall instructions. After performing the uninstall steps, remove from registry:
+
+```bash
+babysitter plugin:remove-from-registry --plugin-name <name> --global|--project [--json]
+```
+
+## Plugin Configuration
+
+```bash
+babysitter plugin:configure --plugin-name <name> --marketplace-name <mp> --global|--project [--json]
+```
+
+Reads `configure.md` from the plugin package directory and returns configuration instructions.
+
+## Registry Management
+
+The 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.
+
+**Storage locations:**
+- Global: `~/.a5c/plugin-registry.json`
+- Project: `<projectDir>/.a5c/plugin-registry.json`
+
+### List installed plugins
+
+```bash
+babysitter plugin:list-installed --global|--project [--json]
+```
+
+Returns 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.
+
+### Remove from registry
+
+```bash
+babysitter plugin:remove-from-registry --plugin-name <name> --global|--project [--json]
+```
+
+Removes a plugin entry from the registry. Returns error if the plugin is not present.
+
+## Plugin Creation
+
+To 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.
+
+### Using the plugin creation process
+
+Orchestrate a babysitter run with the plugin creation process:
+
+```bash
+# Create inputs file
+cat > /tmp/plugin-inputs.json << 'EOF'
+{
+  "pluginName": "my-plugin",
+  "description": "What the plugin does — be specific about install/configure/uninstall behavior",
+  "scope": "project",
+  "outputDir": "./plugins",
+  "components": {
+    "installProcess": false,
+    "configureProcess": false,
+    "uninstallProcess": false,
+    "migrations": false,
+    "processFiles": false
+  },
+  "marketplace": {
+    "name": "my-marketplace",
+    "author": "my-org",
+    "tags": ["category1", "category2"]
+  }
+}
+EOF
+
+# Create and run
+babysitter run:create \
+  --process-id meta/plugin-creation \
+  --entry library/specializations/meta/plugin-creation.js#process \
+  --inputs /tmp/plugin-inputs.json \
+  --prompt "Create a new babysitter plugin package" \
+  --json
+```
+
+### What the process generates
+
+The process creates a complete plugin package directory:
+
+| File | Description |
+|------|-------------|
+| `install.md` | Agent-readable installation instructions with numbered steps |
+| `uninstall.md` | Reversal instructions for clean removal |
+| `configure.md` | Configuration options table and adjustment instructions |
+| `install-process.js` | *(optional)* Automated babysitter process for complex install steps |
+| `configure-process.js` | *(optional)* Automated configuration process |
+| `process/main.js` | *(optional)* Main process the plugin contributes |
+| `marketplace-entry.json` | Ready-to-use marketplace.json entry for publishing |
+
+### Process phases
+
+1. **Requirements Analysis** — Analyzes plugin purpose, prerequisites, config options, file structure
+2. **Structure Design** — Plans directory layout and file inventory (with review breakpoint)
+3. **Instruction Authoring** — Writes install.md, uninstall.md, configure.md
+4. **Process Files** — Creates optional babysitter process files (install-process.js, configure-process.js, process/main.js)
+5. **Validation** — Verifies package completeness, instruction quality, path correctness
+6. **Marketplace Integration** — Generates marketplace.json entry for publishing
+
+### Quick creation (without orchestration)
+
+For 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).
+
+## Plugin Package Structure
+
+```
+my-plugin/
+  package.json         # Optional (name field used as plugin ID, falls back to directory name)
+  install.md           # Markdown instructions for installation
+  uninstall.md         # Markdown instructions for removal
+  configure.md         # Markdown instructions for configuration
+  install-process.js   # Optional automated install process
+  uninstall-process.js # Optional automated uninstall process
+  configure-process.js # Optional automated configure process
+  migrations/          # Version migration files
+    1.0.0_to_1.1.0.md
+    1.1.0_to_2.0.0.js
+  process/             # Process definition files (collected recursively)
+    main.js
+```
+
+## All CLI Commands Summary
+
+All commands accept `--json` for machine-readable output and `--global|--project`.
+
+| Command | Required Flags | Description |
+|---------|---------------|-------------|
+| `plugin:add-marketplace` | `--marketplace-url`, `--global\|--project` [`--marketplace-path`, `--marketplace-branch`, `--force`] | Clone a marketplace repository |
+| `plugin:update-marketplace` | `--marketplace-name`, `--global\|--project` [`--marketplace-branch`] | Pull latest marketplace changes (optionally switch branch) |
+| `plugin:list-plugins` | `--marketplace-name`, `--global\|--project` | List available plugins in a marketplace |
+| `plugin:install` | `--plugin-name`, `--marketplace-name`, `--global\|--project` | Get install instructions for a plugin |
+| `plugin:uninstall` | `--plugin-name`, `--marketplace-name`, `--global\|--project` | Get uninstall instructions for a plugin |
+| `plugin:update` | `--plugin-name`, `--marketplace-name`, `--global\|--project` | Resolve migration chain and get update instructions |
+| `plugin:configure` | `--plugin-name`, `--marketplace-name`, `--global\|--project` | Get configuration instructions for a plugin |
+| `plugin:list-installed` | `--global\|--project` | List all installed plugins |
+| `plugin:update-registry` | `--plugin-name`, `--plugin-version`, `--marketplace-name`, `--global\|--project` | Register or update a plugin entry |
+| `plugin:remove-from-registry` | `--plugin-name`, `--global\|--project` | Remove a plugin entry from the registry |
+
+## After Plugin Work: Contribute Back
+
+After working with plugins, prompt the user to share improvements or report issues:
+
+- **Improved a plugin's install/configure/uninstall instructions**: `/babysitter:contrib library contribution: improved [plugin-name] [install|configure|uninstall] instructions`
+- **Created a new plugin**: `/babysitter:contrib library contribution: new plugin [plugin-name] -- [description]`
+- **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"]`
+- **Plugin install/configure instructions were confusing or wrong**: `/babysitter:contrib bug report: [plugin-name] install instructions [description of what was wrong]`
+- **Have an idea for a new plugin**: `/babysitter:contrib feature request: plugin idea -- [description]`
+
+Even reporting that a plugin's instructions were unclear helps improve it for the next user.

package/skills/project-install/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: project-install
+description: Set up a project for babysitting. Guides you through onboarding a new or existing project — researches the codebase, interviews you about goals and workflows, builds the project profile, installs the best tools, and optionally configures CI/CD integration.
+---
+
+# project-install
+
+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
+babysitter process-library:active --json
+```
+
+Then use the `cradle/project-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

package/skills/resume/SKILL.md

@@ -5,5 +5,5 @@ description: Resume orchestrating of a babysitter run. use this command to resum
 
 # resume
 
-Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md). to resume a run.
+Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md). to resume a run.
 if no run was given, discover the runs and suggest which incomplete run to resume based on the run's status, inputs, process , etc.

package/skills/retrospect/SKILL.md

@@ -5,52 +5,52 @@ description: Analysis for a run and its results, process, suggestions for proces
 
 # retrospect
 
-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]`
+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/skills/user-install/SKILL.md

@@ -5,8 +5,8 @@ description: Set up babysitter for yourself. Guides you through onboarding — i
 
 # user-install
 
-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).
+
 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
@@ -14,5 +14,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

package/skills/yolo/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: yolo
+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.
+---
+
+# yolo
+
+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/versions.json

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

package/.github/plugin.json

@@ -1,25 +0,0 @@
-{
-  "name": "babysitter",
-  "version": "0.1.0",
-  "description": "Orchestrate complex, multi-step workflows with event-sourced state management, hook-based extensibility, and human-in-the-loop approval -- powered by the Babysitter SDK",
-  "author": { "name": "a5c.ai", "email": "support@a5c.ai" },
-  "license": "MIT",
-  "skills": "skills/",
-  "hooks": "hooks.json",
-  "commands": "commands/",
-  "agents": "AGENTS.md",
-  "repository": {
-    "type": "git",
-    "url": "https://github.com/a5c-ai/babysitter"
-  },
-  "keywords": [
-    "orchestration",
-    "workflow",
-    "automation",
-    "event-sourced",
-    "hooks",
-    "github-copilot",
-    "agent",
-    "LLM"
-  ]
-}

package/hooks/proxied-hooks.json

@@ -1,29 +0,0 @@
-{
-  "_comment": "NOT ACTIVE — Alternative hook registration using per-hook unified scripts with hooks-proxy support. To activate, update the harness plugin configuration to reference these scripts.",
-  "hooks": {
-    "sessionStart": [
-      {
-        "type": "command",
-        "bash": "bash \"./hooks/babysitter-proxied-session-start.sh\"",
-        "powershell": "powershell -NoProfile -ExecutionPolicy Bypass -File \"./hooks/babysitter-proxied-session-start.ps1\"",
-        "timeoutSec": 30
-      }
-    ],
-    "sessionEnd": [
-      {
-        "type": "command",
-        "bash": "bash \"./hooks/babysitter-proxied-session-end.sh\"",
-        "powershell": "powershell -NoProfile -ExecutionPolicy Bypass -File \"./hooks/babysitter-proxied-session-end.ps1\"",
-        "timeoutSec": 30
-      }
-    ],
-    "userPromptSubmitted": [
-      {
-        "type": "command",
-        "bash": "bash \"./hooks/babysitter-proxied-user-prompt-submitted.sh\"",
-        "powershell": "powershell -NoProfile -ExecutionPolicy Bypass -File \"./hooks/babysitter-proxied-user-prompt-submitted.ps1\"",
-        "timeoutSec": 15
-      }
-    ]
-  }
-}

package/hooks/session-end.ps1

@@ -1,69 +0,0 @@
-# Babysitter Session End Hook for GitHub Copilot CLI (PowerShell)
-# Cleanup and logging on session exit.
-#
-# NOTE: Unlike Claude Code's Stop hook, sessionEnd output is IGNORED by
-# Copilot CLI. This hook cannot block session exit or drive an orchestration
-# loop. It is purely for cleanup and logging.
-
-$ErrorActionPreference = "Continue"
-
-$PluginRoot = if ($env:COPILOT_PLUGIN_DIR) { $env:COPILOT_PLUGIN_DIR } else { Split-Path -Parent $PSScriptRoot }
-
-# Resolve babysitter CLI
-$hasBabysitter = [bool](Get-Command babysitter -ErrorAction SilentlyContinue)
-$useFallback = $false
-
-if (-not $hasBabysitter) {
-    $localBin = Join-Path $env:USERPROFILE ".local\bin\babysitter.cmd"
-    if (Test-Path $localBin) {
-        $env:PATH = "$(Split-Path $localBin);$env:PATH"
-        $hasBabysitter = $true
-    } else {
-        $versionsFile = Join-Path $PluginRoot "versions.json"
-        try {
-            $SdkVersion = (Get-Content $versionsFile -Raw | ConvertFrom-Json).sdkVersion
-            if (-not $SdkVersion) { $SdkVersion = "latest" }
-        } catch {
-            $SdkVersion = "latest"
-        }
-        $useFallback = $true
-    }
-}
-
-$GlobalRoot = if ($env:BABYSITTER_GLOBAL_STATE_DIR) { $env:BABYSITTER_GLOBAL_STATE_DIR } else { Join-Path $HOME ".a5c" }
-$LogDir = if ($env:BABYSITTER_LOG_DIR) { $env:BABYSITTER_LOG_DIR } else { Join-Path $GlobalRoot "logs" }
-$LogFile = Join-Path $LogDir "babysitter-session-end-hook.log"
-New-Item -ItemType Directory -Path $LogDir -Force -ErrorAction SilentlyContinue | Out-Null
-
-function Write-Blog {
-    param([string]$Message)
-    $ts = (Get-Date).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ")
-    Add-Content -Path $LogFile -Value "[INFO] $ts $Message" -ErrorAction SilentlyContinue
-}
-
-Write-Blog "Hook script invoked"
-Write-Blog "PLUGIN_ROOT=$PluginRoot"
-
-# Capture stdin
-$InputFile = [System.IO.Path]::GetTempFileName()
-$input | Out-File -FilePath $InputFile -Encoding utf8
-
-Write-Blog "Hook input received"
-
-$stderrLog = Join-Path $LogDir "babysitter-session-end-hook-stderr.log"
-
-try {
-    if ($useFallback) {
-        Get-Content $InputFile | & npx -y "@a5c-ai/babysitter-sdk@$SdkVersion" hook:run --hook-type session-end --harness github-copilot --plugin-root $PluginRoot --json 2>$stderrLog | Out-Null
-    } elseif ($hasBabysitter) {
-        Get-Content $InputFile | & babysitter hook:run --hook-type session-end --harness github-copilot --plugin-root $PluginRoot --json 2>$stderrLog | Out-Null
-    }
-} catch {
-    Write-Blog "Hook error: $_"
-}
-
-Write-Blog "Session end hook complete"
-
-Remove-Item $InputFile -Force -ErrorAction SilentlyContinue
-
-exit 0