This section has three tracks:

Use this directory as the source of truth for repository-level AI agent guidance.

This section collects long-form writing that helps readers understand the ideas behind Babysitter without making those essays part of the core task-oriented docs flow.

These guides cover the current harness-integration surface for Babysitter.

Generated: 2026-05-07

This guide walks through a realistic flow that exercises the babysitter CLI and the new deterministic test harness exposed from @a5c-ai/babysitter-sdk/testing. The examples assume you are standing in the repo root (or a project that already vendored the CLI + SDK) and that ~/.a5c/runs is the default runs directory. Set BABYSITTERRUNSSCOPE=repo if you want repo-local <repo>/.a5c/runs instead.

This guide explains how to use the official Babysitter GitHub Action(https://github.com/a5c-ai/babysitter) (a5c-ai/babysitter@main) for automated, AI-orchestrated workflows in your CI/CD pipeline.

This guide explains how to integrate the Babysitter plugin with Claude Code GitHub Actions(https://github.com/anthropics/claude-code-action) for automated orchestration workflows in your CI/CD pipeline.

This guide explains how to integrate the Babysitter plugin with OpenAI's Codex GitHub Action(https://github.com/openai/codex-action) for automated orchestration workflows in your CI/CD pipeline.

This guide explains how to integrate the Babysitter plugin with Google's Gemini CLI GitHub Action(https://github.com/google-github-actions/run-gemini-cli) for automated orchestration workflows in your CI/CD pipeline.

(excludes test infrastructure in harness-mock: 55 refs)

This gap analysis identifies feature gaps in the Babysitter orchestration platform from the babysitter-native perspective. All gaps are framed around what the orchestration platform needs -- not what any specific host harness (like Claude Code) provides.

This page is the canonical discovery index for package and plugin documentation in the Babysitter monorepo.

Most plugin systems work like this: there's a host application with predefined extension points (hooks, APIs, lifecycle events), and plugins slot into those points. The plugin can only do what the host lets it do.

This section contains the current reference docs that remain part of the published docs surface.

<!-- Generated by .claude/skills/assimilate-popular-workflows. Re-run to refresh. -->

1. Ensure release-notes.md matches the changelog section before approving the release.

<!-- Generated by .claude/skills/catalog-babysitter-users. Re-run the skill to refresh. -->

Core SDK improvements including CLI bash migration, shell-to-CLI refactor, DX optimization, path resolution utilities, completionSecret rename, prompt persistence, staging versioning, and hook thin-shell refactors. All completed successfully.

This directory defines the replacement testing strategy after the legacy Docker and Docker-E2E workflows were removed. The current CI implementation lives primarily in .github/workflows/publish.yml, with GitHub Actions owning the live-stack scenario and OS matrix. The new plan starts from repository-native package boundaries, Babysitter harness setup commands, the babysitter-agent runtime surface, and explicit model/no-model lanes instead of reusing the retired Docker image and e2e-tests/docker suite.

Welcome to the Babysitter documentation. Babysitter is an AI-powered development workflow orchestrator that enables iterative quality convergence with human-in-the-loop approval through breakpoints.

When babysitter started, it was a single npm package that could wrap an AI agent session in a structured process. You called defineTask, wrote some effects, and the SDK kept your agent on the rails. That was useful, but it only worked with one harness, in one environment, with one person watching.

This directory documents a pragmatic V6 evolution for the Babysitter stack. The intent is not to describe the biggest possible modular future. The intent is to define the smallest architecture change that is worth shipping, can be validated against the current repository, and leaves room for later extraction if the seams prove real.

This document is the repo-level source of truth for which npm workspaces are active, which ones are release-critical, and which workflow path validates them.