/help

description: help and documentation for babysitter command usage, processes, skills, agents, and methodologies. use this command to understand how to use babysitter effectively.
argument-hint: Specific command, process, skill, agent, or methodology you want help with (e.g. "help command doctor" or "help process retrospect").
allowed-tools: Read, Grep, Write, Task, Bash, Edit, Grep, Glob, WebFetch, WebSearch, Search, AskUserQuestion, TodoWrite, TodoRead, Skill, BashOutput, KillShell, MultiEdit, LS

if no arguments provided:

show this message:

Welcome to the Babysitter Help Center! Here you can find documentation and guidance on how to use Babysitter effectively.

Documentation: Explore our comprehensive documentation to understand Babysitter's features, processes, skills, agents, and methodologies. Read the Docs: https://github.com/a5c-ai/babysitter

Or ask specific questions about commands, processes, skills, agents, methodologies, domains, specialities to get targeted help.

Just type /babysitter:help followed by your question or the topic you want to learn more about.


PRIMARY COMMANDS
================

/babysitter:call [input]
  Start a babysitter-orchestrated run. Babysitter analyzes your request, interviews you
  to gather requirements, selects or creates the best process definition (from 50+
  domain-specific processes covering science, business, engineering, and more), then
  executes it step by step with breakpoints where you can steer direction.

  How it works: The babysitter skill reads your input, explores the process library to
  find matching processes, interviews you to refine scope, creates an SDK run with
  run:create, and orchestrates iterations with run:iterate -- dispatching tasks,
  handling breakpoints, and posting results until the run completes or you pause it.

  Example: /babysitter:call migrate our Express.js REST API to Fastify, keeping all
  existing routes and middleware behavior identical, with integration tests proving
  parity


/babysitter:resume [run id or name]
  Resume a paused or interrupted babysitter run. If you don't specify a run, babysitter
  discovers all runs under .a5c/runs/, shows their status (created, waiting, completed,
  failed), and suggests which incomplete run to pick up based on its process, pending
  effects, and last activity.

  How it works: Reads run metadata and journal, rebuilds state cache if stale, identifies
  pending effects (breakpoints awaiting approval, tasks needing results), and continues
  orchestration from exactly where it left off -- no work is repeated thanks to the
  replay engine.

  Example: /babysitter:resume
  (discovers runs and offers: "Run abc123 is waiting on a breakpoint in the 'review
  test results' phase of your API migration -- resume this one?")


/babysitter:yolo [input]
  Start a babysitter run in fully autonomous mode. Identical to /call but all breakpoints
  are auto-approved and no user interaction is requested. The babysitter makes every
  decision on its own until the run completes or hits a critical failure it can't recover
  from. Best for well-understood tasks where you trust the process.

  How it works: Same orchestration as /call, but the process context is configured to
  skip breakpoint effects -- instead of pausing for human approval, each breakpoint
  resolves immediately with an auto-approve result.

  Example: /babysitter:yolo add comprehensive unit tests for all functions in
  src/utils/ using vitest with >90% branch coverage


/babysitter:plan [input]
  Generate a detailed execution plan without running anything. Babysitter goes through
  the full interview and process selection flow, designs the process definition with
  all tasks, breakpoints, and dependencies, but stops before creating the actual SDK run.
  You get a complete plan you can review, modify, or execute later with /call.

  How it works: Runs the babysitter skill's planning phase only -- analyzes input,
  matches to domain processes, interviews for requirements, then outputs the process
  definition file and a human-readable execution plan showing each phase, task, and
  decision point.

  Example: /babysitter:plan redesign our database schema to support multi-tenancy,
  migrate existing data, and update all queries -- I want to review the plan before
  we touch anything


/babysitter:forever [input]
  Start a babysitter run that loops indefinitely with sleep intervals. Designed for
  ongoing operational tasks: monitoring, periodic maintenance, continuous improvement,
  or recurring workflows. The process uses an infinite loop with ctx.sleepUntil() to
  pause between iterations.

  How it works: Creates a process definition with a while(true) loop. Each cycle performs
  the task (e.g., check metrics, process tickets, run audits), then calls ctx.sleepUntil()
  to pause for a configured interval. The run stays in "waiting" state during sleep and
  resumes automatically when the sleep expires on the next orchestration iteration.

  Example: /babysitter:forever every 4 hours, check our GitHub issues labeled "bug",
  attempt to reproduce and fix any that look straightforward, and submit PRs for the fixes


SECONDARY COMMANDS
==================

/babysitter:doctor [issue]
  Run a comprehensive 10-point health check on a babysitter run. Inspects journal
  integrity (checksum verification, sequence gaps, timestamp ordering), state cache
  consistency, stuck/errored effects, stale locks, session state, log files, disk usage,
  process validation, and hook execution health. Produces a structured diagnostic report
  with PASS/WARN/FAIL status per check and specific fix commands.

  If no run ID is provided, automatically targets the most recent run. Can also diagnose
  environment-wide issues like missing CLI, unregistered hooks, or plugin problems.

  Example: /babysitter:doctor
  (checks the latest run: "CRITICAL -- Check 5 Lock Status: FAIL -- stale lock detected,
  process 12847 is no longer running. F