# Elenchus Build > Use when the user wants a build or architecture idea stress-tested before they commit to building it — "help me plan/design this app", "design the architecture for X", "review my architecture before I build", "is my mental model of X sound", "I want to build Y because Z — poke holes in it". For the still-articulating stage, before brainstorming. NOT for ideas already decided (that's brainstorming), NOT for researching/learning a topic the user has no premise about yet ("I want to learn about X" / "gather resources on Y" — that's elenchus-study), and NOT for an over-engineering / flaw yes-no verdict ("is X over-engineering?") — a single high-tier model can answer those. - Skill: `alexvtejeda/elenchus-build` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add alexvtejeda/elenchus-build` - Raw SKILL.md: https://api.skillmd.com/api/skills/alexvtejeda/elenchus-build/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: alexvtejeda (https://skillmd.com/u/alexvtejeda) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/alexvtejeda/elenchus-build --- # Elenchus — build front end The **build/architecture** front end over the `elenchus-council` engine. The engine owns the loop (Socratic questions → user answers → stress-test → dissent-preserving synthesis → gate, no readiness verdict). **This skill does not re-implement that — read `elenchus-council/SKILL.md` and run its loop.** This file supplies only the build-mode specifics: triggers, premise shaping, seat instructions, seat tools, the checkpoint file, and the terminal. **Convening the engine is the first move, not a formality.** Do not answer the premise yourself, even when the build "seems simple" — that shortcut is the exact sycophancy this exists to prevent. ## Scope - **In:** stress-testing a build/architecture premise — a single feature or a whole app from scratch — that the user is still articulating. - **Out:** an idea the user has already settled (hand to brainstorming); and an over-engineering / flaw **verdict** ("is feature X over-engineering?"). That framing invites a yes/no and sycophancy; a single high-tier model can give it. Elenchus deliberately replaces the verdict with gap-exposure. ## Premise shaping (what to elicit before Round 1) Get the user's **mental model in their own words**, enough for the seats to find where it's thin. Draw out: 1. **What the app/feature is**, and **what they want to build** in this round. 2. **Why** — the goal behind it ("I want feature Y because I think it boosts activity"). The *why* is where the load-bearing assumptions hide. 3. **The key frameworks / APIs / services** they intend to use. 4. **Scope:** a feature on an existing app, or an app from scratch. This is the premise. Don't pre-critique it — but **don't dispatch on it yet either.** First run **Macro clarification** below to give the seats a macro vision, then propose a **Seat roster**. Both happen in the chairman thread, before Round 1. ## Macro clarification (before Round 1) The seats are strong on **architecture, tools, and logic** but **rarely reach for the frontend** on their own. So before dispatching, the chairman builds a **macro vision** of the project and feeds it into every seat's prompt — that is what lets the seats ask grounded questions across *all* the project's aspects (frontend included), not just the backend slice they gravitate to. **Ask the macro questions one at a time, in chat.** Do **not** dump a list, and do **not** spin up one markdown file per question. Ask one, wait for the answer, ask the next. Record each Q&A into the checkpoint's *Clarifying Q&A* section as it lands (chairman asked / user answered), so it survives a `/clear`. Cover at least these axes — skip any the premise already settled, follow up where an answer opens a new gap: - **Platform.** Web app? Mobile (one OS or multiplatform)? Desktop (which framework)? CLI? A mix? "Is this multiplatform, or one target first?" - **Frontend stack.** Framework / rendering model / component system in mind — or undecided. - **Backend & services.** Runtime, data store, third-party APIs, auth, hosting. - **Users & scale.** Who uses it, how many, what's the load-bearing UX path. - **Greenfield vs existing.** New build, or a feature inside a running system with constraints. **When a framework choice is undecided, offer elenchus-study.** If the user is unsure which framework/library to pick, say so and offer to dispatch **elenchus-study** to benchmark the candidates on community feedback before continuing — don't guess one into the premise. **For a visual frontend-design question, hand off — don't decide it in prose.** When a question is genuinely *visual* (a layout, a component's look and feel, two design directions to compare — not a conceptual "which stack?"), dispatch the design thinking to the **`ui-ux-pro-max`** skill and render its options through the **`visual-companion`** skill so the user can *see* them in the browser. The user answers in the **terminal**; the browser is display-only. Keep conceptual/tradeoff/requirements questions in the chat as usual — this handoff is only for questions the user grasps better by seeing than reading. **The chairman does the design once — the seats do not.** The council seats only surface the *visual requirements and critique* as text (that is all their round schemas produce, and they cannot dispatch subagents). **Do not ask every seat to generate or push a mockup** — that fans out N redundant designs and burns tokens. Instead the **chairman alone** takes the seats' requirements, runs `ui-ux-pro-max` **one time** to produce the design/options, and pushes that single result through `visual-companion`. Seats gather; the chairman renders. ## Seat roster (proposed, then approved) After the clarifying questions — as a **separate** step — the chairman proposes a seat roster, then the user approves or edits it. The engine's default is one seat per tier (fable/opus/sonnet/haiku); build mode **replaces that with the approved roster**: any seat count, any model mix, each seat carrying a **lens**. **Propose, grounded in the answers — never guessed.** State the count, the model per seat, and *why each lens earns its seat*, tied to what the user actually said. Example shape: > "Here's my proposed roster — 2 opus, 4 sonnet, 1 haiku. The two opus seats take the > **frontend** (you're going multiplatform Flutter, that's where the load-bearing risk > is). Three sonnet seats split the **backend** (sync engine, data model, auth). One sonnet > takes **integrations** (the Stripe + push pieces). The haiku seat is a **macro-alignment** > check — it holds the whole picture and flags aspects the others missed. Roughly N seat-calls > per round." - **Propose freely; add a one-line cost note** (≈ seat-calls per round) and let the user trim. - **Lenses do the decorrelating within a tier.** Repeated tiers are fine (e.g. 4 sonnet) — give each a **distinct lens** (frontend / a specific backend slice / integrations / macro-alignment) so they don't collapse onto the same answer. The engine's honest-labeling still holds: same vendor, better than one model, not truly independent. - **The user owns the final roster.** They approve as-is or specify their own count, models, and lens split. Record the approved roster in the checkpoint (`seats:` as `{model, lens}`). - **Graceful degradation unchanged:** if an approved tier can't be reached, drop that seat, say so, never silently re-assign its lens to a duplicate model. **Confirm the roster before EVERY dispatching round — not just Round 1.** Before dispatching *any* round (Round 1, Round 2 re-dispatch, **and Round 3 spec-check**), and on **resume** of an existing session, the chairman **presents the roster it intends to use and waits for the user's go-ahead before dispatching.** Reusing the checkpoint's saved roster is fine — but the user must still confirm it (or edit it) *this* round. On resume, re-state the saved roster and the per-seat lens/slice assignment for the upcoming round, and dispatch only after the user agrees. **Never dispatch seats on a silently-reused or newly-assumed structure.** This is a hard gate, same as the "answer questions one at a time" rule. ## Round templates (build mode) The engine composes each seat's prompt from `seat-base` + a **round template this skill owns** + the tier adapter (see `elenchus-council` → *Templates & composition*). Build mode supplies three: - **Round 1 — `templates/round-1-questions.md`.** The biting questions a senior reviewer would ask about *this* design (the un-named failure mode, the edge case, "can you actually explain this part?"). Schema: `QUESTIONS / UNEXAMINED ASSUMPTIONS / WHERE TO LOOK`. **The chairman injects, per seat, that seat's assigned LENS (from the roster) and the MACRO CONTEXT (from the clarifying Q&A)** into the composed prompt — so each seat asks within its lens (including the frontend the seats normally skip) while holding the whole-project view. - **Round 2 — `templates/round-2-stress-test.md`.** Stress-test the user's answers for contradictions, unjustified leaps, and hand-waving. Schema: `HOLDS UP / DOESN'T HOLD / STILL OPEN`. - **Round 3 — `templates/round-3-spec-check.md`** (terminal only, runs once the user self-declares ready — see *Terminal*). Seats audit the chairman's **draft spec** against the session record for fidelity and completeness, not the user's design. Schema: `CAPTURED FAITHFULLY / MISSING / MISREPRESENTED`. **Tools/grounding:** the council-seat sandbox carries Read/Grep/Glob/WebSearch/ WebFetch + **Context7 MCP**. In build mode the seats ground every framework / API the user named against **current docs** (Context7 first, web second) — both to ask accurate questions and to point at a concrete, current study path, not generic advice. ## The checkpoint file (durable state) One markdown file per premise is the durable record that survives a `/clear`. - **Path:** `docs/elenchus/.md` (slug = lowercase, hyphenated, from the premise; e.g. `docs/elenchus/pelu-geocoding.md`). - **Gitignore `docs/elenchus/` first.** These checkpoints are private session scratch, not artifacts to commit. Before writing the first checkpoint, ensure the caller project's `.gitignore` contains a `docs/elenchus/` line — append it if missing (create `.gitignore` if there is none). Do this once per session; don't duplicate the line. - **Write it DURING the round, before the user clears** — never rely on a `SessionEnd` hook. After Round 1, write the premise + anonymized, categorized questions, then tell the user to `/clear` or `/compact` and re-invoke. After Round 2, update with what held, the flagged contradictions, and the study path. - **Resume = scan-on-invoke.** When convened, Read `docs/elenchus/` for an open session (`ready: false`) matching the premise. If found, resume from its `round`: read the premise + open questions back to the user and collect their answers, then dispatch Round 2. If none, start Round 1. - **Ask the Round-1 questions one at a time, in chat — same as the clarifying phase.** The questions live in the checkpoint markdown, but the user answers them **in conversation, one by one**, not by editing the file or replying to a dumped list. Read one question (keep its id and which category it came from), wait for the answer, record it in the checkpoint's answers section, then ask the next. This is the default flow for every new user, not a per-user preference. "I don't know" is a valid answer — log it and move on. Only after the last question dispatch Round 2. Frontmatter schema (mirrors the readiness-session prototype): ``` --- artifact: elenchus-build-session premise: "" ready: false # the USER self-declares this true; the council never sets it round: 1 # 1 = questions posed, awaiting answers · 2 = answers stress-tested platform: "" # from clarifying Q&A macro: # the macro vision injected into every seat (from clarifying Q&A) frontend: "" backend: "" users_scale: "" greenfield: seats: # the USER-approved roster (replaces the engine's one-per-tier default) - {model: opus, lens: frontend} - {model: sonnet, lens: backend-sync} - {model: haiku, lens: macro-alignment} frameworks: [...] # tools/APIs the seats grounded via Context7/web open_questions: [Q1, Q2, ...] # ids unanswered or returned "I don't know" resolved: [...] study_path: [...] # concepts to study for any "I don't know" / flagged gap spec_path: null # set to docs/superpowers/specs/-.md once written created: updated: --- ``` Body: the premise; a **Clarifying Q&A** section (each macro question the chairman asked in chat + the user's answer, in order — written as it lands, before any `/clear`); the Round-1 questions grouped **by category** (anonymized — strip which seat asked), each with an id; an **answers** section; a **stress-test** section (held / didn't hold / still open + contradictions); and the **study path**. ## Terminal - **Success exit = the user self-declares ready.** This does **not** end with a bare hand-off — it ends with a **verified spec** that pins down what the session settled, produced in four steps (Spec synthesis, below): the chairman drafts → the council verifies the draft (Round 3) → the chairman revises → the user finalizes it. The spec is the input the **brainstorming skill** then reviews (and from there, writing-plans). Elenchus is the stress-test *before* brainstorming; the spec is the bridge between them. Set `ready: true` in the checkpoint only because the *user* declared it. - **Open questions / an "I don't know" → honest stop.** Present the ordered study path (grounded in current docs), keep the checkpoint open, and invite re-entry after study. An "I don't know" is a learning point, **not** a failure — and **not** your cue to teach the gap and green-light building anyway. Teach if asked, but the green light is the user's call. Never certify readiness. Do **not** write a spec while questions are still open unless the user explicitly asks for an interim spec that records the gaps as open. ## Spec synthesis (the terminal artifact) Once the user self-declares ready, pin the session down into a spec the brainstorming skill can consume. The spec is a **faithful record**, not a green light: it carries the settled decisions *and* the dissents and open questions, with their reasoning intact. 1. **Draft.** From the checkpoint, the chairman writes a draft to `docs/elenchus/-spec-draft.md` covering: - **Premise & goal** — what's being built and the *why* behind it. - **Settled decisions** — each decision that survived stress-test, with the reasoning that made it hold (not flattened to a bare assertion). - **Grounded frameworks / APIs** — what was checked against current docs, and how firm. - **Constraints & non-goals** surfaced during the rounds. - **Preserved dissents** — where the seats split, *both* positions and the condition under which each wins. Never smooth these into "agreed." - **Open questions / study path** still outstanding (if the user chose to spec anyway). 2. **Verify (Round 3 — full parallel council).** Dispatch the seats via the engine with `templates/round-3-spec-check.md`, giving each the **session record + the draft**. They audit fidelity, not the design (`CAPTURED FAITHFULLY / MISSING / MISREPRESENTED`). Anonymize and synthesize as in any round. 3. **Revise.** The chairman fixes every `MISSING` / `MISREPRESENTED` finding — restoring dropped decisions, un-smoothing dissent, removing invented certainty. Re-verify if the revisions were substantial. 4. **Finalize on the user's say-so.** Present the verified draft. **Only after the user confirms**, the chairman writes the final to `docs/superpowers/specs/-.md` and records that path in the checkpoint's `spec_path`. The user owns this call — do not write into `specs/` or treat the spec as a build green light without explicit confirmation. Then point the user at the **brainstorming skill** over that spec file. ## Common mistakes (build front end) - Answering the architecture question directly because it "seems simple" instead of convening the council. - Skipping the macro clarification and dispatching seats with no macro vision — so the seats ask only backend questions and the frontend goes unexamined. - Dumping all the clarifying questions at once, or spinning up a markdown file per question, instead of asking them one at a time in chat. - Dumping all the Round-1 council questions for the user to answer in one block (or telling them to edit the checkpoint), instead of asking them one by one in chat. The questions are stored in markdown; they are *answered* in conversation, one at a time. - Dispatching the fixed four fable/opus/sonnet/haiku seats without proposing a roster, or proposing a roster the user never approved. - Re-dispatching a later round (Round 2, Round 3, or on resume) on a **silently-reused or assumed roster** without re-confirming the structure with the user first — the roster gate applies to *every* dispatching round, not only Round 1. - Repeating a tier across seats without giving each a **distinct lens** — duplicate models with the same lens are one model in a costume. - Converting "the user can't explain their own design" into "a small gap I'll teach, then they can start." Surface the study path; withhold the green light. - Letting the chairman declare the design ready. Readiness is the user's call. - Writing state only at the end (lose it on `/clear`) instead of during the round. - Smoothing a genuine bottom-line split between seats into "they basically agree." - Smoothing that same split *out of the spec* — dropping a preserved dissent or open question so the spec reads cleaner than the session actually was. - Writing the spec yourself and skipping the Round 3 council verification, or treating its `CAPTURED FAITHFULLY` as a readiness sign-off rather than a fidelity check. - Writing the final into `docs/superpowers/specs/` (or calling the spec a green light to build) before the user explicitly confirms. Drafting and placement are different calls.