Docs › Reference › Glossary

Babysitter Glossary

**Version:** 1.2 **Last Updated:** 2026-06-22 Last refreshed: 2026-06-23 **Audience:** All users

This glossary provides definitions for technical terms and concepts used in Babysitter documentation. Terms are organized alphabetically with cross-references to related concepts and links to detailed documentation.

---

Quick Reference for Beginners

**New to Babysitter?** Here are the 10 most important terms to know:

**Start here:** Read the Getting Started guide to see these concepts in action.

---

On this page

• A | B | C | D | E | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W

---

A

Agent

A **task type** representing LLM-powered operations within a process. Agents perform intelligent tasks like planning, scoring, code review, and analysis.

**Example:**

{
  kind: 'agent',
  agent: {
    name: 'quality-scorer',
    prompt: { role: 'QA engineer', task: 'Score results 0-100' }
  }
}

**Related:** Task, Skill, Effect

**See Also:** Process Definitions

---

Agent Task

A task definition that invokes an LLM agent to perform intelligent operations. Agent tasks specify the agent name, prompt configuration, and expected output schema.

**Example:**

const agentTask = defineTask('scorer', (args, ctx) => ({
  kind: 'agent',
  title: 'Score quality',
  agent: {
    name: 'quality-scorer',
    prompt: {
      role: 'QA engineer',
      task: 'Score the implementation',
      outputFormat: 'JSON'
    },
    outputSchema: { type: 'object', required: ['score'] }
  }
}));

**Related:** Agent, Task Definition

---

Adapter

A unit in Babysitter's **Adapters** runtime that lets the same orchestration core drive many different harnesses, providers, and integrations without bespoke per-target code. Instead of writing integration code for each new harness, you add an adapter/data entry that the Atlas catalog discovers at runtime. Specialized adapters include the Hooks Adapter, the Breakpoints Adapter, and the Transport Adapter.

**Related:** Harness, Atlas, Adapters CLI

**See Also:** Adapters

---

Adapters CLI

The host-side companion CLI (adapters, package @a5c-ai/adapters-cli) for running and managing AI coding harnesses directly from your shell - install, run, models, sessions, config, and auth. It runs a harness from *outside*, whereas the in-session /babysitter:* commands drive an orchestration run from *inside* a harness.

**Binary:** adapters · **Requires:** Node.js >=20.9.0

**See Also:** Adapters CLI Reference

---

Agent-Mux

**Deprecated.** Renamed to Adapters. The harness-agnostic runtime formerly called "Agent Mux" is now the **Adapters** runtime; use that term.

---

Approval Gate

See Breakpoint.

---

Atlas

The catalog that the Adapters runtime reads to discover harness capabilities and adapters. New harness support is largely a matter of adding an entry to Atlas rather than writing bespoke integration code. Inspect it with the atlas (alias a5c-atlas) binary.

**Related:** Adapter, Harness

**See Also:** Adapters

---

Artifact

Any file produced during a run, stored in the artifacts/ directory. Common artifacts include plans, specifications, reports, and generated documentation.

**Location:** .a5c/runs/<runId>/artifacts/

**Examples:**

• process.md - Process description
• plan.md - Implementation plan
• specs.md - Specifications document

**Related:** Run Directory

---

B

Babysitter

The harness-agnostic orchestration framework (v6) that enables deterministic, event-sourced workflow management across any supported AI coding harness via the Adapters runtime. Babysitter provides structured multi-step workflows with quality gates, human approval checkpoints, and session persistence.

**Components:**

• Main CLI (@a5c-ai/babysitter) - End-user command-line tool (the primary install) for babysitter
• SDK (@a5c-ai/babysitter-sdk) - Programmatic runtime imported by process code; public SDK/library and core CLI implementation
• Runtime CLI (@a5c-ai/genty-platform) - Optional runtime/orchestration commands
• Plugin (babysitter@a5c.ai) - Per-harness extension package (skills, hooks, commands)

**Related:** SDK, Blueprint, Plugin, Harness

---

Babysitter Skill

The primary Claude Code skill for orchestrating runs. The skill manages the orchestration loop, executing iterations until completion.

**Location:** plugins/babysitter-unified/skills/babysit/SKILL.md

