@a5c-ai/babysitter-codex 0.1.6-staging.2dca8387 → 0.1.6-staging.4ebefe91

package/.codex/skills/babysitter/call/SKILL.md

@@ -16,18 +16,16 @@ Start a babysitter run with the Codex hook model. The workspace must have
 
 ### Babysitter SDK and CLI
 
-Read the SDK version from the plugin manifest to ensure version compatibility:
+Use the installed Babysitter SDK CLI:
 
 ```bash
-PLUGIN_ROOT="${CODEX_PLUGIN_ROOT:-$(pwd)/.codex}"
-SDK_VERSION=$(node -e "try{console.log(JSON.parse(require('fs').readFileSync('${PLUGIN_ROOT}/plugin.json','utf8')).sdkVersion||'latest')}catch{console.log('latest')}")
-sudo npm i -g @a5c-ai/babysitter-sdk@$SDK_VERSION
+sudo npm i -g @a5c-ai/babysitter-sdk
 # sudo is depending on the env and system
 ```
 
-then use the CLI alias: CLI="babysitter"
+then use the CLI alias: `CLI="babysitter"`
 
-**Alternatively, use the CLI alias:** `CLI="npx -y @a5c-ai/babysitter-sdk@$SDK_VERSION"`
+**Alternatively, use:** `CLI="npx -y @a5c-ai/babysitter-sdk@latest"`
 
 ### jq
 
@@ -52,7 +50,7 @@ The babysitter workflow has 4 steps:
 
 Interview the user for the intent, requirements, goal, scope, etc. through conversational interaction (before setting the in-session loop).
 
