Skill Graph

Design an app: from an idea to a product spec

Specs written in one pass promise features no screen shows and no table stores. Here users, scope, screens and the data model are designed in parallel, and a product review in a fresh context checks that every first-version feature has a user story, a screen and the data it needs.

7 steps in 4 stages · 7 subagents · a kit of 12 files

Open in the studioDownload the kit

Free. Built in your browser; nothing is uploaded. No API key, no account.

How it runs

Steps in the same stage start at the same time. Each subagent gets only what its incoming edges carry, and a step in a fresh context never sees the reasoning of the steps before it. A gate decides whether the work passes, and a failed gate re-runs the work it checks.

  1. Stage 1

    • Split · Planner

      sonnet · Read

  2. Stage 24 in parallel

    • Users & Stories · Worker

      haiku · Read, WebSearch

    • Features & Scope · Worker

      haiku · Read, WebSearch

    • Screens & Flows · Worker

      haiku · Read, WebSearch

    • Data Model · Worker

      haiku · Read, WebSearch

  3. Stage 3

    • VERIFIER (Fresh Context) · Checker

      opus · Read, Grep, Glob · fresh context

      Gate: Every first-version feature maps to a user story, a screen and the data it needs.

  4. Stage 4

    • Final answer · Writer

      sonnet · Read

Use it when

  • You have an idea and want a spec before you or an agent builds it.
  • You want the data model and screens to agree.
  • You want a first version that is small on purpose.

Change these first

  • Add a worker for pricing, onboarding or anything your product needs.
  • Ask the writer for the spec format your coding agent reads, such as a PRD.md.

Need a workflow built for your team? Fixed-price packages

What you get

An orchestrating SKILL.md, one Claude Code subagent per step with its own tools and model, and the same skill as a Cursor rule. Your agent runs it with its own subagents; nothing on this site calls a model.

design-an-app-skill-kit.zip12 files
  • .claude/skills/design-an-app/SKILL.mdorchestrator
  • .claude/skills/design-an-app/graph.skill.mdgraph source
  • .claude/agents/design-an-app-splitter.mdsubagent
  • .claude/agents/design-an-app-users.mdsubagent
  • .claude/agents/design-an-app-features.mdsubagent
  • .claude/agents/design-an-app-screens.mdsubagent
  • .skill-graph/.gitignoresupport
  • .cursor/rules/design-an-app.mdcCursor rule
  • README.mdreadme
  • + 3 more subagents
.claude/skills/design-an-app/SKILL.md
---
name: design-an-app
description: "Designs an app from an idea: users, scope, screens and data model in parallel, a fresh-context product review that makes them fit together, then a product spec."
---

# design-an-app

Designs an app from an idea: users, scope, screens and data model in parallel, a fresh-context product review that makes them fit together, then a product spec.

This skill is a graph: each step has its own prompt and context, and only the payloads named below move between steps.

## Plan

Run the stages in order. Every model step runs in its own subagent; do not do a step's work yourself. Only command steps and approvals are yours to run. Steps in the same stage do not depend on each other: start them together, in one message with several subagent calls.

The input (`goal`) is the user's goal: their request, word for word, handed on under `### goal`. Ask for it if the user has not given one.

### Stage 1 · 1 step

- **SPLIT** (`splitter`) → subagent `design-an-app-splitter`
  - Hand it: the user's goal.
  - Expect: `subtask_json` (json).
  - Contract check (`subtask_json`): save its output to `.skill-graph/design-an-app/splitter.json`, then run `node -e "const fs=require('fs');const d=JSON.parse(fs.readFileSync(process.argv[1],'utf8'));const k=['users','features','screens','data_model'];const ok=d!==null&&typeof d==='object'&&Array.isArray(d)===false;const m=ok?k.filter((x)=>Object.hasOwn(d,x)===false):k;if(m.length>0){console.error('Missing keys: '+m.join(', '));process.exit(1)}" .skill-graph/design-an-app/splitter.json` with Bash. Exit code 0 passes.
  - If a contract check fails: re-run this step once with its previous answer and the error output. If it fails again, stop and show the user the output.

### Stage 2 · 4 steps in parallel

- **Users & Stories** (`users`) → subagent `design-an-app-users`
  - Hand it: only the `users` value from the JSON of SPLIT (`splitter`).
  - Expect: `design_proposals` (markdown).
- **Features & Scope** (`features`) → subagent `design-an-app-features`
  - Hand it: only the `features` value from the JSON of SPLIT (`splitter`).
  - Expect: `design_proposals` (markdown).