**Invocation:**

/babysitter:call Build a REST API with TDD

**Equivalent verbs:** The following commands are functionally identical:

• /babysitter:call build a feature
• /babysitter:call create a feature
• /babysitter:call implement a feature

All verbs (build, create, implement) trigger the same orchestration workflow.

**Related:** Skill, In-Session Loop

---

Breakpoint

A pause point in a process that requires human approval before continuing. Breakpoints enable human-in-the-loop workflows for critical decisions like deployment approval, plan review, or security-sensitive changes. ctx.breakpoint() returns a BreakpointResult containing { approved: boolean; response?: string; feedback?: string; option?: string; respondedBy?: string; allResponses?: array }.

Breakpoints support **routing** to direct approval requests to specific experts via the expert field (a string, array of strings, or 'owner'), categorization via tags, and multi-reviewer resolution via strategy ('single', 'first-response-wins', 'collect-all', or 'quorum'). The previousFeedback and attempt fields provide retry context when a breakpoint is re-presented after rejection.

**Example:**

const result = await ctx.breakpoint({
  question: 'Approve the deployment?',
  title: 'Production Deployment',
  expert: 'ops-lead',
  tags: ['deployment', 'production'],
  context: {
    files: [{ path: 'artifacts/plan.md', format: 'markdown' }]
  }
});
if (!result.approved) {
  ctx.log('Deployment rejected', { feedback: result.feedback, by: result.respondedBy });
}

**See Also:** Breakpoints Feature

---

Breakpoints Adapter

The v6, harness-agnostic home for human-in-the-loop approvals, part of the Adapters runtime. It routes a breakpoint question to a durable backend so an approval can outlive the session or happen somewhere other than the chat, and it cryptographically signs approvals for tamper-evidence ("proven" approvals). It **replaces** the legacy breakpoints-pro package (now deprecated).

**Related:** Breakpoint, Adapter

**See Also:** Breakpoints Feature, Security

---

Blueprint

A packaged, installable unit of orchestration content (processes, skills, hooks, commands) for a harness. In v6 the processes directory is blueprints/ (formerly plugins/), and the in-session command namespace is blueprints:* (the older plugin:* aliases are **deprecated**). Manage blueprints with /babysitter:blueprints.

**Related:** Plugin, Process

---

C

CLI (Command-Line Interface)

The command-line tool for managing Babysitter runs. Provides commands for run lifecycle management, task operations, and state inspection.

**Binary Name:** babysitter

**Installation:**

npm install -g @a5c-ai/babysitter

**Related:** SDK

**See Also:** CLI Reference

---

Completion Promise

A special XML tag that signals the end of an in-session loop. When Claude outputs <promise>TEXT</promise> where TEXT matches the completion proof, the loop exits.

**Format:** <promise>COMPLETION_PROOF</promise>

**Usage:** Only output when the run status is completed.

**Related:** In-Session Loop, Completion Proof

---

Completion Proof

A unique string emitted by run:iterate and run:status when a run completes successfully. Used with the completion promise to exit the in-session loop.

**Example Output:**

{
  "status": "completed",
  "completionProof": "run-abc123-completed-xyz789"
}

**Related:** Completion Promise

---

Context API

The interface available to process functions for interacting with the orchestration system. Provides methods for executing tasks, creating breakpoints, parallel execution, and state management.

**Methods:**

• ctx.task(taskDef, inputs) - Execute a task
• ctx.breakpoint(payload) - Request human approval, returns BreakpointResult. Supports expert, tags, strategy, previousFeedback, and attempt routing fields.
• ctx.sleepUntil(timestamp) - Time gate
• ctx.parallel.all(tasks) - Parallel execution
• ctx.hook(name, payload) - Call custom hooks
• ctx.log(message) - Log to journal
• ctx.now() - Get deterministic timestamp

**Related:** Process, Intrinsic

---

Convergence

See Quality Convergence.

---

D

Deterministic Replay

The ability to reproduce the exact same execution path given the same inputs and journal. Achieved through event sourcing where all state changes are recorded as immutable events.

**Benefits:**

• Time-travel debugging
• Reliable session resumption
• Audit trail verification

