Drive a change to green
The interactive REPL is great for exploring. When you already know what “done” looks like, hand tsforge a task and a check, and it drives the change until the check passes, then exits.
tsforge "add input validation to the signup route" --accept "bun test"--accept is any shell command. tsforge runs the model, applies edits, runs the check, feeds the failures back, and repeats until the command exits 0 or it stops making progress. The exit code is the check’s, so it drops straight into scripts and CI.
Why this is the safe way to delegate
Section titled “Why this is the safe way to delegate”The check is the contract. The model doesn’t decide it’s finished; your command does. With --accept "bun test", “done” means your tests pass. With --accept "tsc --noEmit && bun test", it means types and tests pass. Underneath, tsforge layers its own strict gate (strict tsc, ESLint, and tests by default), so green reflects the compiler, the linter, and your tests all agreeing, not the model’s say-so.
Choosing a good check
Section titled “Choosing a good check”| Goal | --accept |
|---|---|
| Make the suite pass | bun test |
| Types and tests | tsc --noEmit && bun test |
| One file’s tests (fast loop) | bun test src/auth.test.ts |
| Lint clean too | bun test && bun run lint |
If it can’t get there, it stops with a clear status instead of churning forever. See When the gate fails.
Scoping the edits
Section titled “Scoping the edits”By default the whole repo is editable. To fence the agent in, narrow it:
tsforge "refactor the parser" --files "src/parser/**" --accept "bun test"Anything outside --files is read-only, a tripwire rather than a requirement.