SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsdesign-workflow-design

design-workflow-design

Design & creation

View repository

Updated 10-16 09:45

About this skill

Design — Creation Design Control Tower

Entry/Exit

  • Entry: 01-spec.md approved, and the task will produce user-perceivable artifacts
  • Exit: docs/features/YYYYMMDD-<name>/02-design.md + user approval; project root DESIGN.md synchronized update; pure backend/script/migration may skip
  • Points to: after design approval, enter build-workflow-plan; when design exploration is insufficient, return to define-workflow-refine
  • Output path: → build-workflow-plan
  • Preload: CANON.md
  • Must read: references/design-best-practices.md、references/design-inspiration-catalog.md、references/design-pattern-extract.md, project root DESIGN.md(if it exists)

When not to use

  • Pure backend APIs, database migrations, scripts, CI configuration, etc. do not produce user-perceivable artifacts
  • Single-line fix and does not affect any UI/documentation/visual/narrative presentation

Iron Law

Design applicability determination

Design is definitely required: document / article / deck / visual；software and involves pages/components/interaction/visual/information architecture/user paths.

Can skip: software Pure backend, pure script/migration/CI. When skipping, record:Design Status: skipped, Skip Reason: [理由]。

Core boundaries

define: define problem/goal/scope.design: finalize interaction/visual/layout/script/direction.plan: split tasks/order dependencies.build: implement artifacts. During the design phase, do not write implementation code, do not write Task N, and do not decide DB/API/service architecture.

Agent Dispatch Contract

/design Personas are selected by phase skills according to artifact_type ; personas cannot bypass this skill and directly enter plan/build.

  • agents/requirements-analyst.md: the design required / skipped determination in Step 1
  • agents/content-writer.md：document / article / deck script, narrative, and content structure design
  • agents/visual-designer.md：software + UI、deck、visual interaction, visual direction, layout
  • agents/design-reviewer.md: review 02-design.md evidence quality, boundaries, and implementation prerequisites
  • codex:codex-rescue: optional visual generation enhancement, does not replace the above personas and evidence gates

Best practice source model (4+1 layers)

  1. Enterprise Product Patterns — public patterns of mature products. Reference references/design-inspiration-catalog.md(indexes 73 real websites by domain) and references/design-pattern-extract.md(distilled high-frequency design patterns)
  2. Official Systems / Platform Rules — official design systems, platform rules, brand guidelines
  3. Methods / Theory / Style Schools — interaction, information design, typography, visual, narrative methods
  4. Anti-patterns / Verification — anti-patterns, failure modes.references/design-pattern-extract.md general Don'ts as the validation baseline
  5. Local Project Truth — current repo, brand, component library, user goals. Project root DESIGN.md is the carrier of this layer (Google Stitch token format); highest priority

External patterns can only enter Adoptas evidence and cannot directly become design decisions. When Local conflicts with external, Local prevails; external is written to Reject。

Flow

Step 1: Read spec and determine whether design is needed

Read artifact_type, target users, usage scenarios, success criteria, Scope boundaries. Determine whether there are user-perceivable artifacts and whether direction needs to be locked before implementation.

Step 2: Select design track

Scenario Needs to load
software + UI design-experience-interaction + design-visual-direction
document / article design-content-script + design-content-layout
deck design-content-script + design-content-direction + design-content-layout
visual design-visual-direction + design-content-layout

Step 3：Design Best-Practice Scan

Execute creation and presentation-layer scanning around the current track: Interaction (flow/state/information architecture), Visual direction (brand/visual system/hierarchy), Layout (grid/composition/reading path), Script (narrative structure/message line), Direction (page order/reveal/rhythm).

Inspiration source priority: design-inspiration-catalog.md → design-pattern-extract.md → project root DESIGN.md → Web search fallback.

Fixed output: Design References / Pattern Synthesis / Design Inferences / Adopt / Reject / Design Evidence Quality. When retrieval is unavailable, record Search unavailable, and when key decisions still lack evidence, STOP.

Step 3.5: Codex visual generation + Token extraction (optional enhancement)

codex:codex-rescue agent is available, and artifact_type is software(with UI),visual or deck . Artifacts include mockup PNG and assets/design-tokens-extracted.json. When execution is needed, read visual-generation.md。