**Related:** Event Sourcing, Journal

---

E

Effect

A side-effect request generated by process execution. Effects include tasks, breakpoints, and sleep gates. Each effect has a unique effectId and tracks status through the journal.

**Effect Kinds:**

• node - Node.js script execution
• agent - LLM agent invocation
• skill - Claude Code skill invocation
• breakpoint - Human approval gate
• sleep - Time-based wait

**Related:** Effect ID, Task

---

Effect ID

A unique identifier assigned to each effect within a run. Used for tracking, posting results, and state management.

**Format:** effect-<ulid>

**Example:** effect-01HJKMNPQR3STUVWXYZ012345

**Related:** Effect

---

Entry Point

The JavaScript/TypeScript file and export that defines a process. Specified when creating a run using the --entry flag.

**Format:** <path>#<export>

**Example:** .a5c/processes/build/process.js#buildProcess

**Related:** Process, run:create

---

Event

A single immutable record in the journal representing a state change. Events have a type, recordedAt timestamp, data object, and checksum. The sequence number is derived from the filename, not stored in the event body.

**Event Types:**

• RUN_CREATED - Run initialization
• EFFECT_REQUESTED - Effect requested (includes breakpoints with kind: "breakpoint")
• EFFECT_RESOLVED - Effect completed (with status: "ok" or "error")
• RUN_COMPLETED - Successful completion
• RUN_FAILED - Run failure

**Related:** Journal, Event Sourcing

---

Event Sourcing

An architectural pattern where all state changes are recorded as immutable events. State is derived by replaying the event history. This enables deterministic replay, audit trails, and time-travel debugging.

**Benefits:**

• Complete audit trail
• Deterministic behavior
• Resumable sessions
• Debug-friendly

**Related:** Journal, Deterministic Replay

---

G

genty

A supported harness (harness key genty), distributed from npm as @a5c-ai/babysitter-genty. Formerly named **tula** (now deprecated).

**See Also:** Install Matrix

---

GSD (Get Stuff Done)

A methodology focused on rapid task completion. GSD emphasizes pragmatic execution over extensive planning.

**Location:** library/methodologies/gsd/

**Related:** Methodology, TDD

---

H

Harness

An AI coding tool that Babysitter drives - Claude Code, Codex, Cursor, Gemini, GitHub Copilot, genty, and others. Babysitter v6 is harness-agnostic via the Adapters runtime and supports a dozen (12) harnesses. Each harness has a **harness key** (the argument to babysitter harness:install-plugin <harness-key>), which is not always the harness's display name.

**Related:** Adapter, Atlas

**See Also:** Install Matrix

---

Hook

A shell script executed at specific lifecycle points during orchestration. Hooks enable custom behavior for task execution, notifications, logging, and integrations.

**Discovery Priority:** 1. Per-repo: .a5c/hooks/<hook-name>/ 2. Per-user: ~/.config/babysitter/hooks/<hook-name>/ 3. Plugin: plugins/babysitter-unified/hooks/<hook-name>/

**Hook Types:**

• on-run-start - When run is created
• on-run-complete - When run completes
• on-iteration-start - Before iteration (core orchestration)
• on-iteration-end - After iteration
• on-task-start - Before task execution
• on-task-complete - After task execution
• on-breakpoint - Breakpoint notification

**Related:** Hook Dispatcher

**See Also:** Configuration Reference

---

Hook Dispatcher

The component that discovers and executes hooks. The maintained hook source lives under plugins/babysitter-unified/hooks/. It is responsible for finding hooks, executing them with payloads, and collecting results.

**Related:** Hook

---

Hooks Adapter

The v6 unification layer for hooks, part of the Adapters runtime. It provides a canonical session store plus a merge engine that takes each harness's distinct hook/continuation model and presents one consistent contract to the runtime and to your custom hooks. SDK lifecycle hooks behave the same everywhere; what varies is the per-harness continuation model that advances the loop each turn. Do not assume Claude Code's Stop-hook model on other harnesses.

**Related:** Hook, Adapter

**See Also:** Hooks

---

Human-in-the-Loop

A workflow pattern that includes human approval checkpoints. Implemented through breakpoints that pause execution until a human reviews and approves.

