@a5c-ai/babysitter-codex 0.1.6-staging.c7c4cba5 → 0.1.6-staging.cbfb13a1

package/.codex-plugin/plugin.json

@@ -18,6 +18,12 @@
     "skills"
   ],
   "skills": "./skills/",
+  "skillEntries": [
+    {
+      "name": "babysitter:retrospect",
+      "argumentHint": "[run-id...] [--all] Run IDs or --all for all runs"
+    }
+  ],
   "hooks": "./hooks.json",
   "apps": "./.app.json",
   "interface": {

package/README.md

@@ -22,29 +22,17 @@ Install the SDK CLI first:
 npm install -g @a5c-ai/babysitter-sdk
 ```
 
-Install the Codex plugin globally:
+clone the repo and install the plugin globally:
 
 ```bash
-npx @a5c-ai/babysitter-codex install
-```
-
-This copies the plugin into `~/.codex/plugins/babysitter-codex`, registers it
-in `~/.agents/plugins/marketplace.json`, merges the required global Codex
-config into `~/.codex/config.toml`, installs the active global Codex
-`skills/`, `hooks/`, and `hooks.json` surface under `~/.codex/`, and ensures
-the Babysitter process library is active in `~/.a5c`.
+git clone https://github.com/a5c-ai/babysitter.git
+cd babysitter
+codex
 
-Install the plugin into a specific workspace:
-
-```bash
-npx @a5c-ai/babysitter-codex install --workspace /path/to/repo
+> /plugins
 ```
 
-This copies the plugin into `<workspace>/plugins/babysitter-codex`, registers
-it in `<workspace>/.agents/plugins/marketplace.json`, merges
-`<workspace>/.codex/config.toml`, installs the active workspace Codex
-`skills/`, `hooks/`, and `hooks.json` surface under `<workspace>/.codex/`, and
-records install metadata under `<workspace>/.a5c/team/`.
+then navigate to the 'babysitter' entry and select 'Install'.
 
 ## Integration Model
 

package/hooks/babysitter-session-start.sh

@@ -11,16 +11,23 @@ export CODEX_PLUGIN_ROOT="${CODEX_PLUGIN_ROOT:-${PLUGIN_ROOT}}"
 export BABYSITTER_STATE_DIR="${STATE_DIR}"
 
 mkdir -p "$LOG_DIR" 2>/dev/null
-{
-  echo "[INFO] $(date -u +%Y-%m-%dT%H:%M:%SZ) Hook script invoked"
-  echo "[INFO] $(date -u +%Y-%m-%dT%H:%M:%SZ) PLUGIN_ROOT=$PLUGIN_ROOT"
-  echo "[INFO] $(date -u +%Y-%m-%dT%H:%M:%SZ) STATE_DIR=$STATE_DIR"
-} >> "$LOG_FILE" 2>/dev/null
+
+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-start" --message "$msg" --source shell-hook 2>/dev/null || true
+}
+
+blog "Hook script invoked"
+blog "PLUGIN_ROOT=$PLUGIN_ROOT"
+blog "STATE_DIR=$STATE_DIR"
 
 INPUT_FILE=$(mktemp 2>/dev/null || echo "/tmp/codex-session-start-hook-$$.json")
 cat > "$INPUT_FILE"
 
-echo "[INFO] $(date -u +%Y-%m-%dT%H:%M:%SZ) Hook input received ($(wc -c < "$INPUT_FILE") bytes)" >> "$LOG_FILE" 2>/dev/null
+blog "Hook input received ($(wc -c < "$INPUT_FILE") bytes)"
 
 RESULT=$(babysitter hook:run \
   --hook-type session-start \
@@ -30,7 +37,7 @@ RESULT=$(babysitter hook:run \
   < "$INPUT_FILE" 2>"$LOG_DIR/babysitter-session-start-hook-stderr.log")
 EXIT_CODE=$?
 
-echo "[INFO] $(date -u +%Y-%m-%dT%H:%M:%SZ) CLI exit code=$EXIT_CODE" >> "$LOG_FILE" 2>/dev/null
+blog "CLI exit code=$EXIT_CODE"
 
 rm -f "$INPUT_FILE" 2>/dev/null
 printf '%s\n' "$RESULT"

package/hooks/babysitter-stop-hook.sh

@@ -11,16 +11,23 @@ export CODEX_PLUGIN_ROOT="${CODEX_PLUGIN_ROOT:-${PLUGIN_ROOT}}"
 export BABYSITTER_STATE_DIR="${STATE_DIR}"
 
 mkdir -p "$LOG_DIR" 2>/dev/null
-{
-  echo "[INFO] $(date -u +%Y-%m-%dT%H:%M:%SZ) Hook script invoked"
-  echo "[INFO] $(date -u +%Y-%m-%dT%H:%M:%SZ) PLUGIN_ROOT=$PLUGIN_ROOT"
-  echo "[INFO] $(date -u +%Y-%m-%dT%H:%M:%SZ) STATE_DIR=$STATE_DIR"
-} >> "$LOG_FILE" 2>/dev/null
+
+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:stop" --message "$msg" --source shell-hook 2>/dev/null || true
+}
+
+blog "Hook script invoked"
+blog "PLUGIN_ROOT=$PLUGIN_ROOT"
+blog "STATE_DIR=$STATE_DIR"
 
 INPUT_FILE=$(mktemp 2>/dev/null || echo "/tmp/codex-stop-hook-$$.json")
 cat > "$INPUT_FILE"
 
-echo "[INFO] $(date -u +%Y-%m-%dT%H:%M:%SZ) Hook input received ($(wc -c < "$INPUT_FILE") bytes)" >> "$LOG_FILE" 2>/dev/null
+blog "Hook input received ($(wc -c < "$INPUT_FILE") bytes)"
 
 RESULT=$(babysitter hook:run \
   --hook-type stop \
@@ -30,7 +37,7 @@ RESULT=$(babysitter hook:run \
   < "$INPUT_FILE" 2>"$LOG_DIR/babysitter-stop-hook-stderr.log")
 EXIT_CODE=$?
 
-echo "[INFO] $(date -u +%Y-%m-%dT%H:%M:%SZ) CLI exit code=$EXIT_CODE" >> "$LOG_FILE" 2>/dev/null
+blog "CLI exit code=$EXIT_CODE"
 
 rm -f "$INPUT_FILE" 2>/dev/null
 printf '%s\n' "$RESULT"

package/hooks/user-prompt-submit.sh

@@ -5,22 +5,16 @@ SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 PLUGIN_ROOT="$(cd "${SCRIPT_DIR}/.." && pwd)"
 STATE_DIR="${BABYSITTER_STATE_DIR:-${PWD}/.a5c}"
 LOG_DIR="${BABYSITTER_LOG_DIR:-$PLUGIN_ROOT/.a5c/logs}"
-LOG_FILE="$LOG_DIR/babysitter-user-prompt-submit-hook.log"
 
 export CODEX_PLUGIN_ROOT="${CODEX_PLUGIN_ROOT:-${PLUGIN_ROOT}}"
 export BABYSITTER_STATE_DIR="${STATE_DIR}"
 
 mkdir -p "$LOG_DIR" 2>/dev/null
-{
-  echo "[INFO] $(date -u +%Y-%m-%dT%H:%M:%SZ) Hook script invoked"
-  echo "[INFO] $(date -u +%Y-%m-%dT%H:%M:%SZ) PLUGIN_ROOT=$PLUGIN_ROOT"
-  echo "[INFO] $(date -u +%Y-%m-%dT%H:%M:%SZ) STATE_DIR=$STATE_DIR"
-} >> "$LOG_FILE" 2>/dev/null
 
 INPUT_FILE=$(mktemp 2>/dev/null || echo "/tmp/codex-user-prompt-submit-hook-$$.json")
 cat > "$INPUT_FILE"
 
-echo "[INFO] $(date -u +%Y-%m-%dT%H:%M:%SZ) Hook input received ($(wc -c < "$INPUT_FILE") bytes)" >> "$LOG_FILE" 2>/dev/null
+babysitter log --type hook --label "hook:user-prompt-submit" --message "Hook invoked" --source shell-hook 2>/dev/null || true
 
 RESULT=$(babysitter hook:run \
   --hook-type user-prompt-submit \
@@ -30,7 +24,7 @@ RESULT=$(babysitter hook:run \
   < "$INPUT_FILE" 2>"$LOG_DIR/babysitter-user-prompt-submit-hook-stderr.log")
 EXIT_CODE=$?
 
-echo "[INFO] $(date -u +%Y-%m-%dT%H:%M:%SZ) CLI exit code=$EXIT_CODE" >> "$LOG_FILE" 2>/dev/null
+babysitter log --type hook --label "hook:user-prompt-submit" --message "CLI exit code=$EXIT_CODE" --source shell-hook 2>/dev/null || true
 
 rm -f "$INPUT_FILE" 2>/dev/null
 if [ -n "$RESULT" ]; then

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@a5c-ai/babysitter-codex",
-  "version": "0.1.6-staging.c7c4cba5",
+  "version": "0.1.6-staging.cbfb13a1",
   "description": "Babysitter Codex skill bundle and integration package for OpenAI Codex CLI with SDK-managed process-library bootstrapping, 15 orchestration modes, and BOM-safe SKILL installation",
   "scripts": {
     "test": "node test/integration.test.js && node test/packaged-install.test.js",
@@ -43,6 +43,6 @@
   },
   "homepage": "https://github.com/a5c-ai/babysitter/tree/main/plugins/babysitter-codex#readme",
   "dependencies": {
-    "@a5c-ai/babysitter-sdk": "0.0.183-staging.c7c4cba5"
+    "@a5c-ai/babysitter-sdk": "0.0.183-staging.cbfb13a1"
   }
 }

package/skills/babysit/SKILL.md

@@ -1,407 +1,47 @@
 ---
 name: babysit
 description: >-
-  Run babysitter workflows from Codex using the installed babysit skill bundle,
-  Codex mode-wrapper skills, Codex hooks/config, and the Babysitter SDK runtime
-  loop. Use when the user wants to babysit a task, start or resume a run,
-  diagnose run health, install Codex integration, or assimilate a methodology.
+  Orchestrate via @babysitter. Use this skill when asked to babysit a run,
+  orchestrate a process or whenever it is called explicitly. (babysit,
+  babysitter, orchestrate, orchestrate a run, workflow, etc.)
 ---
 
 # babysit
 
-Babysitter on Codex is implemented as:
-
-- the installed plugin under `~/.codex/plugins/babysitter-codex` or `<workspace>/plugins/babysitter-codex`
-- the plugin skill tree under `skills/babysit` and `skills/<mode>`
-- the plugin hook registry at `hooks.json`
-- the plugin hook scripts under `hooks/`
-- global `~/.codex/config.toml`
-- optional workspace `.codex/config.toml`
-- workspace `.a5c/`
-- shared global `.a5c/` process-library state
-- the Babysitter SDK CLI for `run:create`, `run:iterate`, `run:status`,
-  `task:list`, `task:post`, and process-library binding
-
-Native Windows caveat: Codex does not execute hooks on Windows yet. When the
-current Codex session is running on native Windows, do not yield the turn and
-wait for the `Stop` hook. Keep driving the Babysitter loop in the current turn
-until the run completes or you hit a real user breakpoint that requires chat
-input. Only rely on the `SessionStart`/`Stop` hook handoff on platforms where
-Codex hook execution is actually available.
-
-## Choosing a Mode
-
-Use this skill whenever it is invoked directly, and whenever one of the
-installed mode-wrapper skills such as `$call`, `$plan`, `$resume`, or `$yolo`
-loads it.
-
-Choose the mode from either:
-
-1. the direct user intent when the skill is invoked as `$babysit`
-2. the installed wrapper skill name when the user invoked `$call`, `$plan`,
-   `$resume`, `$yolo`, and the rest
-
-| User intent | Mode |
-|-------------|------|
-| Start an orchestration run | `call` |
-| Work an issue-centric flow | `issue` |
-| Run autonomously | `yolo` |
-| Run continuously / recurring workflow | `forever` |
-| Resume an existing run | `resume` |
-| Plan without executing | `plan` |
-| Observe or inspect a run | `observe` |
-| Summarize a completed run | `retrospect` |
-| Diagnose run health | `doctor` |
-| Change or inspect model routing | `model` |
-| Help and documentation | `help` |
-| Install into a project | `project-install` |
-| Install user profile/setup | `user-install` |
-| Install team-pinned setup | `team-install` |
-| Assimilate external methodology | `assimilate` |
-
-Deprecated prompt aliases are not the Codex command surface anymore. Do not
-depend on `.codex/prompts` for normal operation.
+Orchestrate `.a5c/runs/<runId>/` through iterative execution.
 
 ## Dependencies
 
 ### Babysitter SDK and CLI
 
-Use the installed CLI alias:
+Read the SDK version from `versions.json` to ensure version compatibility:
 
 ```bash
-CLI="babysitter"
+SDK_VERSION=$(node -e "try{console.log(JSON.parse(require('fs').readFileSync('${CODEX_PLUGIN_ROOT}/versions.json','utf8')).sdkVersion||'latest')}catch{console.log('latest')}")
+sudo npm i -g @a5c-ai/babysitter-sdk@$SDK_VERSION
+# sudo is depending on the env and system
 ```
 
-If it is not available on the path, use:
+then use the CLI alias: CLI="babysitter"
 
-```bash
-CLI="npx -y @a5c-ai/babysitter-sdk"
-```
+**Alternatively, use the CLI alias:** `CLI="npx -y @a5c-ai/babysitter-sdk@$SDK_VERSION"`
 
 ### jq
 
-Make sure `jq` is available in the path. Install it if missing.
-
-## Core Iteration Workflow
-
-The Babysitter workflow has 8 steps:
-
-1. **Create or find the process** - interview the user or parse the prompt,
-   research the repo and process library, and build a process definition
-2. **Create run and bind session** - create the run via the Babysitter CLI and
-   bind it to the current Codex session honestly
-3. **Run iteration** - execute one orchestration step
-4. **Get effects** - inspect pending effects
-5. **Perform effects** - execute the requested tasks through skills, agents, or
-   shell work
-6. **Post results** - commit results back through `task:post`
-7. **Stop and yield** - on platforms with working Codex hooks, the Codex stop
-   hook decides whether to continue; BUT if running on Windows, stay in-turn and
-   continue the loop yourself instead of waiting for a hook that will not run
-8. **Completion proof** - finish only when the emitted proof is returned
-
-### 1. Create or find the process for the run
-
-#### Interview phase
-
-##### Interactive mode (default)
-
-Interview the user for intent, requirements, goals, scope, and constraints
-before entering the hook-driven loop.
-
-This phase should be iterative and adaptive:
-
-- inspect the current repo state first
-- resolve the active process-library root with
-  `babysitter process-library:active --json`
-- conduct an actual search against that active process library before writing a
-  process
-- research the repo, online references, methodologies, specializations, skills,
-  agents, and related processes as needed
-- ask the user follow-up questions when the intent or constraints are still not
-  clear
-
-Do not plan more than one step ahead during the interview phase. After each
-step, decide the next best step from the current evidence.
-
-The `process-library:active` command bootstraps the shared global SDK process
-library automatically if no binding exists yet. Read:
-
-- `binding.dir` as the active process-library root that must be searched
-- `defaultSpec.cloneDir` as the cloned repo root when adjacent repo-level
-  material is needed
-
-After that, treat `specializations/**/**/**`, `methodologies/`, `contrib/`, and
-`reference/` as paths relative to `binding.dir`.
-
-##### Non-interactive mode
-
-When running non-interactively:
-
-1. parse the initial prompt to extract intent, scope, and constraints
-2. inspect the repo structure
-3. resolve the active process-library root with
-   `babysitter process-library:active --json`
-4. search that active library for the most relevant specialization,
-   methodology, process, skill, or agent
-5. proceed directly to process creation
-
-Do not skip the active-library search step.
-
-#### User Profile Integration
-
-Before building the process, check for an existing user profile:
-
-1. run `babysitter profile:read --user --json`
-2. use the profile to pre-fill user preferences, expertise, and communication
-   style
-3. calibrate breakpoint density from `breakpointTolerance`
-4. prefer tools, skills, and agents the user already uses
-5. adapt explanations and breakpoint text to the user's communication style
-6. if no profile exists, proceed normally and consider suggesting `$user-install`
-
-All profile read/write/merge/render operations must go through the Babysitter
-CLI, never direct SDK imports.
-
-#### Process creation phase
-
-After the interview phase, create the full custom process files for the run
-according to the process-library patterns and the process-creation guidelines
-below.
-
-Install `@a5c-ai/babysitter-sdk` into `.a5c/` if it is missing. When doing so,
-run the install from the project root and use either `npm i --prefix .a5c ...`
-or a subshell so the working directory does not stay inside `.a5c/`.
-
-Always use an **absolute path** for `--entry` when calling `run:create`.
-
-After the process is created and before creating the run:
-
-- in interactive mode, describe the process at a high level, generate
-  `[process-name].diagram.md` and `[process-name].process.md`, and get user
-  confirmation before proceeding
-- in non-interactive mode, proceed directly to `run:create`
-
-Common mistakes to avoid:
-
-- wrong: skipping repo/process-library research before writing the process
-- wrong: bypassing the orchestration model with helper scripts or inline logic
-- wrong: using `kind: 'node'` in generated tasks
-- correct: use `agent` or `skill` tasks for reasoning work, with `shell` only
-  for existing CLIs, tests, linters, git, or builds
-- correct: include verification loops, refinement loops, quality gates, and
-  breakpoints where appropriate
-
-### 2. Create run and bind session
-
-For new runs:
-
-```bash
-$CLI run:create \
-  --process-id <id> \
-  --entry <absolute-path>#<export> \
-  --inputs <file> \
-  --prompt "$PROMPT" \
-  --harness codex \
-  --state-dir .a5c \
-  --plugin-root "${CODEX_PLUGIN_ROOT}" \
-  --json
-```
-
-Required flags:
-
-- `--process-id <id>` - unique identifier for the process definition
-- `--entry <absolute-path>#<export>` - process JS file plus named export
-- `--prompt "$PROMPT"` - the user's initial request
-- `--harness codex` - activates Codex session binding
-- `--state-dir .a5c` - required for honest workspace-local Codex session state
-- `--plugin-root "${CODEX_PLUGIN_ROOT}"` - plugin root used for session/state
-  resolution
-
-Optional flags:
-
-- `--inputs <file>` - process input JSON
-- `--run-id <id>` - override the generated run id
-- `--runs-dir <dir>` - override the default runs directory
+make sure you have jq installed and available in the path. if not, install it.
 
-Inside a real Codex hook/session environment, do **not** pass `--session-id`
-explicitly. The Codex adapter auto-resolves the session/thread id from
-`CODEX_THREAD_ID`, `CODEX_SESSION_ID`, or `CODEX_ENV_FILE`. Only pass
-`--session-id` in out-of-band recovery flows where no ambient Codex session
-identity exists.
+## Instructions
 
-In normal Codex usage, `run:create` must bind the session into the active
-workspace `.a5c`, not the global `~/.a5c`, so the Stop hook can find the same
-session state file in later turns.
-
-On Windows, still bind the session honestly with `run:create`, but do
-not assume that later turns will be resumed by Codex hooks. After `run:create`
-you must keep executing the orchestration loop yourself in the current turn
-until completion or a real user-facing breakpoint. (calling `run:iterate` in the same turn is fine on Windows because the hooks won't run there, but do not do that in the normal Codex plugin path where the hooks are expected to drive the loop).
-
-For resuming existing runs in a manual recovery flow:
-
-```bash
-$CLI session:resume \
-  --session-id <id> \
-  --state-dir .a5c \
-  --run-id <runId> \
-  --runs-dir .a5c/runs \
-  --json
-```
-
-### 3. Run iteration
+Run the following command to get full orchestration instructions:
 
 ```bash
-$CLI run:iterate .a5c/runs/<runId> --json --iteration <n> --plugin-root "${CODEX_PLUGIN_ROOT}"
+babysitter instructions:babysit-skill --harness codex --interactive
 ```
 
-Status values:
-
-- `"executed"` - tasks executed, continue looping
-- `"waiting"` - breakpoint or sleep is pending
-- `"completed"` - run finished successfully
-- `"failed"` - run failed
-- `"none"` - no runnable effects exist
-
-### 4. Get effects
+For non-interactive runs (e.g., with `-p` flag or no question tool):
 
 ```bash
-$CLI task:list .a5c/runs/<runId> --pending --json
+babysitter instructions:babysit-skill --harness codex --no-interactive
 ```
 
-### 5. Perform effects
-
-Run the effect externally to the SDK, then post the outcome summary with
-`task:post`.
-
-Important:
-
-- delegate using Codex skills or agent tooling when possible
-- make sure the requested change actually happened
-- do not describe or imply success without verifying the requested effect
-- do not use the `babysit` skill itself inside delegated task execution
-
-#### 5.1 Breakpoint handling
-
-##### Interactive mode
-
-Ask the user explicitly for approval. If the Codex environment provides a
-structured question UI, include explicit approve/reject options. If not, ask in
-chat and require an explicit approval response.
-
-Never infer approval from silence, ambiguity, or dismissal.
-
-Breakpoint rejections must still be posted with `--status ok` and a value such
-as `{"approved": false, "response": "..."}`.
-
-##### Non-interactive mode
-
-Choose the best option from context and post the result. Rejections still use
-`--status ok` with `{"approved": false}`.
-
-### 6. Results posting
-
-Never write `result.json` directly.
-
-Workflow:
-
-1. write the result value to `tasks/<effectId>/output.json`
-2. call `task:post` with `--value tasks/<effectId>/output.json`
-3. let the SDK write `result.json`, append the journal event, and update state
-
-### 7. Stop after every phase after run-session association
-
-After `run:create` or any posted effect result, end the current assistant turn
-and yield back to the Codex hook loop. Do not run multiple `run:iterate` steps
-in the same turn.
-
-Native Windows exception: because Codex does not execute hooks on Windows yet,
-do not end the turn and wait for the hook loop there. Continue with the next
-`run:iterate`, inspect tasks, perform effects, and post results in the same
-turn until the run completes or you need explicit user input for a breakpoint.
-Do not tell the user you are waiting for the stop hook on Windows.
-
-### 8. Completion proof
-
-When `run:iterate` or `run:status` returns `completionProof`, return that exact
-value wrapped in `<promise>...</promise>`.
-
-## Hook Loop
-
-Global install must register the plugin in `~/.agents/plugins/marketplace.json`
-with the plugin bundle at `~/.codex/plugins/babysitter-codex`, and must merge
-`~/.codex/config.toml`.
-
-Workspace onboarding may also register the plugin in
-`<workspace>/.agents/plugins/marketplace.json` with the plugin bundle at
-`<workspace>/plugins/babysitter-codex`, and may merge `.codex/config.toml` for
-repo-local pinning.
-
-Both levels must provide:
-
-1. `SessionStart` seeds `.a5c` session state
-2. `UserPromptSubmit` performs prompt-time transformations when needed
-3. `Stop` decides whether the run is complete or Codex should receive the next
-   Babysitter iteration context
-
-On native Windows, treat these hook registrations as installation/configuration
-state only. Codex currently does not execute them there, so the skill must keep
-the orchestration loop moving in-turn instead of waiting for hook callbacks.
-
-## Task Kinds
-
-Never generate `kind: 'node'` effects.
-
-| Kind | When to use |
-|------|-------------|
-| `agent` | default for planning, implementation, analysis, debugging, scoring, research |
-| `skill` | when a matching installed skill exists |
-| `shell` | existing CLI tools, tests, git, linters, builds |
-| `breakpoint` | human approval gates |
-| `sleep` | time gates |
-
-## Process Creation Guidelines
-
-- always research the repo and the active process library before writing the
-  process
-- prefer composing multiple relevant library processes rather than copying just
-  one template blindly
-- include verification and refinement loops
-- prefer processes that close the widest practical quality loop
-- add `@skill` and `@agent` discovery markers to generated process files for
-  the dependencies you actually selected
-- prefer incremental work that can be tested as you go
-
-Search for relevant processes, skills, agents, methodologies, and references
-in:
-
-1. `.a5c/processes/`
-2. the active process-library root from `binding.dir`
-3. the cloned repo root from `defaultSpec.cloneDir` when adjacent material is
-   needed
-
-## Codex-Specific Rules
-
-- `$babysit` is the core skill
-- `$call`, `$plan`, `$resume`, `$yolo`, and the other mode skills are thin
-  wrappers that must only load `babysit` for the matching mode
-- do not fabricate a session id
-- on Windows env, never claim that you are yielding to or waiting for the
-  Codex stop hook; continue the Babysitter loop in the current turn instead
-
-## Critical Rules
-
-CRITICAL RULE: The completion proof is emitted only when the run is truly
-completed. Output `<promise>SECRET</promise>` only when the orchestration status
-is completed.
-
-CRITICAL RULE: Never bypass the Babysitter orchestration model when this skill
-is active. Do not replace it with ad-hoc direct execution.
-
-CRITICAL RULE: Never build helper scripts or wrapper programs to drive the run.
-Use the CLI and the hook loop directly.
-
-CRITICAL RULE: In interactive mode, never auto-approve breakpoints.
-
-CRITICAL RULE: Do not use `kind: 'node'` in generated process files.
+Follow the instructions returned by the command above to orchestrate the run.

package/skills/call/SKILL.md

@@ -12,5 +12,6 @@ Resolve the request in `call` mode:
 - treat everything after `$call` as the initial Babysitter request for a new
   orchestration run
 - create the process, create the run, and enter the Babysitter loop
+- using this always means the user meant an interactive run.
 - do not create a separate command surface here; this skill only forwards into
   `babysit`

package/skills/retrospect/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: retrospect
-description: Summarize or retrospect on a completed Babysitter run.
+description: Summarize or retrospect on one or more completed Babysitter runs.
+argument-hint: "[run-id...] [--all] Optional run IDs or --all for all runs"
 ---
 
 # retrospect
@@ -9,7 +10,46 @@ Load and use the installed `babysit` skill.
 
 Resolve the request in `retrospect` mode:
 
-- treat everything after `$retrospect` as the run selector to summarize
+- treat everything after `$retrospect` as the run selector(s) to summarize
 - focus on the run history, outcomes, lessons, and gaps
 - do not create a separate command surface here; this skill only forwards into
   `babysit`
+
+## Phase 1: Resolve Target Run(s)
+
+- If `--all` or "all" is present in args: list all runs via `ls -lt .a5c/runs/` and collect all completed/failed run IDs
+- If multiple run IDs are provided: use all of them
+- Otherwise: existing behavior (resolve the latest single run)
+- Use `ask_user` to confirm run selection in interactive mode
+
+## Phase 2: Load Run Data
+
+For each selected run, load:
+- `run.json` metadata
+- Journal events
+- Task definitions and results
+- State snapshots
+
+## Phase 3: Analysis
+
+Perform standard per-run analysis (outcomes, process effectiveness, suggestions).
+
+### Cross-Run Pattern Analysis (multi-run mode)
+
+When analyzing multiple runs, additionally cover:
+- **Common failure modes** across runs
+- **Velocity trends** (tasks/time across runs)
+- **Process evolution** (how processes changed over time)
+- **Repeated breakpoint patterns**
+
+## Phase 4: Suggestions
+
+Provide actionable suggestions for process improvements, optimizations, and fixes.
+
+## Phase 5: Implementation
+
+If the user agrees, implement improvements to processes, skills, or configuration.
+
+## Phase 6: Cleanup Suggestion
+
+After analysis, suggest: "Consider running `babysitter cleanup` (or `/babysitter:cleanup`) to clean up old run data and reclaim disk space."

package/skills/yolo/SKILL.md

@@ -12,5 +12,8 @@ Resolve the request in `yolo` mode:
 - treat everything after `$yolo` as the autonomous execution request
 - follow the `babysit` skill contract while optimizing for minimal manual
   interruption
+- using this means the user wants to run autonomously with minimal manual
+  interruption, so optimize for that by skipping or minimizing any steps that
+  would require user input or decision-making during the run
 - do not create a separate command surface here; this skill only forwards into
   `babysit`