docs/plugins
Agent Plugins guide
Agent plugins are the harness integration packages that install Babysitter into tools such as Claude Code, Codex, Cursor, Gemini CLI, OpenCode, and GitHub Actions. They remain plugins.
Pages in this section
Start with the section hub, then move sideways into adjacent pages when you need more detail.
Complete reference for all babysitter blueprints: commands. Every command supports the --json flag for machine-readable output and --verbose for additional diagnostic information.
wiki/docs/plugins/cli-reference.md
A marketplace is a Git repository that indexes Babysitter blueprints via a marketplace.json manifest. The babysitter SDK clones these repositories locally and reads the manifest to discover available blueprints.
wiki/docs/plugins/marketplace-format.md
The babysitter SDK includes a migration resolution system that finds the shortest path between two blueprint versions using migration files in the blueprint package directory. This guide covers the naming convention, resolution algorithm, and how to write migration instructions.
wiki/docs/plugins/migration-guide.md
This guide explains how to create blueprint packages for the babysitter SDK. A Babysitter blueprint is not a conventional software plugin. Instead, it is a version-managed package of contextual instructions that an AI agent reads and executes to install, uninstall, configure, or migrate between versions of a tool or integration.
wiki/docs/plugins/plugin-author-guide.md
Agent Plugins
Agent plugins are the harness integration packages that install Babysitter into tools such as Claude Code, Codex, Cursor, Gemini CLI, OpenCode, and GitHub Actions. They remain plugins.
Babysitter marketplace installables were renamed to blueprints. Use this page for harness plugin packages and agent-runtime integration details. Use the blueprints page for marketplace packages, install.md instructions, registry operations, and blueprint:* CLI commands.
<!-- supported-harness-plugins:start -->
Supported harness plugin packages
plugins/babysitter-unified/ is the only maintained source tree in this repo. Harness-specific bundles are generated from it and published as npm packages or external plugin repos; they are not maintained as checked-in directories here.
Use this table when you need the canonical entrypoint for a specific Babysitter harness/plugin package rather than the broader blueprint marketplace explanation.
| Surface | Canonical docs home | Status note |
|---|---|---|
plugins/babysitter-unified | plugins/babysitter-unified/per-harness/claude-code/README.md | Canonical authoring source plus Claude Code surface. |
@a5c-ai/babysitter-codex | plugins/babysitter-unified/per-harness/codex/README.md | Generated from the unified source; README is the canonical package-level contract. |
@a5c-ai/babysitter-cursor | plugins/babysitter-unified/per-harness/cursor/README.md | Generated from the unified source; README is the canonical package-level contract. |
babysitter-gemini | plugins/babysitter-unified/per-harness/gemini/README.md | Generated from the unified source; README is the canonical package-level contract. |
babysitter-github | plugins/babysitter-unified/per-harness/github/README.md | Generated from the unified source; README is the canonical package-level contract. |
@a5c-ai/babysitter-omp | plugins/babysitter-unified/per-harness/omp/README.md | Generated from the unified source; README is the canonical package-level contract. |
@a5c-ai/babysitter-openclaw | plugins/babysitter-unified/per-harness/openclaw/README.md | Generated from the unified source; README is the canonical package-level contract. |
@a5c-ai/babysitter-opencode | plugins/babysitter-unified/per-harness/opencode/README.md | Generated from the unified source; README is the canonical package-level contract. |
@a5c-ai/babysitter-pi | plugins/babysitter-unified/per-harness/pi/README.md | Generated from the unified source; README is the canonical package-level contract. |
<!-- supported-harness-plugins:end -->
Bridge Flags for adapters Launch
When launching agents through adapters launch, two bridge flags control how Babysitter hooks and interactive orchestration integrate with the harness:
--bridge-interactiveenables an interactive bridge layer that proxies stdin/stdout through an intermediary capable of injecting Babysitter hook responses and orchestration signals while preserving the harness's native TUI.--bridge-hooksenables hook bridging. The bridge intercepts hook lifecycle events and forwards them to the Babysitter session-start hook.
The hookSupport and bridgeCapabilities attributes in the atlas graph agent version nodes describe which harnesses support these flags natively. See the adapters CLI reference for the full flag table.
Plugin Mode And External Responders
When Babysitter runs inside a host agent plugin, most effects are host-resolvable: the host agent can edit files, run approved tools, answer breakpoints, and post task results back to the run.
External agent responder effects are different. A process can mark an agent task with responderType: "agent" and an adapters adapter; tasks-adapter then resolves that effect through adapters instead of handing it back to the host as ordinary tool work.
This keeps the plugin contract small:
- Host-resolvable effects stay with the current host agent.
- External agent responder effects route through tasks-adapter, adapters, and the
adapterBridgeintegration. - Fallback to the internal agent path must be explicit, using the current fallback field documented in the agent-reference docs.
For task shape, fallback behavior, and troubleshooting, see Process Authoring Policy and Command Surfaces.
Names That Stay As Plugins
The blueprints rename does not change agent harness plugin concepts. These names remain plugin-specific:
CLAUDE_PLUGIN_ROOTPI_PLUGIN_ROOT.claude/plugins/packages/adapters/hooks/packages/extensions-adapter/- Agent plugin
plugin.jsonmanifests - Agent plugin
install.mdfiles
Built-in Quality Gates
The babysitter-unified plugin ships a small set of pre-deploy gates as flat command markdown files under plugins/babysitter-unified/commands/. Each command pairs a user-facing slash invocation with reusable process helpers, so the gate can be invoked manually or composed programmatically.
`babysitter:check-forbidden-markers`
Pre-deploy substring grep for obsolete code paths that must never re-ship after a refactor or restart-from-baseline. Reads a project-local scripts/forbidden-markers.txt and scans built assets for forbidden markers.
- Helper:
library/processes/shared/forbidden-markers-scanner.js - Slash command:
plugins/babysitter-unified/commands/check-forbidden-markers.md