How Context Daemon Works

Context Daemon runs a seven-stage pipeline. Each stage is a structured divergent/convergent exercise — you explore widely, then narrow to a decision. Context accumulates across stages through file artifacts. The daemon reads what you've already produced and carries it forward. Nothing gets lost between stages.

Each stage has a kill point. If an idea isn't working, the pipeline kills it early — before you've wasted build time on something that was never going to ship.

01 Research

DIVERGENT → CONVERGENT

The Research stage is structured exploration. You diverge — casting a wide net across the problem space, competitors, prior art, and adjacent domains. Then you converge — synthesizing what you found into a structured research findings document that downstream stages can consume.

The output is research-findings.md — a document with key findings, evidence quality ratings, and an opportunity framing. This becomes the foundation for everything that follows.

Input: Your idea, problem space, or domain

Output: research-findings.md

Kill point: If research reveals the problem isn't real or the space is already saturated, kill here. Don't strategize about a non-problem.

02 Strategy

DIVERGENT → CONVERGENT

The Strategy stage produces a WWWHW — Why, Who, What, How, When. It reads your research findings and guides you through a structured strategy exercise. Why does this need to exist? Who is it for? What exactly is the solution? How will you know it's working? When does this ship?

The output is wwwhw.md — a strategy document that functions as your project's north star.

Input: research-findings.md

Output: wwwhw.md

Kill point: If you can't articulate a compelling Why or identify a specific Who, the idea may not be ready. Kill or shelve.

03 Gauntlet

ADVERSARIAL STRESS-TEST

The Gauntlet is optional and auto-calibrated. For major bets, it's a full five-phase adversarial stress test — your strategy gets attacked from every angle. For incremental features, it's a lightweight assumptions check. For tiny scope, skip it entirely.

The daemon asks you one question: "How would you characterize this project — major bet, incremental feature, or skip?" Then it routes accordingly.

Five phases (full gauntlet): Thesis Inversion, Moat Analysis, Technical Feasibility, Competitive Landscape, Decision.

Input: wwwhw.md, research-findings.md

Output: gauntlet-state.md

Outcomes: Proceed (build it), Refine (fix weaknesses), Pivot (change direction), Pause (wait for conditions to change), Kill (stop, the thesis doesn't hold)

04 Design

DIVERGENT → CONVERGENT

The Design stage creates a complete design system — not mockups, not wireframes, but the tokens, rules, and component specifications that an AI coding agent can use as hard constraints. Colors with hex values. Typography with specific fonts and sizes. Spacing with pixel values. Component behaviors with interaction states.

The output is precise enough that an agent can implement a UI conforming to the system without asking design clarification questions.

Input: wwwhw.md, gauntlet-state.md

Output: design-system.md

Kill point: Rare at this stage, but if design exploration reveals the product concept is fundamentally un-buildable within appetite, flag it.

05 Specification

DIVERGENT → CONVERGENT

The PRD stage produces a product requirements document — the authoritative spec for what gets built. It reads everything produced so far (strategy, gauntlet findings, design system) and synthesizes it into requirements with acceptance criteria, user scenarios, technical constraints, and a build order.

This is the document you hand to a coding agent. It should be specific enough that the agent can execute without ambiguity.

Input: wwwhw.md, gauntlet-state.md, design-system.md

Output: prd.md

Kill point: If writing the spec reveals scope has ballooned beyond appetite, either cut scope or kill.

06 Build

EXECUTION

The Build stage is where the coding agent takes over. The daemon provides the PRD as the execution spec and the design system as the visual authority. It structures the build into phases, tracks progress, and ensures the implementation stays true to the spec.

This is the convergent endpoint of all prior stages — every decision, constraint, and design token flows into the build.

Input: prd.md (primary), design-system.md (visual authority)

Output: The built product

Kill point: If build reveals a fundamental technical blocker not caught in the Gauntlet, flag and decide.

07 Ship

LAUNCH + MEASURE

The Ship stage structures the launch. It reads your strategy's success metrics and rollout plan, creates a ship log, and guides you through the release — what to measure, what to watch, and when to make the persevere/pivot/pause decision.

Shipping isn't the end. It's the first contact with reality.

Input: wwwhw.md (success metrics, rollout plan), built product

Output: ship-log.md