Step 4: Produce 02-design.md

must include: design source evidence, pattern synthesis, design inferences, Adopt / Reject, evidence quality, design goals, key decisions, design boundaries, design approval criteria, implementation prerequisites, and type-specific design content.

Multiple options (visual comparison applicable): software(with UI),visual、deck produce 2-3 design directions, each differentiated along the most impactful dimensions, record them independently, then proceed to Step 4.5 interactive comparison. When not applicable, produce a single draft and skip Step 4.5.

Step 4.5: Interactive visual comparison (conditional)

Execute only when Step 4 produces alternatives. Call design-interactive-preview: start local HTTP service → generate comparison HTML → multiple rounds of comparison → capture selection → refine 02-design.md → close service.

Step 5: User approval

Show the design draft to the human partner, confirm direction, evidence, Adopt / Reject, missing items, and not-to-do list. Do not proceed to /plan。

Step 6: Sync project-level design constraints to DESIGN.md

Read the approved 02-design.md, extract project-level design tokens that span features and write them to DESIGN.md. For detailed merge rules, see design-sync.md。

Validation failure handling

Failure scenario Handling method
Design goal conflicts with spec Return to define-workflow-refine to revise goals or boundaries
Cannot determine whether design is needed Conservative handling: design is needed
Missing best-practice scan Supplement the scan and write Design References / Adopt / Reject
Key decisions lack evidence STOP, supplement evidence or downgrade the design decision
Design draft writes implementation steps Delete implementation steps and return to the creative decision layer
User believes the direction is wrong Keep existing judgments, revise and re-review

Common excuses

Excuse Reality Consequence
"Write the code first and adjust the design later" Creative decisions disguised as implementation details make rework more expensive. Interaction path locked in by implementation → changing direction rewrites UI >50%
"Layout/script/interaction can all be done along the way during build" Doing it along the way = no phase gates, no basis for finalization. Each developer improvises freely → visual/interaction inconsistency
"It's just a small UI, no design needed" If users can see or use it, the main path and states may need to be defined first. Skipping design → missing empty/error/loading states → users see a blank screen after launch
"Design is just writing the implementation in more detail" Design sets the direction, plan breaks down tasks, and only build lands the implementation. Confusing creative decisions with technical execution → review becomes ineffective
"A few reference cases are enough" Cases must be turned into Pattern / Adopt / Reject. Pile of inspirations → no evidence chain → key decisions cannot be traced back

Red flag — STOP

  • Start breaking down Task N when design has not been approved
  • design required but missing Sources / Patterns / Adopt / Reject
  • Sources are not layered, or key decisions cannot be traced back to evidence
  • Writing popular styles or personal aesthetics directly as design conclusions
  • in 02-design.md write test/implementation steps or commit commands
  • Cramming API / schema / service architecture decisions into the design phase
  • Only discussing "whether it looks good", not discussing user paths, pacing, hierarchy
  • software UI tasks proceed without a design draft into /plan

Verification checklist

  • has determined design required / skipped
  • when required, has generated 02-design.md
  • when required, Design Best-Practice Scan has been completed
  • 02-design.md includes Design References / Pattern Synthesis / Design Inferences / Adopt-Reject / Evidence Quality
  • key decisions can be traced back to source evidence or Local Project Truth
  • contains no implementation steps or task breakdown
  • The user has approved the design, or the skip reason has been clearly recorded
  • when required: DESIGN.md has been synced

Output template

### Design 交付记录 — <feature-name>

**Design Status**: [required / skipped — 跳过原因]
**artifact_type**: [software / document / article / deck / visual]
**设计轨道**: [交互 / 视觉方向 / 排版 / 剧本 / 导演]

**Design Best-Practice Scan**:
- Design References: [来源列表]
- Pattern Synthesis: [综合模式]
- Adopt / Reject: [采纳/拒绝清单 + 理由]
- Evidence Quality: [评分 / 来源数]

**关键决策**: [决策1 / 决策2 / ...]
**设计边界**: [不做清单 + trade-off]
**实施前置条件**: [前提条件列表]
**用户批准**: [已批准 / 待批准]
**DESIGN.md 同步**: [已同步 / 未同步]