// Clarify intent, propose 2-3 approaches, embedded grill to stress-test the chosen path. Use before any creative work — new features, components, behavior changes, design questions. Mockup-only requests use mockup quick-mode (no spec/plan ceremony).
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".
Meta skill for the EvanFlow system. Loads the shared vocabulary (deep modules, deletion test, vertical slice, grill, mockup quick-mode, no-auto-commit) and describes when to invoke each evanflow-* skill. Use when starting a new task and unsure which evanflow skill applies, or when you need to ground reasoning in the shared vocabulary.
Vertical-slice TDD for any production code. One test → one impl → repeat. Tests verify behavior through public interfaces, not internals. Use when implementing any feature, bugfix, or behavior change.
Orchestrate parallel implementation with coder/overseer pairs. Coders implement decomposed tasks using evanflow-tdd; overseers review each coder's output for bugs, gaps, errors, AND cohesion violations against a shared contract. A final integration overseer checks cross-coder cohesion. Use for plans with 3+ truly independent tasks that share an interface contract.
Manage long-session context to prevent drift and degradation. Strategies for proactive summarization, branch isolation, and /clear decisions. Invoke when context feels heavy, when accuracy starts slipping, or proactively after a major phase boundary. Addresses the
Root-cause discipline for bugs, test failures, and unexpected behavior. Embedded grill on the hypothesis before writing fix code. Use when encountering any bug, failing test, or behavior that doesn't match expectation.
| name | evanflow-brainstorming |
| description | Clarify intent, propose 2-3 approaches, embedded grill to stress-test the chosen path. Use before any creative work — new features, components, behavior changes, design questions. Mockup-only requests use mockup quick-mode (no spec/plan ceremony). |
See evanflow meta-skill. Key terms used here: deep modules, deletion test, mockup quick-mode, grill.
SKIP this skill when: the user is asking a factual question, requesting a quick mockup, or doing exploratory reading. EvanFlow has no skill tax — answer directly.
If the user says "show me mockups", "give me visual options", "let's see designs", or anything similar and is NOT asking to implement — skip everything below. Produce mockups directly in whatever form the project uses:
open mockup-1.html or via a local HTTP server)No spec doc. No plan. No git operations. Just iterate visually until the user picks a direction.
Once an approach is chosen, ask 3–5 sharp questions targeting:
CONTEXT.md?"For each question, propose a recommended answer. The user accepts, refines, or rejects. Don't grill on every single design — only when the choice has irreversibility, security, or domain-modeling implications.
docs/specs/YYYY-MM-DD-<topic>.md. Don't write to any vendor-specific path unless user requests.evanflow-writing-plans (if non-trivial)evanflow-prd instead of writing-plansevanflow-executing-plans (which itself offers evanflow-coder-overseer if the plan has 3+ parallelizable units)evanflow-tdd for the first behaviorevanflow-glossary to update CONTEXT.mdevanflow-design-interface before writing-plans