process-builder

name	process-builder
description	Scaffold new babysitter process definitions following SDK patterns, proper structure, and best practices. Guides the 3-phase workflow from research to implementation.

Process Builder

Create new process definitions for the babysitter event-sourced orchestration framework.

Quick Reference

Processes live in: library/
├── methodologies/          # Reusable development approaches (TDD, BDD, Scrum, etc.)
│   └── [name]/
│       ├── README.md       # Documentation
│       ├── [name].js       # Main process
│       └── examples/       # Sample inputs
│
└── specializations/        # Domain-specific processes
    ├── [category]/         # Engineering specializations (direct children)
    │   └── [process].js
    └── domains/
        └── [domain]/       # Business, Science, Social Sciences
            └── [spec]/
                ├── README.md
                ├── references.md
                ├── processes-backlog.md
                └── [process].js

3-Phase Workflow

Phase 1: Research & Documentation

Create foundational documentation:

# Check existing specializations
ls library/specializations/

# Check methodologies
ls library/methodologies/

Create:

• README.md - Overview, roles, goals, use cases, common flows
• references.md - External references, best practices, links to sources

Phase 2: Identify Processes

Create processes-backlog.md with identified processes:

# Processes Backlog - [Specialization Name]

## Identified Processes

- [ ] **process-name** - Short description of what this process accomplishes
  - Reference: [Link to methodology or standard]
  - Inputs: list key inputs
  - Outputs: list key outputs

- [ ] **another-process** - Description
  ...

Phase 3: Create Process Files

Create .js process files following SDK patterns (see below).

---

Process File Structure

Every process file follows this pattern:

/**
 * @process [category]/[process-name]
 * @description Clear description of what the process accomplishes end-to-end
 * @inputs { inputName: type, optionalInput?: type }
 * @outputs { success: boolean, outputName: type, artifacts: array }
 *
 * @graph
 *   domains: [domain:software-engineering]
 *   skillAreas: [skill-area:your-skill-area]
 *   topics: [topic:your-topic]
 *   roles: [role:your-role]
 *   workflows: [workflow:your-workflow]
 *
 * @example
 * const result = await orchestrate('[category]/[process-name]', {
 *   inputName: 'value',
 *   optionalInput: 'optional-value'
 * });
 *
 * @references
 * - Book: "Relevant Book Title" by Author
 * - Article: [Title](https://link)
 * - Standard: ISO/IEEE reference
 */

import { defineTask } from '@a5c-ai/babysitter-sdk';

/**
 * [Process Name] Process
 *
 * Methodology: Brief description of the approach
 *
 * Phases:
 * 1. Phase Name - What happens
 * 2. Phase Name - What happens
 * ...
 *
 * Benefits:
 * - Benefit 1
 * - Benefit 2
 *
 * @param {Object} inputs - Process inputs
 * @param {string} inputs.inputName - Description of input
 * @param {Object} ctx - Process context (see SDK)
 * @returns {Promise<Object>} Process result
 */
export async function process(inputs, ctx) {
  const {
    inputName,
    optionalInput = 'default-value',
    // ... destructure with defaults
  } = inputs;

  const artifacts = [];

  // ============================================================================
  // PHASE 1: [PHASE NAME]
  // ============================================================================

  ctx.?.(, );

   phase1Result =  ctx.(someTask, {
    
  });

  artifacts.(...(phase1Result. || []));

  
   ctx.({
    : ,
    : ,
    : {
      : ctx.,
      : [
        { : , : , :  }
      ]
    }
  });

  
  
  

   [result1, result2, result3] =  ctx..([
     ctx.(task1, {  }),
     ctx.(task2, {  }),
     ctx.(task3, {  })
  ]);

  
  
  

   iteration = ;
   targetMet = ;

   (!targetMet && iteration < maxIterations) {
    iteration++;

     iterResult =  ctx.(iterativeTask, {
      iteration,
      : 
    });

    targetMet = iterResult.;

     (!targetMet && iteration %  === ) {
      
       ctx.({
        : ,
        : ,
        : {  }
      });
    }
  }

  
  
  

   {
    : targetMet,
    : iteration,
    artifacts,
    
  };
}






 someTask = ({
  : ,
  : ,

  
  

  : {
    : { : , :  },
    : { : , :  }
  },

  : {
    : { :  },
    : { :  }
  },

   () {
     effectId = taskCtx.;

     {
      : ,  
      : ,
      : {
        : ,
        : [, inputs., , effectId]
      },
      : {
        : ,
        : 
      },
      : [, ]
    };
  }
});

---

SDK Context API Reference

The ctx object provides these intrinsics:

Method	Purpose	Behavior
ctx.task(taskDef, args, opts?)	Execute a task	Returns result or throws typed exception
ctx.breakpoint(payload)	Human approval gate	Pauses until approved via human
ctx.sleepUntil(isoOrEpochMs)	Time-based gate	Pauses until specified time
ctx.parallel.all([...thunks])	Parallel execution	Runs independent tasks concurrently
ctx.parallel.map(items, fn)	Parallel map	Maps items through task function
ctx.now()	Deterministic time	Returns current Date (or provided time)
ctx.log?.(level, msg, data?)	Logging	Optional logging helper
ctx.runId	Run identifier	Current run's unique ID

