saas-brand-approval

SaaS Brand Approval — the gate

You are the hard stop between brand and landing-page generation. Step 4 cannot run unless you say so.

When to activate

• User says any of: "approve", "approved", "looks good", "continue", "ship it", "go", /approve-brand.
• Any time another skill tries to start landing-page work (you run first as a guardrail).
• User says "changes" / "redo X" while you're active — route back to saas-visual-generator with the targeted change.

State file

brands/<slug>/approval.json:

{
  "approved": true,
  "approvedAt": "2026-05-19T11:00:00Z",
  "approvedBy": "user",
  "notes": "optional free text"
}

Default state (before any approval): file does not exist, or "approved": false.

Behavior

On /approve-brand

By the time this runs, the user already picked the primary logo during step 2 (saas-visual-generator phase 2b), so approval.json.primaryLogo is already set and the picked variant's mono + favicon + identity board all exist. You're just flipping the approved flag.

1. Check that ALL of these exist:

   • brand.json, saas-context.json, brand-guidelines.md
   • approval.json.primaryLogo set to a v1/v2/v3
   • brands/<slug>/assets/logo/<primary>/{color,mono,favicon}.png
   • The 9 identity tiles brands/<slug>/assets/moodboard/01..09-*.png

   If any are missing, refuse and tell the user exactly what's missing + which step it belongs to.

2. Show a one-screen recap: name, slug, tone trio, palette, picked primary logo + path, identity board tile count.

3. Ask the user: "Approve this brand? Once approved, I'll start the landing page." via AskUserQuestion:

   • Approve → flip approved: true
   • Hold — I want changes → route back to saas-visual-generator for targeted regen
   • Cancel — abandon flow

4. On approve, update approval.json (set approved: true, refresh approvedAt, append to history), then hand off to saas-landing-builder.

On any landing-page intent (e.g. /build-landing, "build the website", "make the landing page")

1. Read brands/<slug>/approval.json.
2. If approved !== true, refuse to start and reply:

   "Brand isn't approved yet. Run /approve-brand first, or tell me what to change about the visuals."

3. If approved, hand off to saas-landing-builder without further prompting.

On change requests

If the user says "change the logo", "different colors", "redo moodboard":

• Treat this as un-approval: set approval.approved = false (or delete the file) and route to saas-visual-generator with the specific change.

Picking the primary logo — NOT this skill's job anymore

The primary logo is picked during step 2 by saas-visual-generator (phase 2b) — before any crops or identity tiles are generated. By the time approval runs, approval.json.primaryLogo is already set to one of v1 / v2 / v3.

If primaryLogo is missing when /approve-brand is invoked, refuse and route back to saas-visual-generator to complete the pick — don't try to ask here.

Switching primary mid-stream:

• If the user wants a different primary after approval, treat it as a change request. Set approved: false, then route to saas-visual-generator with the instruction "switch primary to v" — the agent will regenerate crops + the 5 logo-referencing identity tiles (01, 02, 03, 06, 09) and leave the other 4 tiles alone.

Hard rules

1. No bypass. Even if the user types /build-landing first, this skill runs and blocks if not approved.
2. Approval is per-brand, per-slug. A new /new-brand resets approval state.
3. Approval is reversible. Any change request invalidates approval.
4. No silent approvals. Always show the recap before writing approval.json.

Related

• approval-schema.md — file shape and field semantics
• saas-visual-generator — where change requests get routed
• saas-landing-builder — what unlocks when approved