design-flow

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 80a50dfcaf5a · 22 Oct 2026Report an issue or request a re-scan

• Publisherjulianoczkowski GitHub userOwner of the repository this skill is read from
• Source folderjulianoczkowski/designer-skills/design-flowThe exact folder we audited
• LicenceApache-2.0As the repository states it
• Commit pinned for this verdict80a50dfcaf5aA new audit runs when the source changes
• Repository statusNot archivedLast push 107 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Run the full design-to-build workflow as a guided sequence. Orchestrates all designer skills in order, from grilling through review. Use when user wants to go through the complete design process, start a project from…

---
name: design-flow
description: Run the full design-to-build workflow as a guided sequence. Orchestrates all designer skills in order, from grilling through review. Use when user wants to go through the complete design process, start a project from scratch, run the full flow, or mentions "design flow" or "full workflow".
---

This skill orchestrates the full designer workflow by running each skill in sequence. You are a guide walking the designer through each phase. Do not rush. Each phase must be completed and confirmed before moving to the next.

## Example prompts

- "Run the full design flow"
- "Walk me through the complete process for a new project"
- "Start from scratch and take me through everything"
- "Design flow for a dashboard app"

## The Sequence

```
1. Grill Me          → Clarify thinking
2. Design Brief      → Document intent
3. Info Architecture  → Define structure
4. Design Tokens     → Establish visual system
5. Brief to Tasks    → Plan the build
6. Frontend Design   → Build it
—
7. Design Review     → Run separately when ready
```

## Rules

1. **At the start**, tell the designer what the full sequence looks like (phases 1-6, with review available separately) and ask if they want to skip any phases. Common skip patterns:
   - Already have a clear idea → skip grill-me
   - Single component, not a full page → skip information-architecture
   - Existing project with tokens → skip design-tokens

2. **Before each phase**, announce which phase you are entering and what it will produce. Example: "Phase 2: Design Brief. I'll interview you about the project and produce a DESIGN_BRIEF.md file. Ready?"

3. **During each phase**, read the corresponding SKILL.md file and follow its full instructions. Do not summarize or abbreviate the skill. Run it properly.

4. **After each phase**, summarize what was produced (the file name, the key decisions, any open questions) and ask: "Ready to move to the next phase?" Wait for confirmation.

5. **Between phases**, check if the output from the previous phase changes anything about the next phase. For example, if the brief names a philosophy, mention that the tokens phase will use it.

6. **The designer can stop at any point.** If they say "that's enough for now," summarize where they are in the sequence and what the next phase would be when they return.

## Phase Details

### Phase 1: Grill Me

Read the `grill-me` skill (grill-me/SKILL.md) and follow its instructions.
**Produces**: Shared understanding of the project. No file output.
**Transition**: "We've resolved the key decisions. Ready to capture this as a design brief?"

### Phase 2: Design Brief

Read the `design-brief` skill (design-brief/SKILL.md) and follow its instructions.
**Produces**: `.design/<feature-slug>/DESIGN_BRIEF.md`.
**Transition**: "The brief is saved. Next is information architecture, where we'll define the page structure and navigation. Skip this if you're building a single component. Continue?"

### Phase 3: Information Architecture

Read the `information-architecture` skill (information-architecture/SKILL.md) and follow its instructions.
**Produces**: `.design/<feature-slug>/INFORMATION_ARCHITECTURE.md`.
**Transition**: "IA is defined. Next we'll generate design tokens (colors, spacing, typography) based on the philosophy from the brief. Continue?"

### Phase 4: Design Tokens

Read the `design-tokens` skill (design-tokens/SKILL.md) and follow its instructions.
**Produces**: Token file (CSS variables, Tailwind config, or theme file depending on stack).
**Transition**: "Tokens are set. Next I'll break the brief into a task list so we can build in order. Continue?"

### Phase 5: Brief to Tasks

Read the `brief-to-tasks` skill (brief-to-tasks/SKILL.md) and follow its instructions.
**Produces**: `.design/<feature-slug>/TASKS.md`.
**Transition**: "Tasks are ready. Now we build. I'll start with the first task on the list. Continue?"

### Phase 6: Frontend Design

Read the `frontend-design` skill (frontend-design/SKILL.md) and follow its instructions.
Work through the tasks from `TASKS.md` in order. After completing each task, check it off and confirm with the designer before moving to the next task.
**Produces**: Built components and pages.
**Transition**: "The flow is complete. Your brief, IA, tokens, and tasks are all saved in the project. When you're ready for a design review, run `/design-review` and I'll critique the build against the brief."

**The flow ends here.** Phase 7 is not automatic.

### Phase 7: Design Review (on request only)

This phase does NOT run automatically. It only runs if:

- The designer explicitly asks for a review during the flow
- The designer runs `/design-review` separately after building

The review requires built code to examine. If no components or pages have been built yet, do not run this phase. Instead, remind the designer: "Run `/design-review` once you have something built. It will check the output against the brief."

When triggered, read the `design-review` skill (design-review/SKILL.md) and follow its instructions. The review will capture screenshots of the running application using Playwright MCP (preferred), the Cursor IDE Browser (fallback), or by asking the user to provide them manually if no browser tool is available.

**Produces**: `.design/<feature-slug>/DESIGN_REVIEW.md` + screenshots saved in `.design/<feature-slug>/screenshots/`.
**Transition**: "Review is done. Screenshots are saved in `.design/<feature-slug>/screenshots/`. If there are must-fix items, I can address them now."

## Project Files Structure

All design flow artifacts are saved under `.design/<feature-slug>/` where `<feature-slug>` is a short, lowercase, hyphenated name derived from the feature being designed. This ensures multiple features can be designed independently without overwriting each other.

```
.design/
└── <feature-slug>/
    ├── DESIGN_BRIEF.md              ← Phase 2: Project intent, goals, aesthetic direction
    ├── INFORMATION_ARCHITECT

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

1. 2026-10-22
   ✓SAFE B 89 / 100

   first audit · source 80a50dfcaf5a

Questions about design-flow

• github.com/julianoczkowski/designer-skills/tree/main/design-flow — the audited source at commit 80a50dfcaf5a and every finding aboveObserved · 22 Oct 2026

Spotted something wrong? Report a correction · Methodology