Design Discovery Ideation

---
name: design-discovery-ideation
description: Use when the operator asks for options, variations, alternatives, product/UI directions, or divergent ideation before a spec or decision is locked. Do NOT use for deterministic edits, post-lock implementation changes, simple bug fixes, or AI Developer invention of new product direction.
source_inspiration: conceptual-only
license_status: clean-room-original
fusebase_flow_version: 3.1
risk_level: medium
invocation: automatic
expected_outputs:
  - option brief in chat or clarify conversation
  - alternatives matrix for spec.md or decisions.md
  - selected direction handoff to implementation-planning
related_workflows:
  - eight-phase-flow.md
  - architect-escalation.md
hook_dependencies:
  - none
---

# Design Discovery Ideation

> **Style:** Mode-B-lite. Divergent product/UI exploration before decisions lock; no production code.

## Purpose

Help the Product Owner turn "show options" / "try approaches" requests into clear, bounded alternatives before implementation. The skill separates fixed constraints from open design dimensions, presents 2-4 meaningfully different directions, and feeds the chosen direction into `spec.md` or `decisions.md`.

## When to invoke

- Operator asks for options, variations, alternatives, ideas, directions, or other possible shapes.
- A UI, workflow, prompt, dashboard, or product behavior needs divergent exploration before lock.
- `requirements-specification` finds unclear product framing or user experience scope.
- `implementation-planning` needs real alternatives for a decision instead of a single recommendation.
- Architect escalation is active and the design space spans multiple files, flows, or constraints.

## Do not invoke when

- The task is a deterministic bug fix with known expected behavior.
- A relevant decision is already LOCKED; AI Developer must implement or stop and surface a conflict.
- Operator asks for direct implementation, not option discovery.
- The only requested change is a narrow styling tweak with no product/design ambiguity.
- Required context is unavailable and cannot be inspected read-only.

## Required inputs

| Input | Where it lives | If missing |
|---|---|---|
| Operator intent | chat, backlog ticket, or `spec.md` | Ask one chat-text clarify question; no popup tools |
| Affected surface | file paths, route, workflow, prompt, component, or user journey | Identify likely surface with read-only search; if unclear, ask |
| Constraints | `AGENTS.md`, `docs/constitution.md`, policies, locked decisions | Read before proposing options |
| Current implementation/context | repo files, screenshots, docs, logs, or operator description | Note confidence level; avoid over-specific recommendations |
| Frontend/product inputs (if applicable) | routes, components, data contracts, API helpers, brand/source assets | Mark unknown; do not invent product surface |
| CLI edition map, for Fusebase Apps work | `docs/fusebase-cli-edition.md` | Continue with Flow-only ideation, but mark CLI UI/runtime assumptions unknown |
| Decision owner | operator via PO | Never lock the choice on the operator's behalf |

## Procedure

1. Confirm role boundary.
   - Product Owner owns ideation and option recommendation.
   - Architect escalation may deepen read-only investigation.
   - AI Developer may only flag underspecified or conflicting design and return to PO.
2. Understand the current surface:
   - User goal and workflow position.
   - Information collected or shown.
   - Interaction states and failure states.
   - Existing structure and neighboring screens/prompts.
   - Constraints from spec, constitution, policies, accessibility, platform, and locked decisions.
   - For Fusebase Apps UI/product work, supporting CLI guidance from `app-ui-design`, `app-dev-practices`, or another relevant CLI skill named in `docs/fusebase-cli-edition.md`.
3. Separate design space:
   - **Fixed:** cannot change without violating scope, constraints, or locked decisions.
   - **Assumed:** current shape that may be changed if operator chooses.
   - **Open:** dimensions worth exploring.
4. Pick 2-3 exploration dimensions that matter for this ticket. Examples:
   - Structure / flow order.
   - Content hierarchy / semantic framing.
   - Interaction behavior / state progression.
   - Visual tone / density when UI-facing.
   - Technical approach only when it changes product trade-offs.
5. Produce 2-4 options. Each option must have:
   - A short name.
   - Design hypothesis.
   - What changes.
   - What stays fixed.
   - Trade-off.
   - Verification or smoke implication.
6. For frontend/UI tickets, also draft an implementation-ready design brief:
   - Product identity and target user.
   - Selected option or option set.
   - Affected routes, pages, workflows, prompts, or components.
   - Data types, fields, states, and real interactions the UI must support.
   - API/helper surfaces by name/signature when known.
   - Applicable stack conventions or project-local frontend rules by path when known.
   - Stable test selector strategy for interactive and meaningful dynamic elements.
   - Trust-critical flows that must work with real behavior, not placeholders.
   - Brand/source inputs, only when provided or gathered from approved read-only sources.
   - Explicit non-goals: routes, entities, workflows, or visual constraints the implementer must not invent.