Task Kinds

Kind	Use Case	Executor
node	Scripts, builds, tests	Node.js process
agent	LLM-powered analysis, generation	Claude Code agent
skill	Claude Code skills	Skill invocation
shell	System commands	Shell execution
breakpoint	Human approval	Breakpoints UI/service
sleep	Time gates	Orchestrator scheduling
orchestrator_task	Internal orchestrator work	Self-routed

---

Breakpoint Patterns

Basic Approval Gate

await ctx.breakpoint({
  question: 'Approve to continue?',
  title: 'Checkpoint',
  context: { runId: ctx.runId }
});

With File References (for UI display)

await ctx.breakpoint({
  question: 'Review the generated specification. Does it meet requirements?',
  title: 'Specification Review',
  context: {
    runId: ctx.runId,
    files: [
      { path: 'artifacts/spec.md', format: 'markdown', label: 'Specification' },
      { path: 'artifacts/spec.json', format: 'json', label: 'JSON Schema' },
      { path: 'src/implementation.ts', format: 'code', language: 'typescript', label: 'Implementation' }
    ]
  }
});

Conditional Breakpoint

if (qualityScore < targetScore) {
  await ctx.breakpoint({
    question: `Quality score ${qualityScore} is below target ${targetScore}. Continue iterating or accept current result?`,
    title: 'Quality Gate',
    context: {
      runId: ctx.runId,
      data: { qualityScore, targetScore, iteration }
    }
  });
}

---

Common Patterns

Quality Convergence Loop

let quality = 0;
let iteration = 0;
const targetQuality = inputs.targetQuality || 85;
const maxIterations = inputs.maxIterations || 10;

while (quality < targetQuality && iteration < maxIterations) {
  iteration++;
  ctx.log?.('info', `Iteration ${iteration}/${maxIterations}`);

  // Execute improvement tasks
  const improvement = await ctx.task(improveTask, { iteration });

  // Score quality (parallel checks)
  const [coverage, lint, security, tests] = await ctx.parallel.all([
    () => ctx.task(coverageTask, {}),
    () => ctx.task(lintTask, {}),
    () => ctx.task(securityTask, {}),
    () => ctx.task(runTestsTask, {})
  ]);

  // Agent scores overall quality
  const score = await ctx.task(agentScoringTask, {
    coverage, lint, security, tests, iteration
  });

  quality = score.overall;
  ctx.log?.('info', `Quality: ${quality}/${targetQuality}`);

  if (quality >= targetQuality) {
    ctx.log?.('info', );
    ;
  }
}

 {
  : quality >= targetQuality,
  quality,
  : iteration
};

Phased Workflow with Reviews

// Phase 1: Research
const research = await ctx.task(researchTask, { topic: inputs.topic });

await ctx.breakpoint({
  question: 'Review research findings before proceeding to planning.',
  title: 'Research Review',
  context: { runId: ctx.runId }
});

// Phase 2: Planning
const plan = await ctx.task(planningTask, { research });

await ctx.breakpoint({
  question: 'Review plan before implementation.',
  title: 'Plan Review',
  context: { runId: ctx.runId }
});

// Phase 3: Implementation
const implementation = await ctx.task(implementTask, { plan });

// Phase 4: Verification
const verification = await ctx.task(verifyTask, { implementation, plan });

await ctx.breakpoint({
  question: 'Final review before completion.',
  title: 'Final Approval',
  context: { runId: ctx.runId }
});

return { success: verification.passed, plan, implementation };

Parallel Fan-out with Aggregation

// Fan out to multiple parallel analyses
const analyses = await ctx.parallel.map(components, component =>
  ctx.task(analyzeTask, { component }, { label: `analyze:${component.name}` })
);

// Aggregate results
const aggregated = await ctx.task(aggregateTask, { analyses });

return { analyses, summary: aggregated.summary };

---

Testing Processes

CLI Commands

# Create a new run
babysitter run:create \
  --process-id methodologies/my-process \
  --entry ./library/methodologies/my-process.js#process \
  --inputs ./test-inputs.json \
  --json

# Iterate the run
babysitter run:iterate .a5c/runs/<runId> --json

# List pending tasks
babysitter task:list .a5c/runs/<runId> --pending --json

# Post a task result
babysitter task:post .a5c/runs/<runId> <effectId> \
  --status ok \
  --value ./result.json

# Check run status
babysitter run:status .a5c/runs/<runId>

# View events
babysitter run:events .a5c/runs/<runId> --limit 20 --reverse

Sample Test Input File

{
  "feature": "User authentication with JWT",
  "acceptanceCriteria": [
    "Users can register with email and password",
    "Users can login and receive a JWT token",
    "Invalid credentials are rejected"
  ],
  "testFramework": "jest",
  "targetQuality": 85,
  "maxIterations": 5
}