**Use Cases:**

• Production deployments
• Security-sensitive changes
• Major architectural decisions
• Plan and specification review

**Related:** Breakpoint

---

I

In-Session Loop

A mechanism for continuous iteration within a single harness session: each turn the loop re-injects the next iteration until the run reaches completion (or max iterations). **How continuation is driven is harness-specific** - it is one part of the per-harness hook/continuation model that the Hooks Adapter normalizes. Claude Code's Stop Hook is one such mechanism; other harnesses use different signals (e.g. Codex also intercepts Stop; Gemini and Antigravity re-inject via an AfterAgent hook with no Stop; openclaw drives it from a daemon; opencode runs the loop within a single turn on session.idle; Hermes drives orchestration over ACP). Do not assume Claude Code's Stop-hook model on other harnesses.

**Components:**

• State file: $BABYSITTER_PLUGIN_ROOT/state/${AGENT_SESSION_ID}.md

**Invocation:**

/babysitter:call Build feature --max-iterations 20

**Related:** Hooks Adapter, Stop Hook, Completion Promise

---

Inputs

The initial data provided to a process when creating a run. Stored in inputs.json at the run root.

**Location:** .a5c/runs/<runId>/inputs.json

**Example:**

{
  "feature": "user-authentication",
  "targetQuality": 85,
  "maxIterations": 5
}

**Related:** Run, Process

---

Intrinsic

A built-in SDK function callable from within a process. Intrinsics provide the core capabilities for task execution, breakpoints, parallel operations, and state management.

**Core Intrinsics:**

• ctx.task() - Execute a task
• ctx.breakpoint() - Request approval, returns BreakpointResult. Supports routing (expert, tags, strategy) and retry context (previousFeedback, attempt).
• ctx.sleepUntil() - Time gate
• ctx.parallel.all() - Batch execution
• ctx.hook() - Custom hooks
• ctx.log() - Logging
• ctx.now() - Timestamp

**Related:** Context API

---

Invocation Key

A unique identifier for a specific call to a task within a process. Used to track and deduplicate task executions.

**Format:** <taskId>:<sequence>

**Example:** task/build:1

**Related:** Task, Effect

---

Iteration

A single pass through the orchestration loop. Each iteration processes pending effects, executes tasks, and updates state.

**Iteration Status Values:**

• executed - Tasks executed, continue looping
• waiting - Breakpoint or sleep active
• completed - Run finished successfully
• failed - Run failed with error
• none - No pending effects

**Related:** Orchestration Loop

---

J

Journal

The append-only event log recording all state changes. Located at .a5c/runs/<runId>/journal/. Each event is stored as a separate JSON file.

**File Naming:** <sequence>.<ulid>.json

**Example:** 000042.01HJKMNPQR3STUVWXYZ012345.json

**Benefits:**

• Complete audit trail
• Deterministic replay
• State reconstruction
• Time-travel debugging

**Related:** Event, Event Sourcing

**See Also:** Journal System

---

JSON Lines (JSONL)

A format where each line is a complete JSON object. Used for streaming data.

**Note:** The Babysitter journal does **not** use JSONL format. It stores individual JSON files, one per event.

---

K

Kind

The type classification of an effect or task. Determines how the effect is executed.

**Effect Kinds:**

• node - Node.js script
• shell - Shell command
• agent - LLM agent
• skill - Claude Code skill
• breakpoint - Human approval
• sleep - Time gate

**Related:** Effect, Task

---

Kradle

The artifact/content store component (formerly **Krate**). Use the name "Kradle"; "Krate" is **deprecated**.

---

Krate

**Deprecated.** Renamed to Kradle. Use "Kradle".

---

L

Label

An optional descriptive string attached to tasks for identification in logs and UI.

**Example:**

{
  kind: 'node',
  label: 'Build workspace',
  node: { entry: './scripts/build.js' }
}

**Related:** Task

---

M

Methodology

A high-level structured approach or pattern for software development. Methodologies define the *conceptual framework* - the "what" and "why" of a development approach.

**Key distinction:** Methodology = high-level concept/pattern; Process = low-level code implementation of a methodology.