7. Recommend one option in chat text with **(Recommended)** marked. Do not use popup / clickable menu tools.
8. Wait for operator direction:
   - If approved, write the selected direction into `spec.md`, `clarify-conversation.md`, or `decisions.md` as appropriate.
   - If redirected, revise the options without preserving stale discarded content in authoritative artifacts.
   - If unresolved, leave status DRAFT / PENDING and name the blocking question.
9. If delegated investigation is useful, invoke `task-delegation` with a read-only/doc-only brief. The brief must include the selected exploration dimensions and forbid code edits unless the session is AI Developer and the task is already locked.

## Output artifacts

| Artifact | Path or location | Mode |
|---|---|---|
| Option brief | chat text | Mode A |
| Clarify record | `docs/specs/<slug>/clarify-conversation.md` | Mode B |
| Decision alternatives | `docs/specs/<slug>/decisions.md` | Mode B |
| Spec updates | `docs/specs/<slug>/spec.md` | Mode B |
| Implementation-ready design brief | `docs/specs/<slug>/decisions.md` or implement handoff | Mode B |
| Delegation brief | chat or handoff section | Mode-B-lite |

## Failure cases

| Failure mode | Detection | Response |
|---|---|---|
| Options are just reskins | Same structure, hierarchy, and behavior across all options | Redraft around a stronger dimension before presenting |
| Hidden locked decision | `decisions.md` already fixes the disputed direction | Stop; ask whether to redirect the decision |
| AI Developer invents new direction | Implementation diverges from locked spec/decision | Stop under IM.2 and return to PO |
| Frontend brief omits real interactions | UI work would rely on placeholders for primary actions | Amend brief with data/API/trust-critical flows before handoff |
| Frontend brief omits selector strategy | UI smoke would rely on brittle selectors | Add stable selector guidance before handoff |
| Operator wants only one answer | Operator says "just pick" | Recommend one option, but ask for explicit lock per FR-11 |
| Design space is too large | More than 4 plausible options or multiple workflows | Split into narrower decisions or invoke Architect escalation |

## Escalation path

- Cross-cutting product/workflow change -> `workflows/architect-escalation.md`.
- Need implementation sequencing -> `flow-skills/implementation-planning/SKILL.md`.
- Need smoke criteria for a UI/operator-facing outcome -> `flow-skills/smoke-testing/SKILL.md`.
- Need parallel read-only analysis -> `flow-skills/task-delegation/SKILL.md`.

## Prototype before build

Use when a UI / screen / app is about to be implemented and the operator would benefit from *seeing* it before code is written — cheap visual agreement avoids expensive rebuilds.

| Step | Action |
|---|---|
| 1. Mock in markdown | Draw the layout as an ASCII/box mockup in chat (Mode A) — structure, key elements, states. No code. |
| 2. Get feedback | Operator reacts to the mockup; iterate in chat until the shape is agreed. |
| 3. Optional HTML prototype | If a richer preview is needed, build a single throwaway static HTML page of the screen for visual testing — clearly a prototype, not the implementation. |
| 4. Then build | Only after the visual is agreed, hand the agreed shape to `implementation-planning` -> AI Developer. |

Pre-build prototyping is a generic technique (no project artifact needed). Keep prototypes disposable; the real build follows the locked direction. ASCII mockups belong in chat (Mode A), never embedded in Mode-B artifact files (FR-08).

## Anti-patterns

- Do not write production code from this skill.
- Do not treat an HTML prototype as the real implementation — it is throwaway.
- Do not present only one option unless the operator explicitly narrowed the choice.
- Do not produce alternatives that differ only by color, wording, or spacing unless the operator asked for that narrow axis.
- Do not prescribe exact UI structure, colors, typography, spacing, or component patterns unless the operator explicitly made them constraints.
- Do not let UI implementation briefs omit real data, states, and primary interactions.
- Do not bury the recommendation in prose; mark it clearly.
- Do not lock a direction without operator approval.
- Do not use popup / clickable menu tools; options must be written in chat text per FR-19.
- Do not let AI Developer use ideation to bypass locked decisions.

## Clean-room note

Original Fusebase Flow content. Derived from operator-provided capability requirements and generalized into repo-local workflow discipline; no third-party code, prompts, skill files, or hook scripts are copied. See `docs/source-map.md`.