Design

Design is the third stage of the platform workflow. It takes your completed product definition from Define and produces a complete technical solution: a project plan, stakeholder brief, client proposal, architecture document, and a granular dependency-ordered implementation backlog.

What it is

Every artefact is generated with your product definition as context, which prevents the technical solution from drifting away from the problem you set out to solve.

Who can use it

Available to all authenticated users with an active subscription (both ORG Admins and ORG Members).

Navigate to Design in the sidebar or go directly to /project.

How it works

Project Runs

Every design is stored as a Project Run. A Project Run is linked to a Workflow Run (your product definition) and contains all artefacts generated through the Design layers. You can create multiple Project Runs, for example, to explore different technical approaches to the same product definition.

From the Design page you can:

• Create a new Project Run, linking it to an existing Workflow Run
• View and navigate all existing runs
• Access individual artefacts (plan, backlog, architecture, Layer 7 consultation)

Layer 3: Project Plan

Layer 3 generates the high-level project plan. It produces:

• A set of epics representing the major deliverable areas of the product
• Phases grouping epics into a logical delivery sequence
• Integration epic rules are enforced automatically to ensure cross-cutting concerns (authentication, APIs, data layers) are properly planned

The plan is stored as a structured JSON artefact on the Project Run. It is the spine that all subsequent layers build upon.

Layer 4: Project Brief

Layer 4 generates a stakeholder-facing project brief from the plan. The brief is written in plain language suitable for presentation to non-technical stakeholders, product owners, or clients. It communicates what will be built, why, in what phases, and what the expected outcomes are.

Layer 5: Client Proposal

Layer 5 generates a client-facing proposal document from the brief and plan. This is a more formal document suitable for commercial contexts, presenting scope, approach, phases, and expected deliverables in a structured format.

Architecture Document

The architecture generation is a separate step from the layered plan generation. It produces:

• An architecture document describing the overall technical approach, key decisions, and system design
• Architecture Decision Records (ADRs) capturing why specific technology choices were made

If your organisation has configured architecture defaults (preferred technologies, patterns, or constraints) in Settings, those are automatically injected into the architecture generation prompts. This ensures all projects start from a consistent architectural baseline.

The architecture document can be updated independently of the plan at any time. Use the Planner Chat panel or retrigger architecture generation after amending the plan.

Layer 6: Verbose Implementation Tasks

Layer 6 expands the project plan into granular, dependency-ordered implementation tasks. These are the tasks that will eventually be sent to the coding agent in the Build stage.

Each task:

• Carries full context about what it needs to do (not just a title)
• Has explicit dependencies on other tasks
• Is grouped into execution batches based on its dependency graph. Tasks in the same batch can be run in parallel; batches must be run in order

Layer 6 output is what populates the Kanban board in Build. The quality and completeness of the verbose tasks directly determines how well the coding agent performs.

Layer 7: Consultation and Prioritisation

Layer 7 generates a set of consultation questions. These are things the platform has identified as unknowns, risks, or decisions that should be resolved before coding begins. Examples include:

• Unresolved technical choices ("Should the API be REST or GraphQL?")
• Missing acceptance criteria for specific features
• Integration assumptions that need confirmation

Layer 7 also provides an interface to:

• Edit the architecture document inline
• Adjust task priorities before the backlog is sent to Build

Work through the consultation questions before enqueuing tasks. Each answered question reduces the risk of the coding agent making a wrong assumption.

Planner Chat (Artefact Amendment)

The Planner Chat panel is available throughout Design. It is aware of the current Project Run and all its artefacts.

Use it to:

• Ask questions about any artefact: "What dependencies does the authentication epic have?"
• Request amendments: "Add a caching layer to the architecture document."
• Regenerate affected artefacts: "The data model has changed, update the verbose tasks for the user management epic."

Changes are applied as diffs to the stored JSON artefacts and persisted to the Project Run.

Per-Project API Key Overrides

By default, the platform uses the organisation-level API keys configured in Settings. You can override the LLM provider keys on a per-project basis from within the Design interface.

This is useful when:

• A specific project should be charged to a different LLM account
• You want to test a project with a different provider or model configuration
• A client has provided their own API keys for a project

Project-level overrides take priority over organisation-level keys, which take priority over the platform environment defaults.

Adversarial Review

As in Define, any artefact in Design can be submitted to adversarial review. Critiques are contextualised to the artefact type. An adversarial review of a project plan will challenge scope, phasing, and assumptions. A review of an architecture document will challenge technical decisions and risks.

How to use it to solve your problem

Running a complete Design workflow

1. Navigate to Design in the sidebar.
2. Click New Run and link it to the completed Workflow Run (product definition) from Define.
3. Trigger Layer 3 to generate the project plan. Review the epics and phases.
4. If anything is missing or structured incorrectly, open Planner Chat and describe the changes needed.
5. Trigger Layer 4 to generate the project brief. Review it for accuracy and completeness.
6. Trigger Layer 5 to generate the client proposal if you need a commercial-facing document.
7. Trigger Architecture generation. Review the architecture decisions and ensure they match your technical constraints. Amend via Planner Chat if needed.
8. Trigger Layer 6 to expand the plan into verbose implementation tasks. This step may take several minutes for large projects.
9. Review the verbose tasks. Check that each task has sufficient context and that the dependency ordering makes sense.
10. Trigger Layer 7 to generate consultation questions. Work through each question and either answer it or update the relevant artefact to reflect the decision.
11. Adjust task priorities as needed from the Layer 7 interface.
12. When you are satisfied, move to Build to enqueue tasks to the coding agent.

Amending the design after Build has started

If requirements change mid-build:

1. Return to Design and open the relevant Project Run.
2. Use Planner Chat to amend the affected artefacts.
3. If new verbose tasks are needed, regenerate the affected epics or stories.
4. Return to Build to enqueue the new tasks.

How it fits the broader picture

Design sits between Define and Build. It translates the product definition into an executable technical plan. The formal link between the Workflow Run (product definition) and the Project Run ensures the Design output is always traceable back to the problem statement.

The verbose tasks produced in Layer 6 are the direct input to the Build stage. The better the Design output, the more autonomously and accurately the coding agent can work.

When your verbose tasks are complete, prioritised, and the consultation questions are resolved, move to Build.