---

Process Builder Workflow

1. Gather Requirements

Ask the user:

Question	Purpose
Domain/Category	Determines directory location
Process Name	kebab-case identifier
Goal	What should the process accomplish?
Inputs	What data does the process need?
Outputs	What artifacts/results does it produce?
Phases	What are the major steps?
Quality Gates	Where should humans review?
Iteration Strategy	Fixed phases vs. convergence loop?

2. Research Similar Processes

# Find similar processes
ls library/methodologies/
ls library/specializations/

# Read similar process for patterns
cat library/methodologies/atdd-tdd/atdd-tdd.js | head -200

# Check methodology README structure
cat library/methodologies/atdd-tdd/README.md

3. Check Methodologies Backlog

cat library/methodologies/backlog.md

4. Create the Process

For Methodologies:

1. Create methodologies/[name]/README.md (comprehensive documentation)
2. Create methodologies/[name]/[name].js (process implementation)
3. Create methodologies/[name]/examples/ (sample inputs)

For Specializations:

1. If domain-specific: specializations/domains/[domain]/[spec]/
2. If engineering: specializations/[category]/[process].js
3. Create README.md, references.md, processes-backlog.md first
4. Then create individual process.js files

5. Validate Structure

Checklist:

• JSDoc header with @process, @description, @inputs, @outputs, @example, @references
• @graph block with relevant atlas node IDs (at minimum one domain)
• Import from @a5c-ai/babysitter-sdk
• Main export async function process(inputs, ctx)
• Input destructuring with defaults
• Clear phase comments (// === PHASE N: NAME ===)
• Logging via ctx.log?.('info', message)
• Tasks via ctx.task(taskDef, inputs)
• Breakpoints at key decision points
• Artifact collection throughout
• Return object matches @outputs schema

---

Examples by Type

Methodology Process (atdd-tdd style)

/**
 * @process methodologies/my-methodology
 * @description My development methodology with quality convergence
 * @inputs { feature: string, targetQuality?: number }
 * @outputs { success: boolean, quality: number, artifacts: array }
 */
export async function process(inputs, ctx) {
  const { feature, targetQuality = 85 } = inputs;
  // ... implementation
}

Specialization Process (game-development style)

/**
 * @process specializations/game-development/core-mechanics-prototyping
 * @description Prototype and validate core gameplay mechanics through iteration
 * @inputs { prototypeName: string, mechanicsToTest: array, engine?: string }
 * @outputs { success: boolean, mechanicsValidated: array, playtestResults: object }
 */
export async function process(inputs, ctx) {
  const { prototypeName, mechanicsToTest, engine = 'Unity' } = inputs;
  // ... implementation
}

Domain Process (science/research style)

/**
 * @process specializations/domains/science/bioinformatics/sequence-analysis
 * @description Analyze genomic sequences using standard bioinformatics workflows
 * @inputs { sequences: array, analysisType: string, referenceGenome?: string }
 * @outputs { success: boolean, alignments: array, variants: array, report: object }
 */
export async function process(inputs, ctx) {
  const { sequences, analysisType, referenceGenome = 'GRCh38' } = inputs;
  // ... implementation
}

---

Atlas Graph Metadata

Every generated process file MUST include a @graph JSDoc block in its file header comment alongside the standard @process, @description, @inputs, and @outputs tags.

Format

/**
 * @process specializations/my-domain/my-process
 * @description ...
 * @inputs { ... }
 * @outputs { ... }
 *
 * @graph
 *   domains: [domain:software-engineering, domain:devops]
 *   skillAreas: [skill-area:caching-strategies]
 *   topics: [topic:microservices, topic:event-sourcing]
 *   roles: [role:backend-engineer, role:sre]
 *   workflows: [workflow:code-review]
 */

How to choose node IDs

Read the atlas graph domain directory (packages/atlas/graph/domain/) to find valid node IDs. The directory contains YAML files grouped by category:

• domains/ — high-level domain nodes (e.g. domain:software-engineering, domain:devops, domain:data-engineering)
• skill-areas/ — specific skill area nodes
• topics/ — granular topic nodes
• roles/ — role nodes (engineers, practitioners, researchers)
• workflows/ — workflow nodes

Pick 2–4 edges that genuinely relate to the process. Do not guess IDs — read the actual YAML files to find valid ones. At minimum, every process must reference at least one domain: node.

Why this matters

This metadata connects the process to the atlas knowledge graph. A pre-build generator script parses the @graph block and creates graph nodes and edges for discoverability. Processes without this block will not appear in graph-based search results or recommendations.

---

Resources

• SDK Reference: library/reference/sdk.md
• Methodology Backlog: library/methodologies/backlog.md
• Specializations Backlog: library/specializations/backlog.md
• Example: ATDD/TDD: library/methodologies/atdd-tdd/
• Example: Spec-Driven: library/methodologies/spec-driven-development.js
• README: Root README.md for full framework documentation