@a5c-ai/babysitter-opencode 5.0.1-staging.3e9ebe56e689 → 5.0.1-staging.3edc9d7b8d6f

package/bin/install-shared.js

@@ -29,7 +29,7 @@ function writeFileIfChanged(filePath, contents) {
   try {
     const existing = fs.readFileSync(filePath, 'utf8');
     if (existing === contents) return false;
-  } catch {}
+  } catch (e) { process.stderr.write('[extension-mux] file read failed for ' + filePath + ', overwriting: ' + (e instanceof Error ? e.message : String(e)) + '\n'); }
   fs.mkdirSync(path.dirname(filePath), { recursive: true });
   fs.writeFileSync(filePath, contents);
   return true;
@@ -82,7 +82,7 @@ function writeJson(filePath, value) {
 function ensureExecutable(filePath) {
   try {
     fs.chmodSync(filePath, 0o755);
-  } catch {}
+  } catch (e) { process.stderr.write('[extension-mux] chmod failed for ' + filePath + ': ' + (e instanceof Error ? e.message : String(e)) + '\n'); }
 }
 
 function normalizeMarketplaceSourcePath(source, marketplacePath) {
@@ -104,7 +104,7 @@ function ensureMarketplaceEntry(marketplacePath, pluginRoot) {
     name: PLUGIN_NAME,
     source: relSource,
     description: "Orchestrate complex, multi-step workflows with event-sourced state management, hook-based extensibility, and human-in-the-loop approval",
-    version: "5.0.1-staging.3e9ebe56e689",
+    version: "5.0.1-staging.3edc9d7b8d6f",
     author: { name: "a5c.ai" },
   };
   if (idx >= 0) marketplace.plugins[idx] = entry;
@@ -147,7 +147,7 @@ function resolveCliCommand(packageRoot) {
   const versionsPath = path.join(packageRoot, 'versions.json');
   const versions = readJson(versionsPath) || {};
   const ver = versions.sdkVersion || 'latest';
-  return `npx -y @a5c-ai/babysitter-sdk@${ver}`;
+  return `npm exec --yes --package @a5c-ai/babysitter-sdk@${ver} -- babysitter`;
 }
 
 function runCli(packageRoot, cliArgs, options = {}) {

package/commands/blueprints.md

@@ -0,0 +1,64 @@
+---
+description: manage Babysitter blueprints. Use this command to list installed blueprints, browse marketplaces, install, update, uninstall, configure, or create a new blueprint.
+argument-hint: Blueprint action and options.
+---
+
+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/commands/call.md

@@ -1,9 +1,9 @@
----
-description: Orchestrate a babysitter run. use this command to start babysitting a complex 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
----
-
+---
+description: Orchestrate a babysitter run. use this command to start babysitting a complex 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). 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:

package/commands/check-forbidden-markers.md

@@ -0,0 +1,68 @@
+---
+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
+argument-hint: "[--markers-file <path>] [--chunks-dir <path>] [--json] Optional overrides; defaults are project-relative."
+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). 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/commands/cleanup.md

@@ -6,7 +6,13 @@ allowed-tools: Read, Grep, Write, Task, Bash, Edit, Grep, Glob, WebFetch, WebSea
 
 Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md).
 
-Create and run a cleanup process using the process at `skills\babysit\process\cradle\cleanup-runs.js/processes/cleanup-runs.js`.
+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)

package/commands/contrib.md

@@ -1,33 +1,33 @@
----
-description: Submit feedback or contribute to babysitter project
-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).
-
-## Process Routing
-
+---
+description: Submit feedback or contribute to babysitter project
+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).
+
+## 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/commands/forever.md

@@ -1,7 +1,7 @@
----
-description: Use this command to start babysitting a never-ending babysitter run.
-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
----
-
+---
+description: Use this command to start babysitting a never-ending babysitter run.
+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 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/commands/help.md

@@ -179,13 +179,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:
@@ -193,11 +193,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]

package/commands/observe.md

@@ -13,5 +13,5 @@ Run the babysitter observer dashboard:
 
 Do not fall back to `babysitter observe`; the core Babysitter CLI does not expose
 that subcommand. Some harness runtimes may provide a separate
-`babysitter-agent observe` surface, but this skill uses the verified standalone
+`agent-platform observe` surface, but this skill uses the verified standalone
 dashboard package.

package/commands/plan.md

@@ -1,7 +1,17 @@
----
-description: Plan a babysitter run. use this command to plan a complex workflow, without actually running it.
-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). focus on creating the best process possible, but without creating and running the actual run.
+---
+description: Plan a babysitter run. use this command to plan a complex workflow, without actually running it.
+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). 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/commands/plugins.md

@@ -1,255 +1,22 @@
----
-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).
-argument-hint: Specific instructions.
----
-
-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.
+---
+description: deprecated alias for the Babysitter blueprints command. Use /babysitter:blueprints for marketplace installables.
+argument-hint: Blueprint action and options.
+---
+
+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.