Skip to content

glossary.md

Latest commit

 

History

History
1261 lines (798 loc) · 37.8 KB

glossary.md

File metadata and controls

1261 lines (798 loc) · 37.8 KB
Raw

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:

Term Plain English Example
Run One execution of a workflow "I started a run to build my feature"
Process A reusable workflow template "The TDD process writes tests first"
Iteration One try-and-improve cycle "It took 3 iterations to pass all tests"
Quality Gate A check that must pass "The tests are a quality gate"
Breakpoint A pause for your approval "It stopped at a breakpoint for me to review"
Journal A record of everything that happened "I can see in the journal what the AI did"
Task A single unit of work "The 'run tests' task checks if tests pass"
Effect Something the AI wants to do "The effect was to create a file"
Convergence Getting better until target met "Quality converged from 60% to 95%"
Artifact A file created during the run "The plan.md artifact shows the AI's plan"

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

On this page

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):

Methodology Description Source
TDD Quality Convergence Test-first development with iterative quality improvement library/tdd-quality-convergence.js
GSD (Get Stuff Done) Rapid, pragmatic 8-phase execution gsd/
Spec-Kit Specification-driven development with governance spec-kit/
ATDD/TDD Acceptance test-driven and test-driven development atdd-tdd/
BDD/Specification by Example Behavior-driven development with Gherkin bdd-specification-by-example/
Domain-Driven Design Strategic and tactical DDD patterns domain-driven-design/
Feature-Driven Development Feature-centric with parking lot tracking feature-driven-development/
Hypothesis-Driven Development Experimentation and validation framework hypothesis-driven-development/
Example Mapping BDD workshop technique for requirements example-mapping/
Scrum Sprint-based iterative development scrum/
Kanban Pull-based system with WIP limits kanban/

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.

Babysitter currently exposes 2,243 JavaScript process files in the live repository tree organized across methodologies, shared processes, and specializations.

Domain Processes Browse
Development and technical specializations 840 Browse →
Business domains 490 Browse →
Science & engineering domains 551 Browse →
Social sciences & humanities 160 Browse →

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

Next steps