babysit

Orchestrate .a5c/runs/<runId>/ through iterative execution. Use the SDK CLI to drive the orchestration loop.

Native Windows caveat: Codex does not execute hooks on Windows yet. When 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.

Non-Negotiables

• Preserve user intent over speed. Never optimize for "get any completion proof" at the expense of the requested scope, quality, or process style.
• Do not create temporary/minimal throwaway processes to force completion unless the user explicitly approves a reduced-scope recovery path.
• If blocked, repair the current run/session first. Only switch strategy after stating the blocker and getting user approval when the new strategy changes intent or scope.
• Use the Babysitter orchestration model end-to-end. Do not bypass with ad-hoc execution, fake outputs, or side workflows that are not represented as tasks.

Dependencies

Babysitter SDK and CLI

Use the installed CLI alias:

CLI="babysitter"

If it is not available on the path, use:

CLI="npx -y @a5c-ai/babysitter-sdk"

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
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 - the Codex stop hook decides whether to continue (on Windows, stay in-turn and continue the loop yourself instead)
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 the intent, requirements, goal, scope, etc.

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. You MUST resolve the active library root with babysitter process-library:active --json before process authoring, and you MUST conduct an actual search against that active process library instead of skipping directly to writing a process. The process-library:active command bootstraps the shared global SDK process library automatically if no binding exists yet. Read binding.dir from the returned JSON to get the active process-library root that must be searched. If you need the cloned repo root itself, read defaultSpec.cloneDir from the same JSON. After that, treat specializations/**/**/**, methodologies/, contrib/, and reference/ as paths relative to binding.dir.

The first step should be to 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.

Then this phase can have: research online, research the repo, user questions, and other steps one after the other until the intent, requirements, goal, scope, etc. are clear and the user is satisfied with the understanding. After each step, decide the type of next step to take. Do not plan more than 1 step ahead in this phase. The same step type can be used more than once in this phase.

Non-interactive mode (running with -p flag or no AskUserQuestion tool)

When running non-interactively, skip the interview phase entirely. Instead:

1. Parse the initial prompt to extract intent, scope, and requirements.
2. Research the repo structure to understand the codebase.
3. Resolve the active process-library root with babysitter process-library:active --json, then search that active library for the most relevant specialization/methodology. Do not skip this search step.
4. Proceed directly to the process creation phase using the extracted requirements.

User Profile Integration

Before building the process, check for an existing user profile to personalize the orchestration:

1. Read user profile: Run babysitter profile:read --user --json to load the user profile. Always use the CLI for profile operations -- never import or call SDK profile functions directly.

2. Pre-fill context: Use the profile to understand the user's specialties, expertise levels, preferences, and communication style. This informs how you conduct the interview (skip questions the profile already answers) and how you build the process.

3. Breakpoint density: Use the breakpointTolerance field to calibrate breakpoint placement in the generated process:

   • minimal/low (expert users): Fewer breakpoints -- only at critical decision points (architecture choices, deployment, destructive operations)
   • moderate (intermediate users): Standard breakpoints at phase boundaries
   • high/maximum (novice users): More breakpoints -- add review gates after each implementation step, before each integration, and at every quality gate
   • Always respect alwaysBreakOn for operations that must always pause (e.g., destructive-git, deploy)
   • If skipBreakpointsForKnownPatterns is true, reduce breakpoints for operations the user has previously approved

4. Tool preferences: Use toolPreferences and installedSkills/ installedAgents to prioritize which agents and skills to use in the process. Prefer tools the user is familiar with.

5. Communication style: Adapt process descriptions and breakpoint questions to match the user's communicationStyle preferences (tone, explanationDepth, preferredResponseFormat).

6. If no profile exists: Proceed normally with the interview phase.

7. CLI profile commands (mandatory): All profile operations MUST use the babysitter CLI -- never import SDK profile functions directly.

   • babysitter profile:read --user --json
   • babysitter profile:read --project --json
   • babysitter profile:write --user --input <file> --json
   • babysitter profile:write --project --input <file> --json
   • babysitter profile:merge --user --input <file> --json
   • babysitter profile:merge --project --input <file> --json
   • babysitter profile:render --user
   • babysitter profile:render --project

   Use --dir <dir> to override the default profile directory when needed.

Process creation phase

After the interview phase, create the complete custom process files (js and jsons) for the run according to the Process Creation Guidelines and methodologies section. Also install the babysitter-sdk inside .a5c/ if it is not already installed. IMPORTANT: When installing into .a5c/, use npm i --prefix .a5c @a5c-ai/babysitter-sdk or a subshell (cd .a5c && npm i @a5c-ai/babysitter-sdk) to avoid leaving CWD inside .a5c/, which causes doubled path resolution bugs.

You must abide the syntax and structure of the process files from the process library.

IMPORTANT -- Path resolution: Always use absolute paths for --entry when calling run:create, and always run the CLI from the project root directory (not from .a5c/).

User profile awareness: If a user profile was loaded in the User Profile Integration step, use it to inform process design -- adjust breakpoint density per the user's tolerance level, select agents/skills the user prefers, and match the process complexity to the user's expertise.

IMPORTANT -- Profile I/O in processes: When generating process files, all profile read/write/merge operations MUST use the babysitter CLI commands (babysitter profile:read, profile:write, profile:merge, profile:render). Never instruct agents to import or call SDK profile functions directly.

After the process is created and before creating the run:

• Interactive mode: describe the process at high level (not the code or implementation details) to the user and ask for confirmation to use it, also generate it as a [process-name].diagram.md and [process-name].process.md file. If the user is not satisfied with the process, go back to the process creation phase and modify the process according to the feedback.
• Non-interactive mode: proceed directly to creating the run without user confirmation.

Intent Fidelity Checks (required before run:create)

Before calling run:create, verify and document in your working notes:

1. The process scope matches the user prompt (no silent scope cuts).
2. The process structure follows library style/composition patterns rather than a one-off minimal flow.
3. Quality gates exist (verification/refinement loops, integration checks, and/or breakpoints appropriate for the task).
4. Any scope reduction, simplification, or recovery tradeoff is explicitly approved by the user before execution.

If any check fails, do not call run:create yet; fix the process or ask the user for approval of the tradeoff.

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 (single command):

For new runs:

$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> -- path to the process JS file and its named export (e.g., ./my-process.js#process)
• --prompt "$PROMPT" -- the user's initial prompt/request text
• --harness codex -- activates Codex session binding. The session ID is auto-resolved from CODEX_THREAD_ID, CODEX_SESSION_ID, or CODEX_ENV_FILE.
• --state-dir .a5c -- required for honest workspace-local session state
• --plugin-root "${CODEX_PLUGIN_ROOT}" -- plugin root for state resolution

Optional flags:

• --inputs <file> -- path to a JSON file with process inputs
• --run-id <id> -- override auto-generated run ID
• --runs-dir <dir> -- override runs directory (default: .a5c/runs)

Do not pass --session-id explicitly inside a real Codex session. The Codex adapter auto-resolves the session/thread ID from environment variables. Only pass --session-id in out-of-band recovery flows.

Common mistakes to avoid:

• wrong: Calling session:init explicitly
• wrong: Fabricating a session ID when none is available from the environment
• wrong: Trying to bind the session in a separate step after run creation
• correct: Using --harness codex with run:create to create the run AND auto-bind the session, relying on environment variables for honest session binding

For resuming existing runs:

$CLI session:resume \
  --session-id <id> \
  --state-dir .a5c \
  --run-id <runId> --runs-dir .a5c/runs --json

3. Run Iteration

$CLI run:iterate .a5c/runs/<runId> --json --iteration <n> --plugin-root "${CODEX_PLUGIN_ROOT}"

Output:

{
  "iteration": 1,
  "status": "executed|waiting|completed|failed|none",
  "action": "executed-tasks|waiting|none",
  "reason": "auto-runnable-tasks|breakpoint-waiting|terminal-state",
  "count": 3,
  "completionProof": "only-present-when-completed",
  "metadata": { "runId": "...", "processId": "..." }
}

Status values:

• "executed" - Tasks executed, continue looping
• "waiting" - Breakpoint/sleep, pause until released
• "completed" - Run finished successfully
• "failed" - Run failed with error
• "none" - No pending effects

Common mistake to avoid:

• wrong: Calling run:iterate, performing the effect, posting the result, then calling run:iterate again in the same session
• correct: Calling run:iterate, performing the effect, posting the result, then STOPPING the session so the hook triggers the next iteration (except on Windows, where you must continue in-turn)

4. Get Effects

$CLI task:list .a5c/runs/<runId> --pending --json

Output:

{
  "tasks": [
    {
      "effectId": "effect-abc123",
      "kind": "agent|skill|breakpoint",
      "label": "auto",
      "status": "requested"
    }
  ]
}

5. Perform Effects

Run the effect externally to the SDK (by you, your hook, or another worker). After execution (by delegation to an agent or skill), post the outcome summary into the run by calling task:post, which:

• Writes the committed result to tasks/<effectId>/result.json
• Appends an EFFECT_RESOLVED event to the journal
• Updates the state cache

IMPORTANT:

• Delegate using the Task tool if possible.
• Make sure the change was actually performed and not described or implied. (for example, if code files were mentioned as created in the summary, make sure they were actually created.)
• Include in the instructions to the agent or skill to perform the task in full and return only the summary result in the requested schema.

5.1 Breakpoint Handling

5.1.0 Mode Detection and Breakpoint Policy

• If the user is present in chat, default to interactive breakpoint handling.
• Use non-interactive handling only when execution context is explicitly non-interactive (for example no question tool / explicit non-interactive run).
• Never auto-approve breakpoints when mode is ambiguous. Treat ambiguity as interactive and ask explicitly.
• Any mode switch that changes approval behavior must be stated explicitly in the run notes.

5.1.1 Interactive mode

Ask the user explicitly for approval. Include explicit approve/reject options so the user's intent is unambiguous.

CRITICAL: Response validation rules:

• If the response is empty, no selection, or dismissed: treat as NOT approved. Re-ask the question or keep the breakpoint pending. Do NOT proceed.
• NEVER fabricate, synthesize, or infer approval text. Only pass through the user's actual selected response verbatim.
• NEVER assume approval from ambiguous, empty, or missing responses. When in doubt, the answer is "not approved".

CRITICAL: Breakpoint rejection posting rules:

• Breakpoint rejection MUST be posted with --status ok and a value of {"approved": false, "response": "..."}. NEVER use --status error for a user rejection -- that signals a task execution failure and will trigger RUN_FAILED, requiring manual journal surgery to recover.
• Only use --status error if the question tool itself throws an error.

Breakpoint posting examples:

# User approved the breakpoint
echo '{"approved": true, "response": "Looks good, proceed"}' > tasks/<effectId>/output.json
$CLI task:post <runId> <effectId> --status ok --value tasks/<effectId>/output.json

# User rejected the breakpoint (ALWAYS use --status ok, not --status error)
echo '{"approved": false, "response": "Stop here"}' > tasks/<effectId>/output.json
$CLI task:post <runId> <effectId> --status ok --value tasks/<effectId>/output.json

5.1.2 Non-interactive mode

Choose the best option from context and post the result. Rejections still use --status ok with {"approved": false}.

6. Results Posting

IMPORTANT: Do NOT write result.json directly. The SDK owns that file.

Workflow:

1. Write the result value to a separate file (e.g., output.json or value.json):

{
  "score": 85,
  "details": { ... }
}

2. Post the result, passing the value file:

$CLI task:post .a5c/runs/<runId> <effectId> \
  --status ok \
  --value tasks/<effectId>/output.json \
  --json

The task:post command will:

• Read the value from your file
• Write the complete result.json (including schema, metadata, and your value)
• Append an EFFECT_RESOLVED event to the journal
• Update the state cache

Available flags:

• --status <ok|error> (required)
• --value <file> - Result value (for status=ok)
• --error <file> - Error payload (for status=error)
• --stdout-file <file> - Capture stdout
• --stderr-file <file> - Capture stderr
• --started-at <iso8601> - Task start time
• --finished-at <iso8601> - Task end time
• --metadata <file> - Additional metadata JSON

Common mistake to avoid:

# wrong: Writing result.json directly
echo '{"result": {...}}' > tasks/<effectId>/result.json
$CLI task:post <runId> <effectId> --status ok

# correct: Write value to separate file, let SDK create result.json
echo '{"score": 85}' > tasks/<effectId>/output.json
$CLI task:post <runId> <effectId> --status ok --value tasks/<effectId>/output.json

Breakpoint-specific posting:

# Breakpoint approval
echo '{"approved": true, "response": "User approved"}' > tasks/<effectId>/output.json
$CLI task:post <runId> <effectId> --status ok --value tasks/<effectId>/output.json

# Breakpoint rejection (ALWAYS use --status ok, not --status error)
echo '{"approved": false, "response": "User rejected"}' > tasks/<effectId>/output.json
$CLI task:post <runId> <effectId> --status ok --value tasks/<effectId>/output.json

7. STOP after every phase after run-session association

After run:create or any posted effect result, end the current turn and yield back to the Codex hook loop. The stop hook drives the loop, not you. 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.

Common mistakes to avoid:

• wrong: Stopping the session before run-session association
• correct: Stopping the session after run-session association, then after every iteration, letting the hook call you back to continue the loop until completion.
• wrong: Calling run:iterate multiple times in the same session without stopping and letting the hook call you back (except on Windows where this is required).
• correct: Calling run:iterate once, then stopping and letting the hook call you back for the next iteration until completion.

On native Windows, an in-turn loop across run:iterate -> task:list -> effect execution -> task:post is expected and valid because hooks do not resume the session. This is not considered bypassing the orchestration model as long as each iteration/effect is handled through the CLI and run journal.

8. Completion Proof

When the run is completed, the CLI will emit a completionProof value in the output of run:iterate and run:status. You must return that exact value wrapped in a <promise>...</promise> tag to signal completion to the stop-hook loop.

Progressing Between The Phases

After you run run:create, progress through the phases above by stopping the session, which will trigger the stop-hook and call you with the next phase. After you finish each phase after run:create, stop the session and return control to the user until you are called again by the hook.

Task Kinds

CRITICAL RULE: NEVER use node kind effects in generated processes. The node kind executes inline Node.js scripts which bypasses the agent orchestration model entirely. Every task that would be a node effect MUST be converted to an agent or skill effect instead. The only acceptable non-agent kinds are shell (for running existing test suites, git commands, or build tools), breakpoint (human approval), and sleep (time gates).

Agent Task Example

Important: Check which subagents and agents are actually available before assigning the name. If none, pass the general-purpose subagent. Check the subagents and agents in the plugin (in nested folders) and to find relevant subagents and agents to use as a reference. Specifically check subagents and agents in folders next to the reference process file.

When executing the agent task, use the Task tool. Never use the Babysitter skill or agent to execute the task.

export const agentTask = defineTask('agent-scorer', (args, taskCtx) => ({
  kind: 'agent',
  title: 'Agent scoring',
  agent: {
    name: 'quality-scorer',
    prompt: {
      role: 'QA engineer',
      task: 'Score results 0-100',
      context: { ...args },
      instructions: ['Review', 'Score', 'Recommend'],
      outputFormat: 'JSON'
    },
    outputSchema: {
      type: 'object',
      required: ['score']
    }
  },

  io: {
    inputJsonPath: `tasks/${taskCtx.effectId}/input.json`,
    outputJsonPath: `tasks/${taskCtx.effectId}/output.json`
  }
}));

Skill Task Example

Important: Check which skills are actually available before assigning the skill name. Check the skills in the plugin (in nested folders) and to find relevant skills to use as a reference. Skills are preferred over subagents for executing tasks.

export const skillTask = defineTask('analyzer-skill', (args, taskCtx) => ({
  kind: 'skill',
  title: 'Analyze codebase',

  skill: {
    name: 'codebase-analyzer',
    context: {
      scope: args.scope,
      depth: args.depth,
      analysisType: args.type,
      criteria: ['Code consistency', 'Naming conventions', 'Error handling'],
      instructions: [
        'Scan specified paths for code patterns',
        'Analyze consistency across the codebase',
        'Check naming conventions',
        'Review error handling patterns',
        'Generate structured analysis report'
      ]
    }
  },

  io: {
    inputJsonPath: `tasks/${taskCtx.effectId}/input.json`,
    outputJsonPath: `tasks/${taskCtx.effectId}/output.json`
  }
}));

Quick Commands Reference

Create run (with session binding):

$CLI run:create --process-id <id> --entry <path>#<export> --inputs <file> \
  --prompt "$PROMPT" --harness codex \
  --state-dir .a5c --plugin-root "${CODEX_PLUGIN_ROOT}" --json

Check status:

$CLI run:status <runId> --json

When the run completes, run:iterate and run:status emit completionProof. Use that exact value in a <promise>...</promise> tag to end the loop.

View events:

$CLI run:events <runId> --limit 20 --reverse

List tasks:

$CLI task:list <runId> --pending --json

Post task result:

$CLI task:post <runId> <effectId> --status <ok|error> --json

Iterate:

$CLI run:iterate <runId> --json --iteration <n> --plugin-root "${CODEX_PLUGIN_ROOT}"

Recovery from failure

If at any point the run fails due to SDK issues or corrupted state or journal, analyze the error and the journal events. Recover the state and journal to the last known good state, adapt, and try to continue the run.

Failure Protocol (required)

When blocked or failed, follow this order:

1. Report the concrete blocker and root cause (command/output based, not vague).
2. Attempt repair of current run/session/journal first.
3. Present recovery options when strategy changes intent/scope:
   • Option A: continue intent-faithful repair path (recommended)
   • Option B: reduced-scope fallback (requires explicit user approval)
4. Do not create a new simplified process without explicit approval if it reduces scope or quality expectations.
5. Resume orchestration only after the chosen recovery path is explicit.

Process Creation Guidelines and methodologies

• When building UX and full stack applications, integrate/link the main pages of the frontend with functionality created for every phase of the development process (where relevant), so that there is a way to test the functionality as you go.

• Unless otherwise specified, prefer quality gated iterative development loops in the process.

• You can change the process after the run is created or during the run (and adapt the process accordingly and journal accordingly) in case you discover new information or requirements.

• The process should be a comprehensive and complete solution to the user request.

• The process should usually be a composition (in code) of multiple processes from the process library (not just one), for multiple phases and parts of the process, each utilizing a different process from the library as a reference.

• Include verification and refinement steps (and loops) for planning phases and integration phases, debugging phases, refactoring phases, etc.

• Create the process with (and around) the available skills and subagents. (check which are available first and use discover to find them)

• Prefer incremental work that allows testing and experimentation with the new functionality as you go.

Process File Discovery Markers

When creating process files, include @skill and @agent markers in the JSDoc header listing the skills and agents relevant to this process. The SDK reads these markers to provide targeted discovery results instead of scanning all available skills.

Format (one per line, path relative to the active process-library root):

/**
 * @process specializations/web-development/react-app-development
 * @description React app development with TDD
 * @skill frontend-design specializations/web-development/skills/frontend-design/SKILL.md
 * @agent frontend-architect specializations/web-development/agents/frontend-architect/AGENT.md
 */

