/evanflow-go

name: evanflow-go
description: Single entry-point orchestrator for the entire EvanFlow loop. The user says "let's evanflow this", "use evanflow", "evanflow this idea", "run this through evanflow", "implement with evanflow", or any similar phrasing — and you walk the full loop (brainstorm → plan → execute → tdd → iterate → STOP) end-to-end, announcing each step, respecting checkpoints, and stopping where the user retains control. Trigger keywords: "evanflow", "let's evanflow", "use evanflow", "evanflow this".

EvanFlow: Go (Entry-Point Orchestrator)

Single entry point for the EvanFlow workflow. The user gives you an idea or task and asks to "evanflow it" — you take responsibility for walking the whole loop end-to-end, picking the right sub-skill at each step, and respecting checkpoints where the user must stay in control.

You are the conductor; the other `evanflow-*` skills are the orchestra.

Vocabulary

See `evanflow` meta-skill for the shared vocabulary (deep modules, deletion test, vertical slice, grill, mockup quick-mode).

When to Use

Trigger phrases (or anything semantically equivalent):

• "let's evanflow this"
• "use evanflow"
• "evanflow this idea"
• "run this through evanflow"
• "implement with evanflow"
• "let's [do X] using evanflow"

**SKIP when:**

• The user is asking a factual question (no skill needed at all)
• The user wants quick mockups only (the brainstorming skill's mockup quick-mode handles this directly — no full loop needed)
• The user explicitly invoked a specific sub-skill by name (`evanflow-debug`, etc.) — let them control granularly
• The work is a one-line fix or trivial change — full loop is overkill

The Walk

Phase 0 — Restate and Confirm Scope (one sentence)

Confirm you've understood the idea in your own words, in one sentence. Examples: > "Got it — you want to add an `archived` flag to messages so cancelled ones drop off the dashboard."

Then ask one calibration question if scope isn't obvious: > "Quick scope check: is this a small targeted change or a feature with multiple components?"

If the user signals quick/small → consider whether a full evanflow loop is overkill. Offer a shortcut: "This sounds small — want me to skip brainstorming/planning and just TDD it directly? Or run the full loop anyway?"

Phase 1 — Brainstorm (always, unless user opts out)

**Announce:** "Step 1: brainstorming via `evanflow-brainstorming`."

Invoke `evanflow-brainstorming`:

• Quick context check (skim relevant files; don't exhaustively explore)
• Scope check (decompose if multi-subsystem)
• Clarifying questions one at a time, multiple-choice when possible
• Propose 2–3 approaches with your recommendation as option (a)
• Embedded grill on the chosen approach
• Present the design in sections; get explicit approval

**Mockup quick-mode bypass:** if the user originally said "show me mockups" rather than "implement," skip the full loop and produce mockups directly (HTML files, Figma frames, ASCII layouts — whatever the project uses). No spec, no plan, no TDD ceremony.

**Checkpoint:** before continuing, the user must explicitly approve the design. Not a tacit yes — actual confirmation.

Phase 2 — Plan (if non-trivial)

**Announce:** "Step 2: writing the plan via `evanflow-writing-plans`."

If scope is small (one file, one behavior change), skip to Phase 3 with a verbal plan ("I'll write a failing test for X, then minimal impl"). Otherwise:

Invoke `evanflow-writing-plans`:

• File structure first (name files + responsibilities, deletion test on each)
• Embedded grill on the structure
• Bite-sized tasks
• **Step 2.5: parallelization check.** If the plan has 3+ independent units sharing a contract, offer `evanflow-coder-overseer` to the user as the execution path instead of sequential `executing-plans`. Lay out signals on both sides. User picks.

If the user picks coder-overseer, structure the plan with a per-coder section + cohesion contract upfront.

**Checkpoint:** before continuing, the user must approve the plan.

Phase 3 — Execute (sequential or parallel)

**Announce based on user's pick:**

• Sequential: "Step 3: executing the plan via `evanflow-executing-plans`."
• Parallel: "Step 3: executing in parallel via `evanflow-coder-overseer`."

**Sequential path** — invoke `evanflow-executing-plans`:

• Step 0: parallelization re-check (one more chance to switch paths)
• Critical review of plan
• Set up TaskCreate items
• Task-by-task; each task uses `evanflow-tdd` for any production code
• Inline verification (typecheck, lint, test for affected workspaces)
• Stop and ask on blockers

**Parallel path** — invoke `evanflow-coder-overseer`:

• Author cohesion contract (with named tests + integration tests at touchpoints)
• Decompose into coder tasks (max 5)
• Phase A: spawn coders for RED checkpoint (failing tests only)
• Verify all REDs are clean
• Phase B: spawn coders for vertical-slice GREEN
• Spawn per-coder overseers (use `subagent_type: evanflow-overseer` if available)
• Spawn integration overseer (runs touchpoint tests)
• Reconcile findings (max 3 rounds)

**Inside both paths**, every code-writing task goes through `evanflow-tdd` — it's the discipline running inside the execute harness, not a phase that comes after. Per-cycle: RED → GREEN → REFACTOR (refactor with the fresh test as safety net, not deferred to the end). Behavior through public interface, watch each test fail before writing impl, assertion correctness check.

Phase 4 — Iterate (always, on success)

**Announce:** "Step 4: self-review loop via `evanflow-iterate`."

Invoke `evanflow-iterate`:

• Run the project's quality checks (typecheck, lint, test — exact commands per CLAUDE.md)
• Re-read the diff (dead code, naming, deletion test, magic strings, error handling, type safety, security, test coverage, assertion correctness, scope creep, comments)
• Five Failure Modes pass (hallucinated actions, scope creep, cascading errors, context loss, tool misuse)
• For UI changes: chrom