| name | salazar |
| description | Autonomous coding orchestrator -- builds software from specs via planner/generator/evaluator agent loop. Use for greenfield TS/Node projects or large refactors. |
Salazar -- Autonomous Coding Orchestrator
Salazar builds software end-to-end from a markdown spec. It decomposes specs into features, implements each feature in its own Claude Code session with TDD, gates every feature through hard validators (tsc, eslint, build, test), and optionally scores moderate/complex features with an evaluator agent.
When to Use Salazar
Use Salazar when the task is large enough that autonomous execution saves real time:
- Greenfield projects -- new modules, new packages, new services built from scratch
- Large refactors touching 5+ files with behavioral changes
- Building from a written spec -- markdown product spec to working code
- When you want TDD with validator gates -- tsc, lint, build, and test must all pass before a feature is accepted
When NOT to Use Salazar
Do not use Salazar for small, obvious, or fast tasks:
- Quick single-file fixes or patches
- Bug fixes where the fix is obvious
- Config changes, dependency updates
- Anything you can do in under 5 minutes manually
- Adding features to an existing codebase (brownfield -- not yet supported)
Key Constraint
Salazar currently supports greenfield TypeScript/Node projects only. It does not support brownfield mode (adding features to existing codebases) yet.
How to Invoke
salazar run <spec.md> --output-dir <target-directory>
salazar run <spec.md> --model claude-sonnet-4-6 --model-evaluator claude-opus-4-6
salazar
Writing a Good Spec for Salazar
The quality of the spec directly determines the quality of the output. Follow these guidelines:
- Use markdown format with clear feature descriptions
- Make each feature independently implementable -- avoid features that can only work if another unfinished feature exists
- Include acceptance criteria or BDD scenarios where possible (Given/When/Then)
- Keep it focused -- one project per spec
- Salazar scales: 10-30 features for tiny libs, 50-150 for medium SDKs
Spec Structure Example
# My Library
## Overview
One paragraph describing what this library does and who it's for.
## Features
### F1: Core Data Model
Description of the data model.
**Acceptance criteria:**
- Given X, when Y, then Z
- Handles edge case A
### F2: API Client
Description of the API client.
**Acceptance criteria:**
- Connects to endpoint and returns typed response
- Retries on 5xx errors with exponential backoff
What Salazar Does (Under the Hood)
- Planner decomposes spec into features with BDD scenarios and dependency ordering
- Generator implements one feature per Claude Code session using TDD
- Hard validators gate every feature -- tsc, eslint, build, and test must all pass
- Evaluator scores moderate/complex features (minimum 7.0/10 to pass)
- Git commits each passing feature automatically
Failed features are retried with validator feedback. The evaluator provides structured feedback on code quality, test coverage, and spec adherence.
Cost and Time Expectations
| Project Size | Features | Time | Estimated Cost |
|---|
| Small lib | ~15 | ~30 min | $5-10 |
| Medium SDK | ~50 | ~2 hours | $15-30 |
| Large system | ~150 | ~6 hours | $50-80 |
Costs depend on model selection. Using claude-sonnet-4-6 for generation and claude-opus-4-6 for evaluation is the recommended balance of speed and quality.
Decision Checklist
Before invoking Salazar, confirm:
