process-builder

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

Jump to install

Repository: a5c-ai/babysitter
Last source activity: June 2, 2026 at 20:47
Detected SKILL.md language: English
Stars: 1,652
Forks: 96

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

A direct command skips the review prompt. Inspect the source before running it.

npx skills add https://github.com/a5c-ai/babysitter --skill process-builder

The command stays on one line. Scroll horizontally to inspect it before copying.

Prefer a local copy? Download the files currently available to SkillsMP.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

SKILL.md

Source instructions · Read-only preview

Back to search Back to installation

atlas-graph-query

Reference for querying the Atlas knowledge graph through its MCP tools — the SECONDARY enrichment/comparison layer that adds best-practice context to systems you have ALREADY scanned from your real sources (`az`, repos, dirs). Use when you need to look up nodes, edges, kinds, clusters, stats, or wiki pages in Atlas to compare against your real inventory. (atlas graph, query atlas, atlas mcp, search the graph, graph neighbors, atlas record, atlas kinds, enrichment layer)

2026-06-12

atlas

Atlas turns your STATED NEED into a real systems atlas by SCANNING your actual sources (Azure via `az`, git repos, local dirs) and process/data mining them, THEN enriching against the Atlas knowledge graph. Use this skill when asked to inventory/map your real systems, scan your cloud + repos + directories, mine the real processes or data they contain, or collect their real constraints/gotchas. (atlas, scan my systems, inventory our azure account, map my repos, real systems atlas, process mining, data mining, collect nuances, system discovery)

2026-06-12

assimilate-popular-workflows

This skill should be used when the user asks to "find skills in the wild", "assimilate popular workflows", "discover SKILL.md files in repos", "research external skills", "find workflow patterns", "survey the skill landscape", "what skills exist out there", or wants to investigate public repositories for extractable processes, babysitter plugins, and reusable procedural insights. Searches GitHub for SKILL.md files, classifies repos by archetype, and maintains structured research under docs/reference-repos/.

2026-06-07

View all from this repository

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 - [ ] - Short description of what this process accomplishes Reference: [Link to methodology or standard] Inputs: list key inputs Outputs: list key outputs [ ] - Description ...

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

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

 [ ]  - Description
  ...

/** * @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.log?.('info', 'Starting Phase 1...'); const phase1Result = await ctx.task(someTask, { // task inputs }); artifacts.push(...(phase1Result.artifacts || [])); // Breakpoint for human review (when needed) await ctx.breakpoint({ question: 'Review the results and approve to continue?', title: 'Phase 1 Review', context: { runId: ctx.runId, files: [ { path: 'artifacts/output.md', format: 'markdown', label: 'Output' } ] } }); // ============================================================================ // PHASE 2: [PHASE NAME] - Parallel Execution Example // ============================================================================ const [result1, result2, result3] = await ctx.parallel.all([ () => ctx.task(task1, { /* args */ }), () => ctx.task(task2, { /* args */ }), () => ctx.task(task3, { /* args */ }) ]); // ============================================================================ // PHASE 3: [ITERATION EXAMPLE] // ============================================================================ let iteration = 0; let targetMet = false; while (!targetMet && iteration < maxIterations) { iteration++; const iterResult = await ctx.task(iterativeTask, { iteration, previousResults: /* ... */ }); targetMet = iterResult.meetsTarget; if (!targetMet && iteration % 3 === 0) { // Periodic checkpoint await ctx.breakpoint({ question: `Iteration ${iteration}: Target not met. Continue?`, title: 'Progress Checkpoint', context: { /* ... */ } }); } } // ============================================================================ // COMPLETION // ============================================================================ return { success: targetMet, iterations: iteration, artifacts, // ... other outputs matching @outputs }; } // ============================================================================ // TASK DEFINITIONS // ============================================================================ /** * Task: [Task Name] * Purpose: What this task accomplishes */ const someTask = defineTask({ name: 'task-name', description: 'What this task does', // Task definition - executed externally by orchestrator // This returns a TaskDef that describes HOW to run the task inputs: { inputName: { type: 'string', required: true }, optionalInput: { type: 'number', default: 10 } }, outputs: { result: { type: 'object' }, artifacts: { type: 'array' } }, async run(inputs, taskCtx) { const effectId = taskCtx.effectId; return { kind: 'node', // or 'agent', 'skill', 'shell', 'breakpoint' title: `Task: ${inputs.inputName}`, node: { entry: 'scripts/task-runner.js', args: ['--input', inputs.inputName, '--effect-id', effectId] }, io: { inputJsonPath: `tasks/${effectId}/input.json`, outputJsonPath: `tasks/${effectId}/result.json` }, labels: ['category', 'subcategory'] }; } });

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

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

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?

process-builder

Source facts

Install options

Review the source files

More from this repository

Process Builder

Quick Reference

3-Phase Workflow

Phase 1: Research & Documentation

Phase 2: Identify Processes

Process Builder

Quick Reference

3-Phase Workflow

Phase 1: Research & Documentation

Phase 2: Identify Processes

Phase 3: Create Process Files

Process File Structure

SDK Context API Reference

Task Kinds

Breakpoint Patterns

Basic Approval Gate

With File References (for UI display)

Conditional Breakpoint

Common Patterns

Quality Convergence Loop

Phased Workflow with Reviews

Parallel Fan-out with Aggregation

Testing Processes

CLI Commands

Sample Test Input File

Process Builder Workflow

1. Gather Requirements

2. Research Similar Processes

3. Check Methodologies Backlog

4. Create the Process

5. Validate Structure

Examples by Type

Methodology Process (atdd-tdd style)

Specialization Process (game-development style)

Domain Process (science/research style)

Atlas Graph Metadata

Format

How to choose node IDs

Why this matters

Resources

More from this repository