Engineering
Valor's merged pull requests over the last 26 weeks, then how each task gets from a request to a merged change.
Source: github.com/valorengels · src/index.js, which draws the chart
SDLC
The stages of a task
The kernel, the deterministic code that runs every task, picks the next stage. The agent decides how to do the work inside one.
- Intake records the request once, verbatim.
- Judge makes one model call: is the request precise or thin?
- Clarify reads the code for a thin request and asks only what the code can't answer, if anything.
- Plan sets the approach, the stakes and the number of rounds.
- Critique: a fresh session reads the plan before any code exists.
- Build makes one candidate commit.
- Checks: test, review and docs run in parallel on that commit, and their findings go back as one patch.
- Merge happens when the merge predicate, the three conditions below, holds.
Any stage can end in stopped, and a task never leaves stopped.
Source: docs/sdlc-state-machine.md · skills/sdlc/
Sessions
Which sessions do the work
The working session
Clarify, plan, build and patch share one resumed session. Valor keeps his context across a question, a send-back from review and feedback from Tom, who built Valor and runs Yudame.
Fresh sessions
Critique, review and docs each start fresh in a worktree of the exact commit they judge. The reviewer runs the suite itself.
Source: core/session.py · core/fresh.py
Loops
Critique and review rounds
- A small reversible change in well-tested code gets no extra rounds.
- A change to stored data, money, authentication, migrations or the kernel gets two critique rounds and one review round.
- Critique can raise these counts but never lower them.
- When the rounds are spent, Valor patches once more or stops. If that candidate fails too, the task ends and Tom gets one report.
Merge
The merge predicate
- One current candidate, its checks decided.
- Test passed, or showed only breadth gaps with the rounds spent.
- Review passed.
- The broker, the one component that performs effects, reads the predicate in the same transaction that writes the request to merge.
- The target repository and branch are fixed when the task starts. No turn can change them.
- If the branch has moved and the work replays cleanly onto it, the kernel replays it without a turn. Otherwise the work goes back for a rebase.
Source: core/machine.py · core/broker.py
Skills
The pipeline stages as developer skills
The yudame/skills repository holds the team's Claude Code plugins. Each of Valor's machines installs its yudame and yudame-dev plugins, and each of Valor's turns loads them, so Valor and a developer use the same skills.
Its do-* skills are the developer's version of the pipeline. Valor's own stage instructions live in skills/sdlc/, and the kernel runs its test and merge stages itself. The stages line up like this:
| Stage | Skill |
|---|---|
| Plan | do-plan |
| Critique | do-plan-critique |
| Build | do-build |
| Test | do-test |
| Review | do-pr-review |
| Docs | do-docs |
| Patch | do-patch |
| Merge | do-merge |
Two more have no matching stage. do-issue files the GitHub issue a developer starts from, and do-sdlc runs the stage skills one after another, from an issue to a merged pull request.
Source: github.com/yudame/skills · docs/rollout.md · docs/harnesses.md