@a5c-ai/babysitter-codex 0.1.6-staging.2df34517 → 0.1.6-staging.3faa6c86

package/.app.json

@@ -0,0 +1,3 @@
+{
+  "apps": {}
+}

package/.codex-plugin/plugin.json

@@ -19,6 +19,7 @@
   ],
   "skills": "./skills/",
   "hooks": "./hooks.json",
+  "apps": "./.app.json",
   "interface": {
     "displayName": "Babysitter",
     "shortDescription": "Run Babysitter orchestration flows from Codex",
@@ -39,6 +40,8 @@
       "Resume the latest Babysitter run in this workspace"
     ],
     "brandColor": "#0F766E",
+    "composerIcon": "./assets/icon.svg",
+    "logo": "./assets/logo.svg",
     "screenshots": []
   }
 }

package/README.md

@@ -2,7 +2,7 @@
 
 Babysitter integration package for OpenAI Codex CLI.
 
-This package now ships as a real Codex plugin bundle:
+This package ships a real Codex plugin bundle:
 
 - `.codex-plugin/plugin.json`
 - `skills/`
@@ -10,8 +10,9 @@ This package now ships as a real Codex plugin bundle:
 - `hooks/`
 
 It still uses the Babysitter SDK CLI and the shared `~/.a5c` process-library
-state, but it no longer installs itself by copying fake skill and hook payloads
-into `~/.codex/skills` and `~/.codex/hooks.json`.
+state. The installer registers the plugin bundle and also materializes the
+active Codex `skills/`, `hooks/`, and `hooks.json` surface at the selected
+scope so Codex can execute the Babysitter commands and hook scripts directly.
 
 ## Installation
 
@@ -21,27 +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`, 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`, and records install metadata under
-`<workspace>/.a5c/team/`.
+then navigate to the 'babysitter' entry and select 'Install'.
 
 ## Integration Model
 
@@ -62,6 +53,9 @@ After `install --workspace`, the important files are:
 - `plugins/babysitter-codex/.codex-plugin/plugin.json`
 - `plugins/babysitter-codex/skills/babysit/SKILL.md`
 - `plugins/babysitter-codex/hooks.json`
+- `.codex/skills/`
+- `.codex/hooks/`
+- `.codex/hooks.json`
 - `.agents/plugins/marketplace.json`
 - `.codex/config.toml`
 - `.a5c/team/install.json`
@@ -77,6 +71,9 @@ test -f ~/.codex/plugins/babysitter-codex/.codex-plugin/plugin.json
 test -f ~/.codex/plugins/babysitter-codex/hooks.json
 test -f ~/.codex/plugins/babysitter-codex/hooks/babysitter-stop-hook.sh
 test -f ~/.codex/plugins/babysitter-codex/skills/babysit/SKILL.md