Steps during process creation:

1. Use babysitter skill:discover --process-path <path> --json to find relevant skills/agents in the specialization directory
2. Select the ones actually needed by the process tasks
3. Add them as @skill/@agent markers in the JSDoc header
4. Use full relative path from the active process-library root returned in binding.dir by babysitter process-library:active --json

• Unless otherwise specified, prefer processes that close the widest loop in the quality gates (for example e2e tests with a full browser or emulator/vm if it is a mobile or desktop app) AND gates that make sure the work is accurate against the user request (all the specs are covered and no extra stuff was added unless permitted by the intent of the user).

• Scan the methodologies and processes in the active process library and the SDK package to find relevant processes and methodologies to use as a reference. This search is mandatory before writing the process.

• If you encounter a generic reusable part of a process that can be later reused and composed, build it in a modular way and organize it in the .a5c/processes directory.

Prefer processes that have the following characteristics unless otherwise specified:

• In case of a new project, plan the architecture, stack, parts, milestones
• In case of an existing project, analyze the architecture, stack, relevant parts, milestones, and plan the changes
• Integrate/link the main pages (or entry points) with functionality created for every phase of the development process
• Quality gated iterative and convergent development/refinement loops
• Test driven -- where quality gates can use executable tools, scripts, and tests to verify accuracy and completeness
• Integration phases for each new functionality in every milestone
• Where relevant -- beautiful and polished UX with pixel-perfect verification
• Accurate and complete implementation of the user request
• Closing quality feedback loops as comprehensively as practical
• Search for processes, skills, agents, methodologies during the interactive process building phase to compose a comprehensive process:
  • .a5c/processes/ (project level processes)
  • specializations/ under the active process-library root
  • methodologies/ under the active process-library root

