| name | cruise-control |
| description | Autonomous development orchestrator that plans, builds, and validates applications |
Cruise-Control Skill
Autonomously orchestrates complete development cycles from high-level prompts through three phases: Plan, Build, and Validate.
Usage
When you need to build an entire application or feature autonomously:
- Provide a high-level prompt describing what to build
- Cruise-control generates a dependency-aware plan using spawn-team ping-pong
- A PR is created for plan approval
- After approval, tasks execute in parallel respecting dependencies
- Finally, the result is audited with functional tests and quality review
Invocation
/cruise-control "Build a sqlite gui interface in rust with jwt authentication"
With options:
/cruise-control --max-parallel 5 "Build microservices architecture"
/cruise-control --auto-approve --test-level strict "Build and test"
Three Phases
Phase 1: Plan
Uses spawn-team in ping-pong mode:
- Primary LLM drafts plan as beads issues
- Reviewer critiques dependencies, identifies gaps
- Primary refines based on feedback
- Iterate until approved or max iterations
Output:
- Beads issues in AISP format (source of truth)
- Markdown plan document (human-readable)
- PR for approval with dependency graph
Phase 2: Build
Uses spawn-team in sequential mode with parallelism:
- Topological sort of tasks by dependencies
- Execute ready tasks up to max_parallel limit
- Create PRs per configured strategy
- Track progress in beads issues
Handles failures by:
- Retrying once with error context
- Marking as blocked if still fails
- Continuing with non-dependent tasks
Phase 3: Validate
Single spawn audits the result:
- Functional tests: Build app, run curl tests
- Plan adherence: Compare implementation to plan
- Quality review: Security, performance, code quality
- Gap analysis: Missing features, improvements needed
Generates comprehensive audit report.
Approval Flow
Plans require GitHub PR approval:
- PR created with plan documents
- Poller checks PR status (1min -> 2min -> 4min -> ... -> 30min max)
- On approval, build phase begins with fresh LLM context
- Use
--auto-approve for tests/CI to skip waiting
Configuration
In .infinite-probability/cruise-control.toml:
[planning]
ping_pong_iterations = 5
[building]
max_parallel = 3
pr_strategy = "per-task"
[validation]
test_level = "functional"
When to Use Cruise-Control
Use cruise-control when:
- Building complete applications from scratch
- Large features requiring multiple coordinated tasks
- You want automated code review at each step
- Testing spawn-team infrastructure end-to-end
Use basic spawn when:
- Single, focused tasks
- Quick fixes or small changes
- You need direct control over execution
Example Workflow
User: /cruise-control "Build a REST API with user auth and data endpoints"
Phase 1 (Plan):
- Generates 8 tasks with dependency graph
- Creates PR #42 with plan
- Waits for approval...
- Approved!
Phase 2 (Build):
- Task 1: Set up project structure ✓
- Task 2: Implement JWT auth ✓
- Task 3: Create database models ✓
- Task 4: Implement user endpoints (depends on 2,3) ✓
- ...
- 8/8 tasks completed
Phase 3 (Validate):
- Build: ✓
- Tests: 12/12 passed
- Quality: 8.5/10
- Findings: 2 warnings (no rate limiting, missing input validation)
Result: SUCCESS
PR: https://github.com/org/repo/pull/50
Report: docs/plans/2026-02-01-api-audit-report.md