Produce a design document proposing how to build or refactor a feature. Typically follows a brief — the brief identifies what to do, the design proposes how.

Input

The user references a task, issue, or an existing brief. Examples:

/riff:design 586
/riff:design the new checkpoint pipeline
/riff:design (in a workspace that already has a brief — design builds on it)

Process

Review context: Read the existing brief (if any), the relevant source code, and understand constraints.
Create workspace: Ensure .workspace/{id}-{slug}/ exists. Add .workspace/ to .gitignore if missing.
Write design.html in the workspace folder.

Output Structure

Title + subtitle — what is being designed
Constraints — hard requirements that shape the design (performance budgets, API compatibility, dependency limits)
Data Structures — the core data types and their relationships. This is the most important section. Show struct/class definitions with field-level commentary.
Flow — ASCII diagram showing the data flow / call sequence through the proposed design
API Surface — public functions/methods, their signatures, and one-line descriptions. Show usage examples.
Alternatives Considered — 2–3 alternatives with a one-line reason each was rejected. Table format.
Migration / Rollout — if this changes existing behavior: what breaks, how to migrate, can it be done incrementally
Open Decisions — choices that need the user's input before implementation

Style

Use the Tokyo Night dark theme. Inline the full CSS from templates/style.css as a <style> block.

Rules

HTML only, self-contained
Data structures first — lead with types, not control flow
Show concrete code for proposed APIs, not pseudocode
Flag decisions that need user input with a visible callout (use .callout class)
lang="zh-CN" — Chinese explanations, English technical terms
Footer: {project} / {identifier} / .workspace/{folder}/design.html
End with "pause for discussion" — do NOT start implementing after producing the design