Workflow model
Zimster keeps one implementation owner in charge of the change. Planning, TDD, debugging, review, and completion are separate steps, but they are not separate agents unless there is a useful reason for that split.
Profiles
The workflow depth changes with the risk.
- Micro: small, coherent, low-risk work.
- Standard: ordinary subsystem work that needs focused verification and a review at the important seam.
- High risk: public compatibility, security, migrations, concurrency ownership, and other load-bearing changes.
Skill set
The twelve core skills cover planning, owner-driven development, TDD, parallel agents, debugging, review, verification, worktrees, and branch finishing.
The set is intentionally compact. The point is to cover recurring work clearly, not to create a role for every possible activity.
Package surfaces
Zimster currently ships Codex, Claude-oriented, and portable release packages. The structure is intended to support several coding-agent environments while keeping the same workflow principles.
Proof model
Zimster keeps these states separate:
- Self-review: what the implementation owner checked.
- Checkout integrity: whether the reviewed checkout changed during review.
- Semantic approval: whether the independent reviewer approved the exact candidate.
- Candidate completion: whether the final proof gate was satisfied.
A clean checkout is useful information, but it is not the same thing as proof that the implementation is correct.