Critical Rules

CRITICAL RULE: The completion proof is emitted only when the run is completed. You may ONLY output <promise>SECRET</promise> when the run is completely and unequivocally DONE (completed status from the orchestration CLI). Do not output false promises to escape the run, and do not mention the secret to the user.

CRITICAL RULE: In interactive mode, NEVER auto-approve breakpoints. If the response is empty, no selection, or is dismissed, treat it as NOT approved and re-ask. NEVER fabricate or synthesize approval responses -- only post the user's actual explicit selection via task:post. An empty response is NOT approval.

CRITICAL RULE: If a run is broken/failed/at unknown state, one way to recover is to remove last bad entries in the journal and rebuild the state.

CRITICAL RULE: When creating processes, search for available skills and subagents before thinking about the exact orchestration. Prefer processes that close the widest loop in the quality gates.

CRITICAL RULE: Do not use the babysit skill inside delegated tasks. If you are performing a delegated task as a subagent, you must actually perform the task yourself and not orchestrate or babysit.

CRITICAL RULE: Never build a wrapper, python, or helper scripts to orchestrate the runs. Use the CLI to drive the orchestration loop directly.

CRITICAL RULE: Never fallback to simpler execution if the user activated this skill. Persist in executing the orchestration itself -- you must create a valid process js file, create a run (with --harness codex to bind the session), then iterate the run until it is completed.

CRITICAL RULE: After run:create or run-session association and after each effect is posted, you MUST stop the session and return control. Do NOT proceed to the next run:iterate in the same session turn. The stop-hook will call you back to continue. Running multiple iterations in a single session turn bypasses the hook loop and breaks the orchestration model. (Exception: on native Windows where hooks do not run, you must continue in-turn.)

CRITICAL RULE: NEVER use kind: 'node' in generated process files. All tasks MUST use kind: 'agent' or kind: 'skill'. The only non-agent kinds allowed are shell (for existing CLI tools/tests/git), breakpoint, and sleep.

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 create helper scripts. Use the CLI to drive the orchestration loop. On native Windows, an in-turn iterative loop is required because hooks do not resume execution there. Not for simple tasks, and even if things get complicated. Persist in executing the orchestration itself.

CRITICAL RULE: Do not fabricate a session ID. Let the Codex adapter auto-resolve it from CODEX_THREAD_ID, CODEX_SESSION_ID, or CODEX_ENV_FILE.

See Also

• library/tdd-quality-convergence.js - TDD quality convergence example
• library/reference/ADVANCED_PATTERNS.md - Agent/skill patterns, iterative convergence
• library/reference/sdk.md - SDK API reference