- **Screens & Flows** (`screens`) → subagent `design-an-app-screens`
  - Hand it: only the `screens` value from the JSON of SPLIT (`splitter`).
  - Expect: `design_proposals` (markdown).
- **Data Model** (`data_model`) → subagent `design-an-app-data-model`
  - Hand it: only the `data_model` value from the JSON of SPLIT (`splitter`).
  - Expect: `design_proposals` (markdown).


… 37 more lines in the kit

Or let Claude adapt it

Add Skill Graph to Claude Code as a connector, then ask. Claude loads this starter, changes it for your project, checks it and hands you the kit.

Set up the connector

Ask Claude

Use Skill Graph: get the design-an-app template, adapt it to this project, validate it until it has no errors, and compile it for Claude Code.

The graph file

The whole workflow is one Markdown file, graph.skill.md: the steps and edges in the frontmatter, one prompt per step below it. The guide explains every field.

graph.skill.md · 146 lines
---
name: design-an-app
description: "Designs an app from an idea: users, scope, screens and data model in parallel, a fresh-context product review that makes them fit together, then a product spec."
spec: skill-graph/1
topology:
  nodes:
    - id: goal
      type: input
      label: APP IDEA
    - id: splitter
      type: orchestrator
      label: SPLIT
      model: sonnet
      tools:
        - Read
    - id: users
      type: worker
      label: Users & Stories
      model: haiku
      tools:
        - Read
        - WebSearch
    - id: features
      type: worker
      label: Features & Scope
      model: haiku
      tools:
        - Read
        - WebSearch
    - id: screens
      type: worker
      label: Screens & Flows
      model: haiku
      tools:
        - Read
        - WebSearch
    - id: data_model
      type: worker
      label: Data Model
      model: haiku
      tools:
        - Read
        - WebSearch
    - id: verifier
      type: verifier
      label: VERIFIER (Fresh Context)
      isolated_context: true
      model: opus
      tools:
        - Read
        - Grep
        - Glob
      gate: Every first-version feature maps to a user story, a screen and the data it needs.
      on_fail: retry
      max_retries: 1
    - id: merger
      type: synthesizer
      label: FINAL ANSWER
      model: sonnet
      tools:
        - Read
  edges:
    - from: goal
      to: splitter
    - from: splitter
      to:
        - users
        - features
        - screens
        - data_model
      contract: subtask_json
    - from:
        - users
        - features
        - screens
        - data_model
      to: verifier
      contract: design_proposals
    - from: verifier
      to: merger
      contract: approved_design
contracts:
  subtask_json:
    format: json
    description: One key per worker id; each value is that worker's task.
  design_proposals:
    format: markdown
    description: A numbered list of proposals, each with the user need it serves and a confidence of high, medium or low.
  approved_design:
    format: markdown
    description: The proposals that fit together, then the cut ones with the reason.
---

# Node Prompts & Edge Contracts

## @node: splitter
You are the product lead. Read the idea and give each designer their part of the app, with the constraints the idea states.

Input:
{{goal}}

Output strictly as JSON with one key per worker: `users`, `features`, `screens`, `data_model`. Each value is the exact task for that worker.

## @node: users
Work ONLY on users: who they are, the jobs they need the app for, and the three most important user stories.

Your task: {{splitter.users}}

Return your proposals as a numbered list. For each one give the user need it serves and a confidence of high, medium or low.

## @node: features
Scope ONLY the features: the smallest useful first version, what waits for later, and why.

Your task: {{splitter.features}}

Return your proposals as a numbered list. For each one give the user need it serves and a confidence of high, medium or low.

## @node: screens
Design ONLY the screens and flows: each screen, what it shows, and how the user moves between them, with empty and error states.

Your task: {{splitter.screens}}

Return your proposals as a numbered list. For each one give the user need it serves and a confidence of high, medium or low.

## @node: data_model
Design ONLY the data: entities, fields and relationships, and the outside services the app needs.

Your task: {{splitter.data_model}}

Return your proposals as a numbered list. For each one give the user need it serves and a confidence of high, medium or low.

## @node: verifier
You are a product reviewer. Check that the proposals fit together: every screen serves a user story, every feature has a screen, and the data model holds what the screens show.

You only see the raw worker outputs below, not their reasoning. Cut proposals that serve no stated user need, settle conflicts between them, and list what you cut and why.

Original input: {{goal}}

Worker outputs:
{{workers.output}}

## @node: merger
Write the product spec in Markdown: Problem, Users and stories, First version scope, Screens and flows, Data model, Open questions.

{{verifier.output}}

More starter graphs

All blueprints