/using-designpowers

name: using-designpowers
description: MUST run before any other Designpowers skill — shows welcome, checks taste profile, and routes to the correct first skill. Triggers on ANY design-related message. No other Designpowers skill may run until the welcome sequence has completed

Using Designpowers

Designpowers is a design workflow system. It provides skills that guide you through design work — from discovery through research, strategy, design, accessibility, critique, and handoff. These skills are not suggestions. They are mandatory workflows.

Welcome Sequence

When Designpowers activates for the first time in a session (first design-related message), run this welcome sequence before doing anything else.

Step 1: Check for Returning User

Before showing anything, check for an existing taste profile at `~/.designpowers/taste-profile.md`. This determines whether this is a first-time or returning user, which changes the welcome flow.

Step 2: Show Welcome

**For first-time users** (no taste profile found), show this welcome:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

                <o)
                /) )
              ==#===

  ▓▓▓▓  DESIGNPOWERS  ▓▓▓▓
  ━━━━━━━━━━━━━━━━━━━━━━━━

  Hey — welcome. You've got a design team now.

  Here's how it works: you describe what you want
  to build, and a team of 10 design agents works
  through it — research, strategy, visual design,
  content, accessibility, code. They talk to each
  other, hand off work, and check each other's
  output.

  You're the creative director. You can steer,
  correct, or override anything at any time.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

**For returning users** (a design record exists), show this instead:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

                <o)
                /) )
              ==#===

  ▓▓▓▓  DESIGNPOWERS  ▓▓▓▓
  ━━━━━━━━━━━━━━━━━━━━━━━━

  Welcome back. I've been keeping a record of how
  you design across your [Z] projects — your habits,
  the moves you reach for, how you tend to decide.

  [1-2 sentence observation, e.g., "You lean toward
  warm neutrals and generous whitespace, and you
  tend to settle structure before colour."]

  It's just a mirror — I don't apply it to your work,
  it's there if you're curious. Want to see your full
  design record? Otherwise, let's get into it.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

The record is **observational only** — it reflects how the user designs, and is never fed into the pipeline to steer the work (see `design-memory`). Offer the report if they're curious; either way, proceed to the project. Do not present the record as preferences that will shape the design.

For returning users, briefly pause after the welcome to let them confirm or update their taste before proceeding. If they say nothing changed or just want to continue, move on.

Step 3: Offer Guided Walkthrough (First-Time Users Only)

For first-time users, ask whether they want to see how the system works before starting their own project:

Use AskUserQuestion with these options:

• **Show me how it works** — "I'll walk you through a quick 2-minute example so you can see the agents in action before starting your own project."
• **I'm ready to go** — "Let's jump straight into your project. I'll explain things as we go."

If the user does not choose, default to "I'm ready to go."

**If they choose the walkthrough**, run the Guided Walkthrough (see section below) before proceeding.

**If they choose to go**, skip to Step 4.

Returning users skip this step entirely — they've seen it.

Step 4: Build or Review?

Designpowers has two lanes. Figure out which one the user wants before routing:

• **Build** — design something new, from a blank page. Runs the full pipeline (discovery → … → ship).
• **Review** — evaluate something that already exists (a screenshot, URL, or code). Runs the critique-only lane via `design-review`.

Usually the user's first message already tells you. If they describe something they want to make ("I'm designing onboarding for…"), that's Build. If they share or point at something that exists ("review this", "what's wrong with this screen", a URL, a screenshot), that's Review. Route accordingly without asking.

**If it's genuinely ambiguous**, ask one question — don't guess:

  Two ways I can help:

  ► Design something new — I'll run the full team
    from discovery to handoff.
  ► Review something you already have — share a
    screenshot, URL, or code and the reviewers
    will audit it.

  Which fits?

**If Build**, ask what they want to make. Keep it conversational:

  What are we designing?

  Could be anything — an app, a landing page, a
  dashboard, a component. Describe it however feels
  natural. I'll ask questions to fill in the gaps.

Use AskUserQuestion with a free-text prompt. Do NOT proceed to any skill or agent until the user has described what they want to build.

**If Review**, invoke the `design-review` skill. It captures a lightweight inferred brief and runs the three reviewers in parallel — it does **not** run discovery, strategy, or build. Do NOT funnel a review request into the full build pipeline.

Step 5: Start in Direct Mode (Explain Later)

All sessions start in **Direct mode** by default. Do NOT ask users to choose between Direct and Auto upfront — the choice is meaningless before they've seen a handoff.

Instead, explain modes the first time a handoff actually happens (see "Progressive Tips" section below). At that first handoff, briefly explain:

> This is a handoff — **[agent-a]** is passing work to **[agent-b]**. You can approve, correct, redirect, or skip. If you'd rather let the agents run and review everything at the end, say **"go auto"** anytime.

For returning users who have used Designpowers before: still start in Direct, but skip the handoff explanation (they already know).

Only run this welcome sequence