Skip to main content
The Clone Substack workflow takes a detailed specification document and autonomously builds a complete, working application — in this case, a Substack-like newsletter creation tool. It uses ensemble planning (two independent plans debated into one), a multi-stage verification chain, parallel code review with consensus, and a postmortem repair loop that feeds failures back into the next iteration. This pattern is adapted from Kilroy’s substack-spec-v01.fabro, which builds a full React application from a natural language spec with acceptance criteria.

​
When to use this

  • You have a detailed spec and a definition of done with concrete acceptance criteria
  • The deliverable is large enough that a single agent pass won’t get it right
  • You want automated verification (build, format, tests, browser checks) with human-free repair loops
  • You want independent review perspectives before accepting the result

​
The workflow

Clone Substack workflow: Start → Bootstrap → Plan Fan-Out → Plan A and Plan B → Debate → Implement → Verify Chain → Review Fan-Out → Review A and Review B → Consensus → Exit, with Fix loop from Verify back to Implement, Rejected path from Consensus to Postmortem, and Replan loop from Postmortem back to Plan Fan-Out
clone-substack.fabro

​
Key patterns

​
Debate planning with independent providers

Instead of a single plan, the workflow generates two independent plans using different models, then synthesizes them:
Plan A runs on Claude Opus and Plan B on Gemini Flash. A different provider for each plan means genuinely independent perspectives — different training data, different reasoning patterns, different blind spots. The debate node reads both plans and produces a single best-of-breed plan that resolves conflicts and picks the strongest approach for each module. When a postmortem exists from a prior iteration, both planners and the debate node read it and adjust the plan to address every identified issue. This creates a feedback loop where each planning round is informed by the failures of the previous one.

​
Six-stage verify chain

After implementation, the workflow runs a gauntlet of six automated checks. Each check is a command node followed by a conditional gate. If any check fails, execution loops back to implement where the agent reads the consolidated error log and fixes the specific failures:
The checks are ordered by cost — format fixing is nearly instant, builds take seconds, tests take longer, browser checks need a running server, artifact validation cross-references evidence files, and the LLM-based fidelity check is the most expensive. By failing fast on cheap checks, the workflow avoids wasting tokens on fidelity verification when the code doesn’t even compile. Each verify step appends errors to .workflow/verify_errors.log. When the implement node runs again, it reads this error log and makes targeted fixes rather than regenerating from scratch.

​
Fidelity verification

The verify_fidelity node is an LLM-based acceptance test. It reads every acceptance criterion (AC1–AC11) from the definition of done, maps each one to concrete files in the implementation, and produces a per-criterion pass/fail verdict. This catches semantic gaps that automated tests miss — a test suite can pass while the app is missing entire features. The fidelity node communicates its result via context updates. It sets all_acs_pass to "true" or "false", and the downstream gate routes based on that context value:

​
Ensemble review with consensus

After all automated checks pass, two independent reviewers evaluate the implementation using different providers:
Both reviewers are instructed to perform mandatory browser verification — they must build the app, start a preview server, and verify it serves real HTML. Screenshot artifacts under 5KB are rejected as fake. This prevents the pattern where code passes static analysis but doesn’t actually render. The review_consensus node applies strict consensus rules:
  • Both APPROVED with no critical gaps: pass
  • Any critical gap from either reviewer: rejected with specific AC IDs
  • Mixed verdicts: rejected with gaps enumerated

​
Postmortem repair loop

When the review consensus rejects the implementation, the workflow runs a postmortem before replanning:
The postmortem node reads all available evidence (review outputs, fidelity checks, implementation logs, test evidence) and produces a structured analysis: root causes, what works and must be preserved, what failed and must be fixed, and concrete next changes. Critically, it directs targeted repair, not a from-scratch restart. The postmortem also classifies the failure. Most failures route back through planning (replan), but environment issues route to check_toolchain for bootstrap repair:

​
Bootstrap self-heal

The check_toolchain node has a self-heal edge for transient infrastructure failures. If Node.js or npm fail to respond due to a temporary issue, the workflow retries via a loop_restart edge. Deterministic failures (toolchain not installed) route to the postmortem for diagnosis:

​
Model routing strategy

The stylesheet assigns models based on task difficulty:
The .branch-b class uses a different provider for both planning and review. This ensures the second opinion is genuinely independent — not just a second run of the same model. The .hard class routes implementation to OpenAI’s Codex, which is optimized for high-throughput code generation.

​
Adapting this pattern

This pattern generalizes beyond React applications:
  • API implementation — spec is an OpenAPI document, verify chain runs contract tests
  • CLI tool — spec is a man page or usage doc, verify chain runs integration tests
  • Infrastructure — spec is a Terraform design doc, verify chain runs terraform plan and policy checks
  • Library — spec is an API surface doc, verify chain runs unit tests and type checks
The core structure is always the same: debate plan, implement, verify with escalating checks, ensemble review, postmortem on failure, loop. To adapt for your project:
  1. Write your spec with concrete acceptance criteria (the more specific, the better the fidelity check)
  2. Write validation scripts for each stage of the verify chain (format, build, test, browser/integration, artifacts)
  3. Adjust the model stylesheet for your budget and quality requirements
  4. Customize prompts with your project’s language, conventions, and file paths
  5. Tune the verify chain — add or remove stages to match your project’s quality gates

​
Further reading

NLSpec Conformance

A simpler implement-test-fix loop for spec-driven development.

Ensemble

Multi-provider fan-out and synthesis.

Failures

Retry policies, loop detection, goal gates, and circuit breakers.

Model Stylesheets

CSS-like rules for assigning models to workflow nodes.