yeah went back and forth on exactly this trade-off, you're right that vertical can produce tests tailored to the impl. horizontal forces invariants up front but the failure mode flips: you're tailoring tests to the architecture you imagined before any feedback from working code. so it's invariants-vs-behaviors, both have a tailoring failure mode just on different axes. compromise i landed on: vertical + an explicit anti-tailoring grill check at each cycle. definitely gonna tweak with more as i keep refining.
1): you have things backwards, the EvanFlow is not something i came up with but rather something i discovered similar to the dao. i am named Evan after the EvanFlow not the other way around.
2): you're right and dmitry called this out below too. shipped a fix that puts REFACTOR per-cycle, instead of being a deferred "after all tests pass" step. the old step 4 was iterate-shaped not TDD-shaped.
> 1): you have things backwards, the EvanFlow is not something i came up with but rather something i discovered similar to the dao. i am named Evan after the EvanFlow not the other way around.
fair to call out but half true. i did send claude off to look up specific stats on failure modes (62% assertion correctness, etc), but the design decisions came from my own reading of anthropic's reports, the columbia daplab paper i cited, and a mix of matt pocock's lectures + my own anecdotal experience running this loop on real projects.
mmm good point! just shipped a fix that puts RED → GREEN → REFACTOR per cycle with the fresh test as safety net just like beck intended. macro/cross-cycle refactor lives in iterate now as its own separate thing so the two don't conflate. thanks for the catch : )
yeah that is a little confusing, tdd is actually a substep of execution. it was listed separately in the diagram because not every task uses TDD (config, generated types, etc. skip it), so the skill is invoked conditionally during execution rather than always. but the arrow notation made it look sequential when it's actually nested. updated the README diagram to show that. thanks for the nudge.
Built this as an opinionated Claude Code development flow based on evidence based practices and what has been working for me while developing professional code.
EvanFlow is a single TDD-driven loop. Say "let's evanflow this" and it walks brainstorm → plan → execute → tdd → iterate → STOP. Real checkpoints at design and plan approval. Never auto-commits, never auto-stages, never proposes integration - every git op is your call.
The three things that actually changed how I work:
1. Vertical-slice TDD. One failing test → minimal impl → next test. Watch each test fail before writing the impl that passes it. (Sounds obvious. Almost no agent does it by default. ~62% of LLM-generated test assertions are wrong per HumanEval research, so testing TDD discipline matters more than the impl discipline.)
2. Embedded grilling at decision points. Before locking a plan: what breaks if a user does X? What's the rollback? What's explicitly out of scope? Catches design flaws while they're still cheap.
3. Iterate-until-clean (hard cap of 5 rounds). Re-read the diff against dead code, naming, the deletion test, assertion correctness, and a Five Failure Modes pass (hallucinated actions, scope creep, cascading errors, context loss, tool misuse). For UI: screenshot via headless Chromium.
For bigger plans with 3+ independent units sharing types, it forks into a parallel coder/overseer orchestration. Integration tests at touchpoints ARE the cohesion contract.
Three install paths: Claude Code plugin marketplace, npx skills add, manual copy. MIT.
reply