**You can use ANY methodology and get great results.** In this repository snapshot, Babysitter includes 38 methodology directories under library/methodologies/ - pick the one that fits your project style, or let Babysitter choose automatically based on your request.

**Built-in Methodologies (examples from the current library):**

Each methodology has one or more Process implementations in the codebase. Browse all methodologies at `library/methodologies/`.

**Related:** Process, TDD Quality Convergence, Process Library

---

N

Node Task

A task type that executes a Node.js script. The most common task type for running build scripts, tests, and automation.

**Example:**

{
  kind: 'node',
  node: {
    entry: './scripts/build.js',
    timeout: 300000
  }
}

**Related:** Task, Effect

---

O

Orchestration

The process of managing run execution and state. Orchestration coordinates task execution, handles effects, and maintains the event journal.

**Related:** Orchestration Loop, Run

---

Orchestration Loop

The iterative cycle that drives run execution. Each loop iteration: runs run:iterate, checks pending effects, executes tasks, posts results.

**Flow:**

iterate -> get effects -> perform effects -> post results -> repeat

**Related:** Iteration, run:iterate

---

P

Parallel Execution

The ability to execute multiple tasks concurrently. Implemented via ctx.parallel.all().

**Example:**

const [build, lint, test] = await ctx.parallel.all([
  () => ctx.task(buildTask, {}),
  () => ctx.task(lintTask, {}),
  () => ctx.task(testTask, {})
]);

**Related:** Context API

**See Also:** Parallel Execution

---

Pending Effect

An effect that has been requested but not yet resolved. Listed via task:list --pending.

**Related:** Effect

---

Plugin

A harness extension package that provides skills, hooks, and commands for orchestration (for example, installed into Claude Code via babysitter harness:install-plugin claude-code).

**Installation:**

claude plugin marketplace add a5c-ai/babysitter-claude
claude plugin install --scope user babysitter@a5c.ai

**Note on naming:** Where "plugin" referred to the orchestration *content* directory (plugins/) or the in-session command namespace (plugin:*), the v6 term is Blueprint - the directory is now blueprints/ and the namespace is blueprints:* (the plugin:* aliases are deprecated). "Plugin" still refers to the per-harness extension package installed by harness:install-plugin.

**Related:** Blueprint, Babysitter Skill, Harness

---

Process

A JavaScript/TypeScript function that is the *low-level code implementation* of a workflow. Processes use the Context API to execute tasks, create breakpoints, and manage state.

**Key distinction:** Process = low-level code implementation; Methodology = high-level concept/pattern that a process implements.

<!-- glossary:process-library:start --> **Babysitter currently exposes 2,243 JavaScript process files in the live repository tree** organized across methodologies, shared processes, and specializations.

<!-- glossary:process-library:end -->

**Structure:**

export async function process(inputs, ctx) {
  const plan = await ctx.task(planTask, inputs);
  const review = await ctx.breakpoint({ question: 'Approve plan?' });
  if (!review.approved) return { success: false, feedback: review.feedback };
  const result = await ctx.task(buildTask, { plan });
  return result;
}

**Location:** .a5c/runs/<runId>/code/main.js

**Related:** Methodology, Context API, Entry Point

**See Also:** Process Definitions, Process Library

---

Process Definition

See Process.

---

Process ID

A unique identifier for a process type. Used when creating runs to specify which process to execute.

**Format:** <namespace>/<name>

**Example:** dev/build, ci/test, tdd/feature

**Related:** Process, run:create

---

Q

Quality Convergence

An iterative methodology that repeats execution until quality metrics meet targets. Each iteration measures quality and refines implementation.

**Example Flow:**

implement -> measure quality -> below target? -> refine -> repeat

**Related:** Quality Score, TDD

**See Also:** Quality Convergence

---

Quality Score

A **multi-dimensional** assessment of implementation quality. Quality scores are not a single number - they comprise multiple dimensions that are weighted and combined into an overall score.

**Dimensions typically include:**

• **Tests**: Pass rate and coverage percentage
• **Code Quality**: Lint errors, complexity, formatting
• **Security**: Vulnerability scans, secrets detection
• **Performance**: Response times, bundle size (when applicable)
• **Type Safety**: TypeScript errors, static analysis

