Skip to content
Docs

The six layers overview

The six layers are the stages of Denote's pipeline, each capturing a different class of structural decision. You move through them in order: Vision, Extract, Map, Structure, Layout, Plan. Each layer is a checkpoint. Each layer writes one or two files to design/. By the time Claude Code reads the output, every structural question has an answer.

Why six layers

The pipeline is a decomposition of the single question "what should this product be?" into smaller, independently reviewable questions.

Trying to answer everything at once produces black-box output. You write a prompt, the tool renders a screen, the structure is whatever the model decided. There is no point where you can look at the structure on its own, without visuals getting in the way.

Splitting the question into six lets you review and edit one thing at a time. The objects. The governance. The page inventory. The region arrangement. Each layer is its own surface in Denote, with its own canvas shape.

The six layers at a glance

1. Vision

What it captures: goals, constraints, audience, open questions. The scratchpad for the evolving idea.

What it writes: design/vision.json.

What it looks like: a terminal-dominant layer. You talk through the product idea with Claude Code. A sidebar accumulates the items worth keeping (outcomes, constraints, audience, open questions). Claude Code proposes items as the conversation goes; you confirm or dismiss. You can also pin text from the terminal directly into the sidebar.

Recipe example: "Home cook needs to scale recipes by serving count. Constraints: must work on a phone in the kitchen. Audience: people cooking for family sizes that do not match the original recipe. Open question: do we save favorite scaling ratios per recipe?"

2. Extract

What it captures: the objects the product is about. Entities, personas, tasks. The attributes of each entity, the states it can be in, the relationships between them.

What it writes: design/entities.json, design/personas.json, design/tasks.json.

What it looks like: structured cards per entity, persona, and task. Entity diagrams showing relationships. You can edit any field directly.

Recipe example: Entities are Recipe, Ingredient, Serving, ScalingRatio. Personas are Home Cook. Tasks are "scale a recipe", "save a favorite ratio", "view past scalings".

3. Map

What it captures: governance. Visual cues per entity trait, pattern assignments per context, priority rules when cues conflict, mental models from adjacent products.

What it writes: design/governance.json.

What it looks like: a governance editor. Per entity, the visual cues that fired. Per context (entity plus persona plus task), the assigned UX pattern and its configuration. Priority rules are edited as a small ranked list.

Recipe example: Recipe has a strong identity attribute (name) and image, so the visual cue says "card with image thumbnail, not table row". The Home Cook + Recipe + scale task is assigned the detail_page pattern with an inline scaling control.

4. Structure

What it captures: the page inventory. Which views exist, which pattern assignments share a page, the navigation hierarchy (L1, L2, L3).

What it writes: design/architecture.json.

What it looks like: an architecture tree and a navigation flow diagram, both on a canvas. You can drag pages between levels, reorder, split one page into two.

Recipe example: One top-level page "Recipes" (list), one detail page "Recipe" (with the scaling control and saved ratios), one settings page "Preferences". No secondary nav.

5. Layout

What it captures: spatial arrangement. Global shells (the persistent chrome: nav, header, footer). Per-page region wireframes (which regions exist and how they are arranged). Surface patterns (how right panels, modals, and drawers are used).

What it writes: design/layout.json.

What it looks like: a shell editor with schematic thumbnails, and a per-page wireframe view where you drag region boundaries directly. Wireframes are schematic (labeled rectangles), not rendered.

Recipe example: One consumer shell with a top bar and a main region. The list page uses a stacked composition (header, list of recipe cards, footer pagination). The detail page uses main plus sidebar (main for the recipe and the scaling control, sidebar for saved ratios).

6. Plan

What it captures: the build plan Claude Code executes. Data model from entities, routes from architecture, component patterns from governance, design direction and token source pointer from Project Settings.

What it writes: design/plan.md.

What it looks like: a rendered Markdown document. You do not usually edit it by hand; you re-run /generate-plan when upstream layers change.

Recipe example: The plan.md describes a two-page app, a Recipe data model with ingredients[] and scalings[], routes for list and detail, a card-grid list, a detail layout with a scaling input bound to a derived ingredient table.

How the layers connect

Each layer is derived from the one above it by running a skill in the terminal.

  • /vision prompts Claude Code to help you fill the Vision sidebar.
  • /extract reads design/vision.json and writes the Extract files.
  • /map reads the Extract files and writes design/governance.json.
  • /structure reads the Map files and writes design/architecture.json.
  • /layout reads Structure and Map and writes design/layout.json.
  • /generate-plan reads everything and writes design/plan.md.

You do not have to run them in strict order. You can edit any layer at any time. When an upstream layer changes in a way that might affect a downstream layer, the activity feed logs a hint: "Extract changed. Map may be stale. Run /map to update." There is no forced cascade. You decide when to re-run.

You do not need every layer to build

A simple utility might only need Vision and a hand-written plan. A complex app might go through all six. The pipeline is a ladder, not a gate. You use the layers you need for the decisions you need to make.

Claude Code builds from whatever files exist. If design/layout.json is empty, Claude Code falls back to reasonable defaults for the pattern assignments in design/governance.json. If design/governance.json is empty, it falls back to reasonable defaults for the entities in design/entities.json. The further up the pipeline you have filled, the more of the structural decision is yours rather than the model's.

Where to next