-A multi-step phase to understand the intent and perspective to approach the process building after researching the repo, short research online if needed, short research in the target repo, additional instructions, intent and library (processes, specializations, skills, subagents, methodologies, references, etc.) / guide for methodology building. (clarifications regarding the intent, requirements, goal, scope, etc.) - the library is at [skill-root]/process/specializations/**/**/** and [skill-root]/process/methodologies/ and under [skill-root]/process/contrib/[contributer-username]/]
+A multi-step phase to understand the intent and perspective to approach the process building after researching the repo, short research online if needed, short research in the target repo, additional instructions, intent and library (processes, specializations, skills, subagents, methodologies, references, etc.) / guide for methodology building. Use project-local `.a5c/processes` plus the active process-library binding returned by `babysitter process-library:active --state-dir .a5c --json`.
 
 The first step should be the look at the state of the repo, then find the most relevant processes, specializations, skills, subagents, methodologies, references, etc. to use as a reference. use the babysitter cli discover command to find the relevant processes, skills, subagents, etc at various stages.
 
@@ -557,9 +555,9 @@ prefer processes that have the following characteristics unless otherwise specif
   - if the user is very explicit about the flow and process, create a process that follows it closely and strictly. (ad hoc requests like: "try this functionality and make sure it works as expected, repeat until it works as expected")
   - search for processes (js files), skills and agents (SKILL.md and AGENT.md files) during the interactive process building phase to compose a comprehensive process that may combine various parts from different sources:
     - .a5c/processes/ (project level processes)
-    - plugins/babysitter/skills/babysit/process/specializations/[rnd-specialization-name-slugified]/ (rnd specializations)
-    - plugins/babysitter/skills/babysit/process/specializations/domains/[domain-name-slugified]/[specialization-name-slugified]/ (non rnd specializations)
-    - plugins/babysitter/skills/babysit/process/methodologies/ (methodologies)
+    - library/specializations/[specialization-name-slugified]/ (specializations)
+    - library/specializations/domains/[domain-name-slugified]/[specialization-name-slugified]/ (domain specializations)
+    - library/methodologies/ (methodologies)
     - When creating the process file, add `@skill` and `@agent` JSDoc markers for the relevant skills and agents found during this search (see "Process File Discovery Markers" above). This ensures only the needed dependencies are surfaced during orchestration instead of scanning all available specializations.
 
 ## Critical Rules
@@ -585,6 +583,6 @@ CRITICAL RULE: NEVER use `kind: 'node'` in generated process files. All tasks MU
 CRITICAL RULE: NEVER bypass, avoid or skip the babysitter orchestration model when the user explicitly requested this skill. Do not execute the tasks yourself, do not loop programmatically, do not create helper scripts to orchestrate the runs. Use the CLI to drive the orchestration loop and do not bypass it. not for simple tasks, and even if things get complicated or don't go smoothly. persist in executing the orchestration itself rather than simplifying the execution by bypassing the process above.
 
 ## See Also
-- `process/tdd-quality-convergence.js` - TDD quality convergence example - read and look for relevant processes and methodologies before creating the code process for a new run (create the run using the CLI, then use these process as a reference)
-- `process/reference/ADVANCED_PATTERNS.md` - Agent/skill patterns, iterative convergence
-- `process/reference/sdk.md` - SDK API reference
+- `library/tdd-quality-convergence.js` - TDD quality convergence example - read and look for relevant processes and methodologies before creating the code process for a new run
+- `library/reference/ADVANCED_PATTERNS.md` - Agent/skill patterns, iterative convergence
+- `library/reference/sdk.md` - SDK API reference

package/.codex/skills/babysitter/help/SKILL.md

@@ -6,8 +6,8 @@ argument-hint: "[command|process|skill|agent|methodology] topic to get help on"
 
 # babysitter:help
 
-Babysitter for Codex uses skills, AGENTS guidance, project config, and
-workspace lifecycle hooks so Codex stays in the orchestration loop.
+Babysitter for Codex uses the installed skill bundle, workspace Codex config,
+workspace hooks, and the SDK runtime so Codex stays in the orchestration loop.
 
 ## No Arguments
 
@@ -24,8 +24,7 @@ Primary examples:
   babysitter doctor current run
 
 Codex-native surfaces:
-  - skills
-  - AGENTS.md guidance
+  - installed skills under ~/.codex/skills/babysitter-codex
   - project .codex/config.toml
   - project .codex/hooks.json (SessionStart, UserPromptSubmit, Stop)
   - optional notify monitoring

package/.codex/skills/babysitter/project-install/SKILL.md

@@ -6,60 +6,57 @@ argument-hint: Specific instructions for project onboarding
 
 # babysitter:project-install
 
-Guide through onboarding a new or existing project for babysitter orchestration.
+Guide through onboarding a new or existing project for Babysitter orchestration.
 
 ## Workflow
 
 ### 1. Research the Codebase
 - Analyze project structure, language, framework, build tools
-- Check for existing `.a5c/` directory
-- Detect CI/CD configuration (GitHub Actions, Jenkins, etc.)
+- Check for existing `.a5c/` and `.codex/`
+- Detect CI/CD configuration
 - Identify key entry points and test suites
 
 ### 2. Interview
-- What are the project's goals?
 - What workflows should be orchestrated?
 - What quality gates matter most?
-- Any specific tools or frameworks to prefer?
+- Any harness, model, or tool preferences to preserve?
 
 ### 3. Install the Real Codex Payload
-- Verify the user has installed `@yaniv-tg/babysitter-codex`
-- Run the packaged team installer from the installed skill payload
+- Verify the user has installed `@a5c-ai/babysitter-sdk`
+- Verify the user has installed `@a5c-ai/babysitter-codex`
+- Run `babysitter harness:install-plugin codex --workspace <repo>`
 - Confirm:
+  - `.codex/hooks.json`
+  - `.codex/config.toml`
   - `.a5c/team/install.json`
-  - `.a5c/team/profile.json`
-- Treat the installed skill root as the source of truth for bundled rules,
-  docs, processes, and hook scripts
+  - `.a5c/active/process-library.json`
 
-### 4. Build Project Profile
-- If `babysitter profile:*` commands are supported, write the project profile
-  through the CLI
-- If the SDK is running in `compat-core`, do not block onboarding on profile
-  writes; instead record the discovered build/test/gate choices in workspace
-  onboarding notes under `.a5c/`
+Treat the installed skill root as the source of truth for Codex-facing assets
+only: hooks, skills, commands, and installer scripts. Treat the active
+process-library binding as the source of truth for process content.
 
-The profile or onboarding notes should cover:
-- Project name, description, language, framework
-- Build and test commands
-- Quality gates configuration
-- Preferred skills and agents
+### 4. Build Project Profile
+- Prefer `babysitter profile:*` CLI commands for project profile work
+- Capture build/test/gate choices in the project profile or `.a5c` notes
+
+The profile should cover:
+- project name, description, language, framework
+- build and test commands
+- quality gates configuration
+- preferred skills and agents
 - CI/CD integration settings
 
 ### 5. Install Project-Level Codex Settings
-- Ensure `@a5c-ai/babysitter-sdk` is available
-- Create `.a5c/` directory structure
-- Set up `.codex/config.toml` using real Codex settings (sandbox, approval, optional notify)
-- Set up `.codex/hooks.json` with `SessionStart`, `UserPromptSubmit`, and `Stop`
-- Create AGENTS.md if not present
-- Do not add fake manifest/plugin sections or external supervisor loops
+- Ensure `.codex/hooks.json` points at the installed hook scripts
+- Ensure `.codex/config.toml` contains the required Codex features and writable roots
+- Ensure `.a5c` contains active process-library binding state
+- Do not add a fake plugin manifest, command catalog, or external supervisor loop
 
 ### 6. Optional: Configure CI/CD
-- Add babysitter orchestration to CI pipeline
-- Set up automated quality gates
-- Configure deployment hooks
-
-### Done!
+- Add Babysitter orchestration to CI pipelines where relevant
+- Add verification or artifact capture around the native/internal harness
 
-Project is ready for babysitting. Try `babysitter call ...` to start your first orchestrated workflow.
+### Done
 
-Star the repo: https://github.com/a5c-ai/babysitter
+Project is ready for babysitting. Try `babysitter call ...` to start the first
+orchestrated workflow.

package/.codex/skills/babysitter/team-install/SKILL.md

@@ -6,26 +6,30 @@ argument-hint: "[--dry-run]"
 
 # babysitter:team-install
 
-Install the team-standard babysitter-codex setup from the installed skill payload into the current workspace.
+Install or refresh the packaged Babysitter Codex workspace setup from the
+installed skill payload into the current workspace.
 
 ## Steps
 
-1. Resolve the installed skill root from this `SKILL.md` location, not from the repo `cwd`.
-2. Run the packaged installer against the current workspace.
-3. Confirm generated files:
-- `.a5c/team/install.json`
-- `.a5c/team/profile.json`
-- `.a5c/active/process-library.json`
-
-The installer must read:
-- `<skillRoot>/babysitter.lock.json`
-
-The installer must bootstrap the active process library through the Babysitter SDK CLI:
-- clone or update the original Babysitter repo under `<workspace>/.a5c/process-library/...`
-- bind the active process root with `babysitter process-library:use ...`
-- resolve the active path later with `babysitter process-library:active --state-dir <workspace>/.a5c --json`
-
-The installer must write workspace state only under:
-- `<workspace>/.a5c/`
-
-Use this before onboarding new repos or contributors so command/process/rules mappings are deterministic and do not depend on the plugin repo being checked out beside the target project.
+1. Resolve the installed skill root from this package, not from a repo checkout.
+2. Read `<skillRoot>/babysitter.lock.json`.
+3. Clone or update the upstream Babysitter repo under
+   `<workspace>/.a5c/process-library/babysitter-repo`.
+4. Bind `<workspace>/.a5c/process-library/babysitter-repo/library` through the
+   Babysitter SDK CLI.
+5. Write or refresh:
+   - `<workspace>/.codex/hooks.json`
+   - `<workspace>/.codex/config.toml`
+   - `<workspace>/.a5c/team/install.json`
+6. Create `<workspace>/.a5c/team/profile.json` if it does not already exist.
+
+The installer must also produce:
+- `<workspace>/.a5c/active/process-library.json`
+
+The installer must not:
+- bundle the process library into the package
+- create a fake Codex plugin manifest
+- depend on an external orchestrator or app-server loop
+
+Use this before onboarding new repos or contributors so the Codex-facing assets
+and the active process-library binding are deterministic.

package/README.md

@@ -1,142 +1,134 @@
 # @a5c-ai/babysitter-codex
 
-Babysitter integration package for OpenAI Codex CLI. It packages Codex-facing
-skills, install helpers, mapping docs, and the hook assets used to keep
-Babysitter in the Codex lifecycle loop.
+Babysitter integration package for OpenAI Codex CLI.
 
-This is a Codex skill bundle plus workspace hook templates. It is not a
-Claude-style manifest plugin, but it does rely on Codex's real lifecycle hook
-engine through `.codex/hooks.json`, and the package postinstall now wires the
-active workspace when the global install is launched from that workspace.
+This package is a Codex skill bundle plus installer assets. It is not a native
+Codex plugin manifest and it does not run an external orchestrator. The Codex
+plugin path is:
 
-## What This Package Owns
+- installed skill bundle under `~/.codex/skills/babysitter-codex`
+- workspace `.codex/hooks.json`
+- workspace `.codex/config.toml`
+- workspace `.a5c/` state
+- Babysitter SDK CLI for run creation, iteration, result posting, and
+  process-library binding
 
-- Codex skill payload under `~/.codex/skills/babysitter-codex`
-- Codex-facing command docs
-- Codex runtime hook helpers under `.codex/`
-- Codex mapping and compatibility policy for SDK-driven orchestration
+## What This Package Installs
 
-## Active Process-Library Model
+Global install copies the Codex-facing bundle into `CODEX_HOME`:
 
-`babysitter-codex` does not ship the process library. Workspace onboarding
-fetches the original Babysitter repo through the SDK CLI and binds the active
-process root in `.a5c/active/process-library.json`.
+- `SKILL.md`
+- `.codex/`
+- `agents/`
+- `commands/`
+- `bin/`
+- `scripts/`
+- `babysitter.lock.json`
 
-Active-use process discovery should prefer:
+It does not bundle the process library.
 
-1. Project-local `.a5c/processes`
-2. The SDK-managed active process-library binding returned by
-   `babysitter process-library:active --state-dir .a5c --json`
+## Integration Model
 
-`project-install` and `team-install` layer config, rules, profiles, and pinned
-content metadata. They should not be documented as creating an exclusive
-project/team process-library scope.
+Babysitter for Codex uses only the hooks model:
 
-## Codex User Experience
+- `SessionStart` seeds Babysitter session state
+- `UserPromptSubmit` handles prompt-time transformations
+- `Stop` yields continuation back into the Babysitter orchestration loop
 
-Codex should be integrated through its real hook engine:
-
-- `SessionStart` initializes Babysitter session state
-- `UserPromptSubmit` handles prompt-time transformations safely
-- `Stop` keeps Babysitter in the orchestration loop after each yielded turn
-
-Current contract:
-
-- start, resume, and inspect work through Codex command phrases such as
-  `babysitter call`, `babysitter resume`, and `babysitter doctor`
-- let the installed Codex hook assets handle runtime state, result posting,
-  and continuation
-- stop after each completed phase so the `Stop` hook can decide whether Codex
-  exits or receives the next Babysitter iteration message
-- finish only when `completionProof` is emitted and echoed as
-  `<promise>...</promise>`
-
-Do not document external supervisors, hidden wrapper loops, or `notify` as the
-continuation mechanism for the plugin path.
+The process library is fetched at workspace-install time through the SDK CLI and
+bound for active use in `.a5c/active/process-library.json`.
 
 ## Installation
 
-Install from npm:
+Install the SDK CLI first:
 
 ```bash
-npm install -g @a5c-ai/babysitter-codex
+npm install -g @a5c-ai/babysitter-sdk
 ```
 
-If you run that command from inside the target repository, postinstall will:
+Install the Codex package:
 
-- install the skill payload into `CODEX_HOME`
-- merge `~/.codex/config.toml` so `codex_hooks` is enabled
-- materialize workspace `.codex/hooks.json` and `.codex/config.toml` for the
-  active workspace
-- clone or update the original Babysitter repo into `.a5c/process-library/...`
-- bind `.a5c/process-library/.../library` for active use through the SDK CLI
+```bash
+npm install -g @a5c-ai/babysitter-codex
+```
 
-If you installed from somewhere else, run:
+Then install the Codex plugin payload into the target workspace:
 
 ```bash
-npm install -g @a5c-ai/babysitter-sdk
 babysitter harness:install-plugin codex --workspace /path/to/repo
 ```
 
-`babysitter harness:install-plugin ...` is provided by the SDK CLI, so make
-sure `@a5c-ai/babysitter-sdk` is installed first.
+If `npm install -g @a5c-ai/babysitter-codex` is run from inside the target
+workspace, `postinstall` will also auto-run the packaged `team-install.js`
+against that workspace.
 
-Or from a local checkout:
+## What `team-install.js` Does
 
-```bash
-cd /path/to/babysitter-codex
-npm install -g .
-```
+`scripts/team-install.js` is the workspace installer used by the package and by
+`babysitter harness:install-plugin codex`.
 
-Verify the installed skill payload:
+It:
 
-```bash
-npm ls -g @a5c-ai/babysitter-codex --depth=0
-ls -1 ~/.codex/skills/babysitter-codex
-test -f ~/.codex/skills/babysitter-codex/scripts/team-install.js
-test -f ~/.codex/skills/babysitter-codex/.codex/hooks.json
-test -f ~/.codex/skills/babysitter-codex/.codex/hooks/babysitter-stop-hook.sh
-```
+1. Resolves the installed package root.
+2. Reads `babysitter.lock.json`.
+3. Clones or updates the upstream Babysitter repo into
+   `<workspace>/.a5c/process-library/babysitter-repo`.
+4. Binds `<workspace>/.a5c/process-library/babysitter-repo/library` with
+   `babysitter process-library:use`.
+5. Writes `<workspace>/.a5c/active/process-library.json`.
+6. Writes or refreshes `<workspace>/.codex/hooks.json`.
+7. Creates or merges `<workspace>/.codex/config.toml` so the workspace has the
+   required Codex settings.
+8. Writes `<workspace>/.a5c/team/install.json`.
+9. Creates `<workspace>/.a5c/team/profile.json` if it does not already exist.
 
-Verify the active process-library binding:
+It does not create an external orchestrator, bundle the process library, or
+turn the workspace into a fake Codex plugin manifest.
 
-```bash
-babysitter process-library:active --state-dir /path/to/repo/.a5c --json
-```
+## Resulting Workspace Files
 
-Manual bootstrap uses the same SDK CLI flow:
+After a successful workspace install, the important files are:
 
-```bash
-babysitter process-library:clone --repo https://github.com/a5c-ai/babysitter.git --dir .a5c/process-library/babysitter-repo
-babysitter process-library:use --dir .a5c/process-library/babysitter-repo/library --state-dir .a5c
-babysitter process-library:active --state-dir .a5c --json
-```
+- `.codex/hooks.json`
+- `.codex/config.toml`
+- `.a5c/team/install.json`
+- `.a5c/team/profile.json`
+- `.a5c/active/process-library.json`
+- `.a5c/process-library/babysitter-repo/library`
 
-## Quick Start
+## Using It In Codex
 
-Use command phrases in Codex chat:
+Use normal Codex chat phrases:
 
 ```text
-babysitter help
 babysitter call implement authentication with tests
-babysitter yolo fix lint and failing tests
-babysitter resume latest incomplete run
-babysitter doctor current run
+babysitter resume
+babysitter doctor
+babysitter team-install
+babysitter project-install
 ```
 
-For Codex users, the expected interface is the Codex command phrases plus the
-workspace hook install created by onboarding. Raw Babysitter CLI primitives are
-internal harness details and live in the Codex skill, not in this user-facing
-README.
+The Codex skill and hooks own the plugin flow. Low-level SDK commands are still
+the runtime mechanism, but they are not the user-facing interface.
 
-## Project And Team Install
+## Verification
 
-Use `babysitter team-install` and `babysitter project-install` from Codex chat
-when you want workspace onboarding. They layer pinned config and setup around
-the active process roots already used at runtime; they are not the source of
-truth for process discovery.
+Verify the installed skill bundle:
+
+```bash
+npm ls -g @a5c-ai/babysitter-codex --depth=0
+ls -1 ~/.codex/skills/babysitter-codex
+test -f ~/.codex/skills/babysitter-codex/scripts/team-install.js
+test -f ~/.codex/skills/babysitter-codex/.codex/hooks/babysitter-stop-hook.sh
+```
+
+Verify the active process-library binding for a workspace:
+
+```bash
+babysitter process-library:active --state-dir /path/to/repo/.a5c --json
+```
 
-## Documentation
+## Docs
 
 - [commands/README.md](./commands/README.md)
 - Internal orchestration details: [.codex/skills/babysitter/call/SKILL.md](./.codex/skills/babysitter/call/SKILL.md)

package/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: babysitter-codex
 description: >-
-  Run babysitter workflows from Codex using real Codex surfaces: skills,
-  AGENTS.md guidance, project config, lifecycle hooks, and the Babysitter SDK
-  runtime loop.
+  Run babysitter workflows from Codex using the installed skill bundle,
+  workspace Codex hooks, workspace Codex config, and the Babysitter SDK runtime
+  loop.
   Use when the user wants to babysit a task, resume a run, diagnose run health,
   install the Codex skill, or assimilate a methodology for Codex.
 ---
@@ -12,20 +12,16 @@ description: >-
 
 Babysitter on Codex is implemented as:
 
-- Codex-facing instructions and skills
-- A workspace `.codex/hooks.json` with `SessionStart`, `UserPromptSubmit`, and
-  `Stop` registrations
-- A `.a5c` state directory in the target workspace
-- The Babysitter SDK run/task loop that owns `run:create`, `run:iterate`,
-  `task:post`, breakpoint handling, and resume behavior
-- Optional `notify` monitoring only as secondary telemetry
-
-Codex does expose real lifecycle hooks for this package on supported
-installations. Do not replace them with an external orchestrator or claim that
-`notify` owns continuation.
-Codex also does not expose a native installable plugin manifest for this
-package. Treat `.codex/command-catalog.json` as Babysitter compatibility
-metadata for the skill bundle, not as a Codex platform feature.
+- the installed skill bundle under `~/.codex/skills/babysitter-codex`
+- workspace `.codex/hooks.json`
+- workspace `.codex/config.toml`
+- workspace `.a5c/`
+- the Babysitter SDK CLI for `run:create`, `run:iterate`, `run:status`,
+  `task:list`, `task:post`, and process-library binding
+
+This package supports only the hooks model for the Codex plugin path. Do not
+introduce an app-server loop, an external orchestrator, or fake plugin-manifest
+machinery for the Codex integration.
 
 ## Choosing a Mode
 
@@ -45,9 +41,9 @@ If the user intent is unclear, default to `call/SKILL.md`.
 | Install team-pinned setup | `team-install` |
 | Assimilate external methodology | `assimilate` |
 
-## Internal Runtime Contract
+## Runtime Contract
 
-Use the babysitter SDK CLI for orchestration:
+Use the Babysitter SDK CLI for orchestration:
 
 ```bash
 babysitter run:create   --process-id <id> --entry <path>#<export> ...
@@ -69,16 +65,34 @@ babysitter run:create ... --harness codex --session-id <id> --state-dir .a5c --j
 2. Post it with `babysitter task:post`
 3. Never write `result.json` directly
 
-## Codex Hook Loop
+## Hook Loop
 
-The workspace onboarding flow should install `.codex/config.toml` and
-`.codex/hooks.json` so:
+Workspace onboarding must install `.codex/hooks.json` and `.codex/config.toml`
+so:
 
 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
 
+## Process Library Model
+
+The Codex package does not bundle the process library.
+
+Workspace onboarding must:
+
+1. clone or update the upstream Babysitter repo into
+   `.a5c/process-library/babysitter-repo`
+2. bind `.a5c/process-library/babysitter-repo/library` with
+   `babysitter process-library:use`
+3. resolve the active binding later with
+   `babysitter process-library:active --state-dir .a5c --json`
+
+Preferred discovery order:
+
+1. project-local `.a5c/processes`
+2. the active SDK-managed process-library binding
+
 ## Codex-Specific Rules
 
 - Prefer natural-language activation such as `babysitter call ...`

package/bin/postinstall.js

@@ -16,7 +16,6 @@ const PACKAGE_ROOT = path.resolve(__dirname, '..');
 const IS_WIN = process.platform === 'win32';
 const INSTALL_ENTRIES = [
   { source: 'SKILL.md', required: true },
-  { source: 'AGENTS.md', required: true },
   { source: 'README.md', required: true },
   { source: 'agents', required: true },
   { source: 'bin', required: true },

package/commands/assimilate.md

@@ -24,4 +24,3 @@ babysitter assimilate https://github.com/org/methodology
 ## Notes
 
 - Use command phrases in Codex chat (`babysitter ...`), not custom slash commands.
-- If SDK capabilities are missing in your installed version, babysitter-codex falls back to compatibility behavior where possible.

package/commands/call.md

@@ -27,4 +27,3 @@ babysitter call implement auth with tests
 - The primary Codex plugin path is hook-first through `.codex/hooks.json` (`SessionStart`, `UserPromptSubmit`, `Stop`).
 - Low-level runtime mechanics live here and in `.codex/skills/babysitter/call/SKILL.md`, not in the top-level README or install guide.
 - The implementation should create or bind honestly, let the `Stop` hook own continuation, write value payloads to `output.json`, and post outcomes through SDK commands rather than direct `result.json` writes.
-- If SDK capabilities are missing in your installed version, babysitter-codex falls back to compatibility behavior where possible.

package/commands/doctor.md

@@ -1,5 +1,5 @@
 ---
-description: Diagnose run/runtime health and compatibility.
+description: Diagnose run/runtime health and installation.
 argument-hint: [run-id|mcp]
 ---
 
@@ -7,7 +7,7 @@ argument-hint: [run-id|mcp]
 
 ## Purpose
 
-Diagnose run/runtime health and compatibility.
+Diagnose run/runtime health and installation.
 
 ## Usage
 
@@ -24,4 +24,4 @@ babysitter doctor mcp
 ## Notes
 
 - Use command phrases in Codex chat (`babysitter ...`), not custom slash commands.
-- If SDK capabilities are missing in your installed version, babysitter-codex falls back to compatibility behavior where possible.
+- Check the workspace hook/config install, active process-library binding, and run state.

package/commands/forever.md

@@ -24,4 +24,3 @@ babysitter forever monitor production error trends daily
 ## Notes
 
 - Use command phrases in Codex chat (`babysitter ...`), not custom slash commands.
-- If SDK capabilities are missing in your installed version, babysitter-codex falls back to compatibility behavior where possible.

package/commands/help.md

@@ -25,4 +25,3 @@ babysitter help command doctor
 
 - Use command phrases in Codex chat (`babysitter ...`), not custom slash commands.
 - Codex chat owns the loop through the hook model in `.codex/hooks.json`; `Stop` is the continuation owner.
-- If SDK capabilities are missing in your installed version, babysitter-codex falls back to compatibility behavior where possible.

package/commands/issue.md

@@ -24,4 +24,3 @@ babysitter issue 123 --repo owner/repo --apply
 ## Notes
 
 - Use command phrases in Codex chat (`babysitter ...`), not custom slash commands.
-- If SDK capabilities are missing in your installed version, babysitter-codex falls back to compatibility behavior where possible.

package/commands/model.md

@@ -24,4 +24,3 @@ babysitter model set plan=gpt-5 execute=gpt-5-codex
 ## Notes
 
 - Use command phrases in Codex chat (`babysitter ...`), not custom slash commands.
-- If SDK capabilities are missing in your installed version, babysitter-codex falls back to compatibility behavior where possible.

package/commands/observe.md

@@ -24,4 +24,3 @@ babysitter observe current workspace
 ## Notes
 
 - Use command phrases in Codex chat (`babysitter ...`), not custom slash commands.
-- If SDK capabilities are missing in your installed version, babysitter-codex falls back to compatibility behavior where possible.

package/commands/plan.md

@@ -24,4 +24,3 @@ babysitter plan migration from monolith to services
 ## Notes
 
 - Use command phrases in Codex chat (`babysitter ...`), not custom slash commands.
-- If SDK capabilities are missing in your installed version, babysitter-codex falls back to compatibility behavior where possible.