Simple.
Repository truth for coding agents: the smallest truthful design, and plain developer writing.
The Raptor test
Necessary complexity moves inward. Raptor 3 internalised flow paths and cooling, so exposed plumbing, shielding and supporting hardware could be removed.
MacBook unibody
One machined enclosure replaced many structural parts, seams and supports.
Apple, 2008
Two modes
Design mode decides architecture, ownership, compatibility, migration, deletion and refactoring against the facts in the nearest SIMPLE.md. Writing mode produces plans, documentation, comments, prompts, reviews and handoffs in plain Markdown. Both start with reality, follow the ordinary path, then prove the result.
- 01
Users, promises, data, consequences.
- 02
One owner. One route. One missing capability.
- 03
Observe behaviour outside the implementation.
The implementation ladder
Design mode stops at the first rung that is sufficient: remove the need, reuse the owner, reuse code already here, the standard library, a native platform feature, a dependency already installed, direct code. New machinery is the last rung, not the first.
Some things are floors rather than candidates: validation at trust boundaries, error handling that prevents data loss, security, accessibility, and the recovery or audit obligations a repository actually has. The profile’s preserved knowledge outranks minimalism.
Commands
Seven entry points into one method. All are read-only except init, which writes routing and profile files, and write, which writes only the requested text.
simple init
Routing files and an incomplete profile.
simple audit
Split ownership and unpaid complexity.
simple plan
The smallest change the repository can justify.
simple review
Claims tested against repository facts.
simple write
Plans, documentation and handoffs in plain Markdown.
simple emulate
A sourced doctrine argued against the decision.
simple check
Routing and profile shape.
Operator emulation
Emulation takes a documented decision doctrine, never a persona. Three lenses ship with it: SpaceX’s five-step engineering process, a scoped Theo/T3 web-product lens, and a minimal-implementation lens informed by the open-source Ponytail project. Each names its sources and its blind spots, and the result is a hypothesis to test against repository facts, not evidence about users or runtime.
Evals
Seventeen cases pair a task, repository facts and a pass/fail rubric.
View the cases and resultsOne paired run, reported in full
22 August 2026, claude-sonnet-5, real headless Claude Code sessions, one per task. Nine graded runs across five of the hardest cases, with user-scope hooks excluded so the baseline arm received no Simple context. The skill passed six, the baseline three; on the hardest case, a concurrency ownership riddle, two of three against none of three. It also activated correctly from a bare “What would Theo do” prompt, though that answer still failed to name the repository’s own proof route.
The caveats matter as much as the numbers: small sample, one model, one harness. Much of the measured value comes from the per-repository facts in SIMPLE.md, not from the skill text alone.
The protocol is part of the work. Paired no-skill and with-skill runs, grader self-test references in every case, a machine-readable results schema, and failed experiments recorded rather than hidden. Instruction text ships only when a paired evaluation moves a number, and superseded results stay published with their corrections.
claude plugin eval simple@timc0y-simple --runs 1 --no-publishSIMPLE.md
The skill holds the method. The nearest SIMPLE.md holds the facts.
# SIMPLE.md
Reality
One trusted operator
No external consumers
No production data
Ordinary path
One process, one command
Proof
Public result + readback
Reconsider when
A second consumer appears