+test -f ~/.codex/hooks.json
+test -f ~/.codex/hooks/babysitter-stop-hook.sh
+test -f ~/.codex/skills/babysit/SKILL.md
 test -f ~/.agents/plugins/marketplace.json
 ```
 

package/assets/icon.svg

@@ -0,0 +1,7 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" role="img" aria-label="Babysitter icon">
+  <rect width="64" height="64" rx="14" fill="#0F766E"/>
+  <path d="M16 22h32v20H16z" fill="#ECFEFF"/>
+  <circle cx="24" cy="32" r="3" fill="#0F766E"/>
+  <circle cx="32" cy="32" r="3" fill="#0F766E"/>
+  <circle cx="40" cy="32" r="3" fill="#0F766E"/>
+</svg>

package/assets/logo.svg

@@ -0,0 +1,8 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 320 80" role="img" aria-label="Babysitter logo">
+  <rect x="0" y="8" width="64" height="64" rx="14" fill="#0F766E"/>
+  <path d="M16 26h32v28H16z" fill="#ECFEFF"/>
+  <circle cx="24" cy="40" r="3" fill="#0F766E"/>
+  <circle cx="32" cy="40" r="3" fill="#0F766E"/>
+  <circle cx="40" cy="40" r="3" fill="#0F766E"/>
+  <text x="80" y="50" font-family="Arial, sans-serif" font-size="34" fill="#0F766E">Babysitter</text>
+</svg>

package/bin/install-shared.js

@@ -58,10 +58,11 @@ const DEFAULT_MARKETPLACE = {
 };
 const PLUGIN_BUNDLE_ENTRIES = [
   '.codex-plugin',
+  '.app.json',
+  'assets',
   'hooks',
   'hooks.json',
   'skills',
-  'README.md',
   'babysitter.lock.json',
 ];
 
@@ -306,6 +307,26 @@ function writeJson(filePath, value) {
   writeFileIfChanged(filePath, `${JSON.stringify(value, null, 2)}\n`);
 }
 
+function ensureExecutable(filePath) {
+  try {
+    fs.chmodSync(filePath, 0o755);
+  } catch {
+    // Best-effort only. Windows and some filesystems may ignore mode changes.
+  }
+}
+
+function normalizeMarketplaceSourcePath(marketplacePath, pluginSourcePath) {
+  let next = pluginSourcePath;
+  if (path.isAbsolute(next)) {
+    next = path.relative(path.dirname(marketplacePath), next);
+  }
+  next = String(next || '').replace(/\\/g, '/');
+  if (!next.startsWith('./') && !next.startsWith('../')) {
+    next = `./${next}`;
+  }
+  return next;
+}
+
 function ensureMarketplaceEntry(marketplacePath, pluginSourcePath) {
   const marketplace = fs.existsSync(marketplacePath)
     ? readJson(marketplacePath)
@@ -318,7 +339,7 @@ function ensureMarketplaceEntry(marketplacePath, pluginSourcePath) {
     name: PLUGIN_NAME,
     source: {
       source: 'local',
-      path: pluginSourcePath,
+      path: normalizeMarketplaceSourcePath(marketplacePath, pluginSourcePath),
     },
     policy: {
       installation: 'AVAILABLE',
@@ -401,6 +422,69 @@ function removeLegacyCodexSurface(codexHome) {
   }
 }
 
+function installManagedSkills(packageRoot, codexHome) {
+  const sourceRoot = path.join(packageRoot, 'skills');
+  const targetRoot = path.join(codexHome, 'skills');
+  fs.mkdirSync(targetRoot, { recursive: true });
+
+  for (const entry of fs.readdirSync(sourceRoot, { withFileTypes: true })) {
+    if (!entry.isDirectory()) continue;
+    copyRecursive(
+      path.join(sourceRoot, entry.name),
+      path.join(targetRoot, entry.name),
+    );
+  }
+}
+
+function mergeManagedHooksConfig(packageRoot, codexHome) {
+  const managedHooks = readJson(path.join(packageRoot, 'hooks.json')).hooks || {};
+  const hooksConfigPath = path.join(codexHome, 'hooks.json');
+  const existing = fs.existsSync(hooksConfigPath)
+    ? readJson(hooksConfigPath)
+    : { hooks: {} };
+  if (!existing.hooks || typeof existing.hooks !== 'object') {
+    existing.hooks = {};
+  }
+
+  for (const [eventName, matchers] of Object.entries(managedHooks)) {
+    const existingMatchers = Array.isArray(existing.hooks[eventName]) ? existing.hooks[eventName] : [];
+    const filteredMatchers = existingMatchers
+      .map((matcher) => {
+        const hooks = Array.isArray(matcher.hooks) ? matcher.hooks : [];
+        const keptHooks = hooks.filter((hook) => {
+          const command = String(hook.command || '');
+          return !LEGACY_HOOK_SCRIPT_NAMES.some((name) => command.includes(name));
+        });
+        return keptHooks.length > 0 ? { ...matcher, hooks: keptHooks } : null;
+      })
+      .filter(Boolean);
+    existing.hooks[eventName] = [...filteredMatchers, ...matchers];
+  }
+
+  writeJson(hooksConfigPath, existing);
+}
+
+function installManagedHooks(packageRoot, codexHome) {
+  const sourceRoot = path.join(packageRoot, 'hooks');
+  const targetRoot = path.join(codexHome, 'hooks');
+  fs.mkdirSync(targetRoot, { recursive: true });
+
+  for (const scriptName of LEGACY_HOOK_SCRIPT_NAMES) {
+    const sourcePath = path.join(sourceRoot, scriptName);
+    const targetPath = path.join(targetRoot, scriptName);
+    copyRecursive(sourcePath, targetPath);
+    ensureExecutable(targetPath);
+  }
+
+  mergeManagedHooksConfig(packageRoot, codexHome);
+}
+
+function installCodexSurface(packageRoot, codexHome) {
+  removeLegacyCodexSurface(codexHome);
+  installManagedSkills(packageRoot, codexHome);
+  installManagedHooks(packageRoot, codexHome);
+}
+
 function warnWindowsHooks() {
   if (process.platform !== 'win32') {
     return;
@@ -416,6 +500,7 @@ module.exports = {
   getCodexHome,
   getHomeMarketplacePath,
   getHomePluginRoot,
+  installCodexSurface,
   mergeCodexConfigFile,
   removeLegacyCodexSurface,
   removeMarketplaceEntry,

package/bin/install.js

@@ -9,8 +9,8 @@ const {
   getCodexHome,
   getHomeMarketplacePath,
   getHomePluginRoot,
+  installCodexSurface,
   mergeCodexConfigFile,
-  removeLegacyCodexSurface,
   warnWindowsHooks,
 } = require('./install-shared');
 
@@ -25,9 +25,9 @@ function main() {
 
   try {
     copyPluginBundle(PACKAGE_ROOT, pluginRoot);
-    ensureMarketplaceEntry(marketplacePath, './plugins/babysitter-codex');
+    ensureMarketplaceEntry(marketplacePath, pluginRoot);
     mergeCodexConfigFile(path.join(codexHome, 'config.toml'));
-    removeLegacyCodexSurface(codexHome);
+    installCodexSurface(PACKAGE_ROOT, codexHome);
 
     const active = ensureGlobalProcessLibrary(PACKAGE_ROOT);
     console.log(`[babysitter-codex]   marketplace: ${marketplacePath}`);

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.2df34517",
+  "version": "0.1.6-staging.3faa6c86",
   "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",
@@ -15,6 +15,8 @@
   },
   "files": [
     ".codex-plugin/",
+    ".app.json",
+    "assets/",
     "hooks/",
     "hooks.json",
     "skills/",
@@ -41,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.2df34517"
+    "@a5c-ai/babysitter-sdk": "0.0.183-staging.3faa6c86"
   }
 }

package/scripts/team-install.js

@@ -7,6 +7,7 @@ const {
   copyPluginBundle,
   ensureGlobalProcessLibrary,
   ensureMarketplaceEntry,
+  installCodexSurface,
   mergeCodexConfigFile,
   warnWindowsHooks,
   writeJson,
@@ -54,8 +55,9 @@ function main() {
   }
 
   copyPluginBundle(packageRoot, workspacePluginRoot);
-  ensureMarketplaceEntry(workspaceMarketplacePath, './plugins/babysitter-codex');
+  ensureMarketplaceEntry(workspaceMarketplacePath, workspacePluginRoot);
   mergeCodexConfigFile(workspaceConfigPath);
+  installCodexSurface(packageRoot, path.join(workspaceRoot, '.codex'));
 
   const active = ensureGlobalProcessLibrary(packageRoot);
   installInfo.processLibraryStateFile = active.stateFile;

package/skills/babysit/SKILL.md

@@ -1,414 +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
-
-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.
-
-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; on native 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
+make sure you have jq installed and available in the path. if not, install it.
 
-When running non-interactively:
+## Instructions
 
-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:
+Run the following command to get full orchestration instructions:
 
 ```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
+babysitter instructions:babysit-skill --harness codex --interactive
 ```
 
-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
-
-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.
-
-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 native 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.
-
-For resuming existing runs in a manual recovery flow:
+For non-interactive runs (e.g., with `-p` flag or no question tool):
 
 ```bash
-$CLI session:resume \
-  --session-id <id> \
-  --state-dir .a5c \
-  --run-id <runId> \
-  --runs-dir .a5c/runs \
-  --json
+babysitter instructions:babysit-skill --harness codex --no-interactive
 ```
 
-### 3. Run iteration
-
-```bash
-$CLI run:iterate .a5c/runs/<runId> --json --iteration <n> --plugin-root "${CODEX_PLUGIN_ROOT}"
-```
-
-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
-
-```bash
-$CLI task:list .a5c/runs/<runId> --pending --json
-```
-
-### 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 revive prompt aliases as a parallel integration surface
-- do not fabricate a session id
-- use `notify` only for telemetry or monitoring, never as the orchestration
-  control loop
-- on native Windows, 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/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`