**Example:**

{
  "overall": 85,
  "dimensions": {
    "tests": 92,
    "codeQuality": 88,
    "security": 100,
    "performance": 75
  },
  "weights": {
    "tests": 0.30,
    "codeQuality": 0.25,
    "security": 0.25,
    "performance": 0.20
  }
}

**See Also:** Quality Convergence for the five quality gate categories and detailed scoring formulas in Best Practices.

**Related:** Quality Convergence, Agent

---

R

Result

The output from a completed task. Stored at tasks/<effectId>/result.json.

**Schema:**

{
  "status": "ok",
  "value": { /* task output */ },
  "metadata": { /* execution metadata */ }
}

**Related:** Task, task:post

---

Resume

Continuing a previously interrupted run. The journal enables exact state reconstruction for seamless resumption.

**Command:**

/babysitter:babysit resume --run-id <runId>

**Related:** Run, Deterministic Replay

**See Also:** Run Resumption

---

Run

A single execution of a process. Each run has a unique ID, directory, journal, and state. Runs are resumable across sessions.

**Directory:** .a5c/runs/<runId>/

**Lifecycle:** created -> running -> completed | failed

**Related:** Run ID, Run Directory

---

Run Directory

The directory containing all data for a run.

**Structure:**

.a5c/runs/<runId>/
├── run.json           # Run metadata
├── inputs.json        # Initial inputs
├── code/
│   └── main.js        # Process implementation
├── artifacts/         # Generated files
├── journal/           # Event log
├── state/
│   └── state.json     # State cache
└── tasks/             # Task artifacts

**Related:** Run

---

Run ID

A unique identifier for a run. Typically includes timestamp and description.

**Format:** run-<YYYYMMDD>-<HHMMSS>[-<description>]

**Example:** run-20260125-143012-auth-feature

**Related:** Run

---

S

SDK (Software Development Kit)

The programmatic runtime package providing the orchestration engine and APIs. It is imported by custom process code, not installed as the end-user CLI (for that, see CLI / @a5c-ai/babysitter).

**Package:** @a5c-ai/babysitter-sdk

**Installation:**

npm install @a5c-ai/babysitter-sdk

**Components:**

• Runtime - Process execution engine
• Storage - Journal and state management
• Tasks - Task definition and execution

**Related:** CLI

---

Session ID

A unique identifier for a harness session. Used for state isolation in in-session loops.

**Environment Variable:** AGENT_SESSION_ID (harness-agnostic; supersedes the deprecated BABYSITTER_SESSION_ID and CLAUDE_SESSION_ID). Session resolution is PID-scoped in v6.

**Related:** In-Session Loop

---

Shell Task

A task type that executes shell commands.

**Example:**

{
  kind: 'shell',
  shell: {
    command: 'npm run build',
    cwd: './packages/app'
  }
}

**Related:** Task

---

Skill

A Claude Code capability that provides specialized functionality. The Babysitter skill (babysit) orchestrates runs.

**Invocation:**

/babysitter:babysit <prompt>

**Related:** Babysitter Skill

---

Skill Task

A task type that invokes a Claude Code skill.

**Example:**

{
  kind: 'skill',
  skill: {
    name: 'codebase-analyzer',
    context: { scope: 'src/', depth: 3 }
  }
}

**Related:** Skill, Task

---

Sleep

A time gate that pauses execution until a specified timestamp.

**Example:**

await ctx.sleepUntil(new Date('2026-01-26T10:00:00Z'));

**Related:** Effect

---

State

The current status of a run derived from replaying the journal. Cached at state/state.json for performance.

**Schema:**

{
  "runId": "run-...",
  "status": "running",
  "version": 42,
  "invocations": {},
  "pendingEffects": []
}

**Note:** State cache is gitignored (derived from journal).

**Related:** State Cache, Journal

---

State Cache

A derived snapshot of current state stored for fast access. Rebuilt from journal if missing or stale.

**Location:** .a5c/runs/<runId>/state/state.json

**Related:** State

---

State Version

A monotonically increasing number tracking state changes. Increments with each journal event.

**Related:** State

---

Stop Hook

A Claude Code hook that intercepts exit attempts during in-session loops. Decides whether to allow exit or continue the loop.

