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

package/skills/blueprints/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: blueprints
+description: manage Babysitter blueprints. Use this command to list installed blueprints, browse marketplaces, install, update, uninstall, configure, or create a new blueprint.
+---
+
+# blueprints
+
+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.
+
+If 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.
+
+Blueprints 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 blueprint package directories. The SDK clones new marketplaces to `.a5c/blueprints/marketplaces/` for the selected scope and reads legacy `.a5c/marketplaces/` clones for compatibility.
+
+### Add a marketplace
+
+```bash
+babysitter blueprint:add-marketplace --marketplace-url <url> [--marketplace-path <relative-path>] [--marketplace-branch <ref>] [--force] --global|--project [--json]
+```
+
+### Update a marketplace
+
+```bash
+babysitter blueprint:update-marketplace --marketplace-name <name> [--marketplace-branch <ref>] --global|--project [--json]
+```
+
+### List blueprints in a marketplace
+
+```bash
+babysitter blueprint:list-plugins --marketplace-name <name> --global|--project [--json]
+```
+
+## Blueprint Lifecycle
+
+For `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.
+
+```bash
+babysitter blueprint:install --plugin-name <name> [--marketplace-name <mp>] --global|--project [--json]
+babysitter blueprint:update --plugin-name <name> --marketplace-name <mp> --global|--project [--json]
+babysitter blueprint:configure --plugin-name <name> --marketplace-name <mp> --global|--project [--json]
+babysitter blueprint:uninstall --plugin-name <name> --marketplace-name <mp> --global|--project [--json]
+```
+
+The `--plugin-name` flag is preserved for CLI compatibility with existing marketplace manifests. User-facing docs should call the installable a blueprint.
+
+## Registry Management
+
+```bash
+babysitter blueprint:list-installed --global|--project [--json]
+babysitter blueprint:update-registry --plugin-name <name> --plugin-version <ver> --marketplace-name <mp> --global|--project [--json]
+babysitter blueprint:remove-from-registry --plugin-name <name> --global|--project [--json]
+```
+
+## Deprecated Aliases
+
+The old `plugin:*` commands remain available as deprecated aliases for one release. Prefer `blueprint:*` in new docs, skills, and process instructions.
+
+## Agent Plugins Are Separate
+
+Do 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/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/check-forbidden-markers/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: check-forbidden-markers
+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
+---
+
+# check-forbidden-markers
+
+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).
+
+## What this gate does
+
+Reads 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`.
+
+Use 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.
+
+## When to use
+
+- **Pre-deploy.** Insert after build, before deploy. Block the deploy when `ok: false`.
+- **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.
+- **Post-refactor.** When old helper / handler / module names must not coexist with the new ones in the same bundle.
+
+## Expected config locations
+
+- `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.
+- `.vercel/output/static/_next/static/chunks/` — default scan target. Override for non-Vercel frameworks via the `--chunks-dir` flag or the `chunksDir` task input.
+
+A 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.
+
+## Exit semantics
+
+| Reason                  | `ok`   | Deploy decision                |
+|-------------------------|--------|--------------------------------|
+| `missing-markers-file`  | true   | Pass (no gate active)          |
+| `missing-chunks-dir`    | true   | Pass (run before build)        |
+| `empty-markers`         | true   | Pass (list is empty)           |
+| `no-chunks`             | true   | Pass (nothing to scan)         |
+| `clean`                 | true   | Pass — proceed to deploy       |
+| `hits`                  | false  | **BLOCK** — surface hits, ask for triage |
+
+For 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.
+
+## Programmatic surface
+
+```js
+import { scanForbiddenMarkers, checkForbiddenMarkersTask } from '@a5c-ai/babysitter-library/processes/shared';
+
+// Direct call:
+const result = await scanForbiddenMarkers({
+  markersFile: 'scripts/forbidden-markers.txt',
+  chunksDir:   '.vercel/output/static/_next/static/chunks',
+});
+if (!result.ok) {
+  // result.hits: Array<{ marker, chunk, count }>
+  // result.reason === 'hits'
+  process.exit(1);
+}
+
+// Or dispatched as a babysitter task:
+const gate = await ctx.task(checkForbiddenMarkersTask, {
+  projectDir: '.',
+  // markersFile / chunksDir are inferred from projectDir if omitted
+});
+```
+
+## Reference
+
+- Issue: https://github.com/a5c-ai/babysitter/issues/477
+- Helper module: `library/processes/shared/forbidden-markers-scanner.js`
+- Origin (cookbook prototype): `cookbook/scripts/check-no-forbidden.mjs` (81 lines)

package/skills/cleanup/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: cleanup
+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.
+---
+
+# cleanup
+
+Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md).
+
+Resolve the active process library with:
+
+```bash
+babysitter process-library:active --json
+```
+
+Read `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.
+
+Implementation notes (for the process):
+- Parse arguments for `--dry-run` flag (if present, set dryRun: true in inputs) and `--keep-days N` (default: 7)
+
+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

