cestDone — Summary

cestDone is a TypeScript CLI that implements a director+coder split: a thin Director AI orchestrates through markdown files while Worker AIs execute in fresh sessions with only task-relevant context per phase. Given a plain-text spec file, the CLI spawns a Planning Worker to explore the codebase and write a .plan.md, then iterates through each plan phase by spawning a fresh Worker that implements the phase and writes a report, after which the Director reviews the report and code diff and decides to commit, retry, or escalate to the human. The Director never reads code directly — it sees only Worker reports and git diffs — keeping its context lean across long projects. Two backends are supported: the Claude CLI (using a Max/Pro subscription via claude -p, no per-token billing) and the Anthropic Agent SDK (API key). The two backends can be mixed per agent. Compared to seeds, cestDone is closest to BMAD-METHOD's director+specialist split, but with a key inversion: BMAD injects personas into a single Claude Code session, whereas cestDone uses separate OS processes per phase with file-based handoffs, achieving context isolation rather than persona management. Unlike claude-conductor's passive markdown scaffolding, cestDone actively spawns and supervises subprocesses.

cestDone — Overview

Origin

cestDone was built by olkano (single contributor). Version 0.1.0, TypeScript. Repository has 2 stars. Last pushed 2026-05-19.

Philosophy

From the README:

"The bottleneck in AI-assisted development isn't the AI — it's the human sitting between the planner and the worker. You paste context, copy instructions, re-explain what was already decided, and babysit every step. cestDone removes that bottleneck."

On context exhaustion:

"There's a second, subtler problem: context window exhaustion. When you drive an AI agent manually through a large project, the conversation fills up — the model forgets earlier decisions, loses track of files, and quality degrades. cestDone sidesteps this by keeping the Director thin — it orchestrates via markdown files and never does deep code analysis itself. Workers get fresh sessions per task with only the relevant context."

Key Design Opinions

• Director is thin: The Director never reads code directly; it only reads Worker reports and git diffs. This keeps its context stable across a long project.
• Workers are ephemeral: Each Worker gets a fresh process session with only the phase-specific context. No cross-phase contamination.
• File-based communication: All Director↔Worker handoffs happen through .cestdone/reports/ markdown files — fully human-readable and debuggable.
• Subscription-first: The Claude CLI backend uses a Max/Pro subscription (claude -p), avoiding per-token API billing.
• Human opt-in only: The human only intervenes when explicitly requested (e.g., plan approval with --with-human-validation, or after 3 Worker retry failures).

Daemon Mode

cestDone also supports a daemon (cestdone daemon) with schedule- and trigger-based execution from a .cestdonerc.json config file.

cestDone — Architecture

Distribution & Install

• Distribution type: npm-package (local build, npm link)
• Install: npm install && npm run build && npm link (from repo)
• Binary name: cestdone
• Version: 0.1.0
• License: MIT (implied)
• Required runtime: node>=22.0.0

Directory Tree (repo)

cestDone/
├── src/
│   ├── cli/            # CLI entry point (commander)
│   ├── director/       # Director orchestration logic
│   ├── worker/         # Worker execution logic
│   ├── backends/       # Claude CLI and Agent SDK backends
│   ├── daemon/         # Daemon mode (scheduler)
│   ├── email/          # Email tool for Worker agents
│   └── shared/         # Shared types and utilities
├── .claude/            # Claude Code context
├── .cestdone/          # Project config and reports
│   └── reports/        # Phase prompt/report files
├── .cestdonerc.example.json  # Daemon config template
├── zz_Specifications/  # Project spec documents
├── zz_Tickets/         # Feature tickets
└── package.json

Two-Agent Architecture

spec.md → DIRECTOR → Planning Worker → .plan.md
                  ↓
           For each phase:
              WORKER (fresh session)
              ├─ Reads phase spec from .plan.md
              ├─ Implements: edit files, run tests
              └─ Writes report to .cestdone/reports/phase-N-report.md
                  ↓
              DIRECTOR (review)
              ├─ Reads report + git diff
              ├─ fix → retry Worker (max 3, then human)
              ├─ continue → Worker keeps going
              └─ done → commit, update plan

Two Backends

Backends can be mixed: --director-backend cli --worker-backend agent-sdk

Target AI Tools

• Claude (primary, both CLI and API)
• No other AI tools are explicitly supported

cestDone — Components

CLI Commands

CLI Options for run

File-Based Communication Artifacts

Daemon Configuration

.cestdonerc.json (example format):

• Schedule-based runs (cron-style)
• Trigger-based runs (e.g., on file change)
• Per-spec director/worker model configuration

Subagent Roles

1. Planning Worker — explores codebase, writes .plan.md with numbered phases
2. Phase Worker(s) — one per phase; fresh session; implements one phase
3. Director — orchestrates; reads reports and diffs; decides next action

Modes

• Two-agent mode (default): Director + Workers; Director never reads code directly
• Director-only mode (--no-with-worker): Director does everything in one session

cestDone — Uniqueness & Positioning

Differs from Seeds

cestDone is closest to BMAD-METHOD's director+specialist split, but inverts the implementation: BMAD injects persona instructions into a single ongoing Claude Code session via skill files, while cestDone uses separate OS processes per phase, achieving true context isolation rather than persona management. The thin-Director / fresh-Worker pattern solves context exhaustion structurally (by never letting the Director read code) rather than through compaction strategies like claude-flow's or claude-conductor's. Unlike spec-driver's sequential skill chain (which is a single-session instruction sequence), cestDone genuinely produces independent agent processes. The --backend agent-sdk option and per-agent model selection (Opus Director + Sonnet Worker) make it the only framework in this batch with explicit cost-optimization through model tier routing that is built into the CLI flags. The daemon mode with .cestdonerc.json is also unique — no seed framework supports scheduled autonomous execution.

Positioning

cestDone targets developers running large, multi-phase projects where a single Claude context window would exhaust before completion. The subscription-first billing model (Claude CLI, no per-token charge) and per-process session isolation are explicit answers to the two failure modes of prolonged agentic workflows: context exhaustion and API cost overrun.

Observable Failure Modes

• Worker 3-retry escalation: If a Worker fails 3 times on the same phase, the human must intervene. There is no alternative recovery strategy (e.g., breaking the phase into sub-phases).
• Plan format sensitivity: If the Planning Worker produces a malformed .plan.md, a revision Worker is invoked, but if revision also fails, the pipeline blocks.
• Director review accuracy: The Director reviews only reports and diffs, not code. A Worker that produces plausible-looking reports but broken code can advance phases.
• No parallel execution: Phases are strictly sequential. Large projects with parallelizable work cannot exploit multiple Workers concurrently.
• npm-link-only distribution: No npm registry package; installation requires cloning the repo and building locally.

Explicit Antipatterns (from README philosophy)

• Human sitting between planner and worker (removing this is the goal)
• Single-session agents that accumulate context until quality degrades
• Director reading code directly (kept thin for context stability)