**Location:** generated from plugins/babysitter-unified/hooks/stop.sh

**Output (block):**

{
  "decision": "block",
  "reason": "<prompt>",
  "systemMessage": "Babysitter iteration N"
}

**Related:** In-Session Loop, Hook

---

T

Task

The core primitive for external work in processes. Tasks define what to execute and how to handle results.

**Task Kinds:**

• node - Node.js script
• shell - Shell command
• agent - LLM agent
• skill - Claude Code skill

**Example:**

const result = await ctx.task(buildTask, { target: 'app' });

**Related:** Effect, Task Definition

---

Task Definition

A JavaScript object or function that specifies how to create a task. Defines kind, configuration, and I/O paths.

**Example:**

const buildTask = defineTask('build', (args, ctx) => ({
  kind: 'node',
  title: 'Build project',
  node: { entry: './scripts/build.js' },
  io: {
    inputJsonPath: `tasks/${ctx.effectId}/input.json`,
    outputJsonPath: `tasks/${ctx.effectId}/result.json`
  }
}));

**Related:** Task

---

TDD Quality Convergence

The full name for Babysitter's test-driven development methodology. TDD Quality Convergence combines traditional TDD (writing tests before implementation) with iterative quality improvement until targets are met.

**Process:** 1. Write tests first 2. Implement code to pass tests 3. Measure quality (tests, coverage, lint, security, etc.) 4. Iterate until quality target is achieved

**Shorthand:** "TDD" is acceptable after first mention in a document.

**Related:** Quality Convergence, Methodology

**See Also:** Quality Convergence Guide

---

TDD (Test-Driven Development)

See TDD Quality Convergence.

**Note:** In Babysitter documentation, "TDD" typically refers to the full TDD Quality Convergence methodology, not just traditional test-driven development.

---

Transport Adapter

The Adapter that normalizes provider transports so a harness can speak to a provider it cannot reach natively (used together with the adapters-proxy binary). Paired with Triggers to launch runs from CI.

**Related:** Adapter, Triggers

**See Also:** Adapters

---

Triggers

The v6 mechanism that normalizes inbound webhooks from GitHub, GitLab, and Bitbucket (via the adapters-triggers action) so a run can be launched from CI regardless of provider. Part of the Adapters runtime alongside the Transport Adapter.

**Related:** Transport Adapter, Adapter

**See Also:** GitHub Actions Setup

---

tula

**Deprecated.** Renamed to genty. Use "genty".

---

U

ULID (Universally Unique Lexicographically Sortable Identifier)

A time-sortable unique identifier used for event and effect IDs.

**Example:** 01HJKMNPQR3STUVWXYZ012345

**Related:** Event, Effect ID

---

V

Value

The main output data from a task result. Passed via --value flag when posting results.

**Example:**

$CLI task:post <runId> <effectId> --status ok --value output.json

**Related:** Result, task:post

---

W

Waiting

A run status indicating a blocking effect (breakpoint or sleep) is active. Orchestration pauses until the effect is resolved.

**Related:** Breakpoint, Sleep, Iteration

---

Quick Reference Index

By Category

**Core Concepts:** Run, Process, Journal, Event, Effect, Task, State

**Task Types:** Node Task, Agent Task, Skill Task, Shell Task

**Workflow:** Orchestration Loop, Iteration, Quality Convergence, Breakpoint

**Architecture:** SDK, CLI, Adapter, Adapters CLI, Atlas, Harness, Blueprint, Plugin, Hook, Hooks Adapter, Breakpoints Adapter, Transport Adapter, Triggers, Kradle

**Session Management:** In-Session Loop, Completion Promise, Stop Hook

---

Related Documentation

• CLI Reference - Complete babysitter CLI command documentation
• Adapters CLI Reference - The host-side adapters CLI
• Install Matrix - Supported harnesses and harness keys
• Adapters - The Adapters runtime, Atlas, and Triggers
• Configuration Reference - Environment variables and settings
• FAQ - Frequently asked questions
• Troubleshooting - Common issues and solutions

---

Next steps

• **Next:** Getting Started overview
• **Related:** Two-Loops Architecture, FAQ