@@ -0,0 +1,34 @@
+---
+name: contrib
+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
+
+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
+ * 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`.
@@ -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

@@ -180,13 +180,13 @@ SECONDARY COMMANDS
   a fuzzy comparison step before strict assertion. Implement this fix?")
 
 
-/babysitter:plugins [action]
-  Manage babysitter plugins: list installed plugins, browse marketplaces, install,
-  update, configure, uninstall, or create new plugins. Plugins are version-managed
-  instruction packages (not executable code) that guide the agent through install,
-  configure, and uninstall steps via markdown files.
+/babysitter:blueprints [action]
+  Manage Babysitter blueprints: list installed blueprints, browse marketplaces,
+  install, update, configure, uninstall, or create new blueprints. Blueprints are
+  version-managed instruction packages or process bundles that guide the agent
+  through install, configure, and uninstall steps.
 
-  Without arguments: shows installed plugins (name, version, marketplace, dates) and
+  Without arguments: shows installed blueprints (name, version, marketplace, dates) and
   available marketplaces. With arguments: routes to the specific action.
 
   Key actions:
@@ -194,11 +194,11 @@ SECONDARY COMMANDS
   - configure <name> --global|--project: fetch configure.md and walk through options
   - update <name> --global|--project: resolve migration chain via BFS and apply steps
   - uninstall <name> --global|--project: fetch uninstall.md and execute removal
-  - create: scaffold a new plugin package with the meta/plugin-creation process
+  - create: scaffold a new blueprint package
 
-  Example: /babysitter:plugins install sound-hooks --project
+  Example: /babysitter:blueprints install sound-hooks --project
   (fetches sound-hooks from marketplace, reads install.md, walks you through player
-  detection, sound selection, hook configuration, and registers in plugin-registry.json)
+  detection, sound selection, hook configuration, and registers the blueprint)
 
 
 /babysitter:contrib [feedback]
@@ -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/plan/SKILL.md

@@ -5,4 +5,14 @@ description: Plan a babysitter run. use this command to plan a complex workflow,
 
 # plan
 
-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.
+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.
+
+Before 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.
+
+## Process Shape Selection
+
+Choose the process shape before authoring `process.js`:
+
+- 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.
+- 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.
+- 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/skills/plugins/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: plugins
+description: deprecated alias for the Babysitter blueprints command. Use /babysitter:blueprints for marketplace installables.
+---
+
+# plugins
+
+This command is a deprecated alias for `/babysitter:blueprints`.
+
+For Babysitter marketplace installables, use blueprints terminology and the `babysitter blueprint:*` CLI command family:
+
+```bash
+babysitter blueprint:list-installed --global|--project [--json]
+babysitter blueprint:add-marketplace --marketplace-url <url> [--marketplace-path <relative-path>] --global|--project [--json]
+babysitter blueprint:list-plugins --marketplace-name <name> --global|--project [--json]
+babysitter blueprint:install --plugin-name <name> [--marketplace-name <mp>] --global|--project [--json]
+babysitter blueprint:update --plugin-name <name> [--marketplace-name <mp>] --global|--project [--json]
+babysitter blueprint:configure --plugin-name <name> [--marketplace-name <mp>] --global|--project [--json]
+babysitter blueprint:uninstall --plugin-name <name> [--marketplace-name <mp>] --global|--project [--json]
+```
+
+The `--plugin-name` flag remains for CLI compatibility with existing marketplace manifests. Describe the installable as a blueprint in user-facing text.
+
+Agent 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/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/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. Use Bash to run `babysitter instructions:babysit-skill --harness github-copilot --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.
+
+User arguments for this command:
+
+$ARGUMENTS

package/versions.json

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

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

package/hooks/session-end.sh

@@ -1,54 +0,0 @@
-#!/bin/bash
-# Babysitter Session End Hook for GitHub Copilot CLI
-# 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.
-#
-# Protocol:
-#   Input:  JSON via stdin (session context)
-#   Output: IGNORED by Copilot CLI
-#   Exit 0: success (exit code also ignored)
-
-set -uo pipefail
-
-PLUGIN_ROOT="${COPILOT_PLUGIN_DIR:-$(cd "$(dirname "$0")/.." && pwd)}"
-
-if ! command -v babysitter &>/dev/null; then 
-  # No CLI available — exit 0 (no-op, proceed with original command)
-  exit 0
-fi
-
-GLOBAL_ROOT="${BABYSITTER_GLOBAL_STATE_DIR:-$HOME/.a5c}"
-LOG_DIR="${BABYSITTER_LOG_DIR:-${GLOBAL_ROOT}/logs}"
-LOG_FILE="$LOG_DIR/babysitter-session-end-hook.log"
-
-mkdir -p "$LOG_DIR" 2>/dev/null
-
-# Structured logging helper
-blog() {
-  local msg="$1"
-  local ts
-  ts="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
-  echo "[INFO] $ts $msg" >> "$LOG_FILE" 2>/dev/null
-  babysitter log --type hook --label "hook:session-end" --message "$msg" --source shell-hook 2>/dev/null || true
-}
-
-blog "Hook script invoked"
-blog "PLUGIN_ROOT=$PLUGIN_ROOT"
-
-# Capture stdin so we can log size and pass to CLI
-INPUT_FILE=$(mktemp 2>/dev/null || echo "/tmp/hook-session-end-$$.json")
-cat > "$INPUT_FILE"
-
-blog "Hook input received ($(wc -c < "$INPUT_FILE") bytes)"
-
-# Run cleanup/logging via CLI; output is ignored by Copilot CLI
-babysitter hook:run --hook-type session-end --harness github-copilot --plugin-root "$PLUGIN_ROOT" --json < "$INPUT_FILE" 2>"$LOG_DIR/babysitter-session-end-hook-stderr.log" || true
-
-blog "Session end hook complete"
-
-rm -f "$INPUT_FILE" 2>/dev/null
-
-exit 0