design git:20261028.5f4a891A

Immutable. This exact content never changes and is served at /api/v1/blob/6391ac9b48c60c8c.

---
name: design
description: Create or refine interface mockups from goals, references, and feedback. Use only when explicitly invoked.
disable-model-invocation: true
---

# Hope Design

Use only when the person invokes `$hope:design`, `/hope:design`, or the
host's equivalent skill command or picker. Continue follow-ups within that
invoked task without requiring another invocation. Ordinary requests and calls
from another skill do not activate this skill; continue authorized work through
the ordinary workflow. Reading a shared reference does not invoke its skill.

Turn the person's purpose and impressions into a considered interface they can
see, try, and direct. Carry new screens, refinements, reference studies, or
comparisons through the requested result. Preserve settled choices, the parts
the person likes, and existing implementation authorization.

Read `../write/references/writing-standard.md` for language and
`references/judgment.md` for design judgment. Use the topic references below
when they affect the current work; do not read the whole library on every run.

## Establish what this work needs

Read the conversation, actual screens, representative code and content, design
rules, components, and assets. A coherent existing interface is a design system
even without a DESIGN.md. Distinguish a local refinement, a new surface inside
that system, and a requested redesign. Preserve the corresponding scope.

Understand who uses the screen, what they need to accomplish, and where it fits
in their work. Investigate what the environment can answer. Ask only unresolved
questions that change the result, in terms of actions and consequences rather
than CSS values or style names. Use visual evidence when words cannot settle
a visual choice. Follow existing decisions and delegation; a request to make a
mockup does not itself choose a material product trade-off.

An impression is a clue, not a prescription. For "cramped," inspect grouping,
density, reading width, and navigation effort before adding space. For "bland,"
inspect composition and emphasis before adding effects. Explain the likely
cause through the person's task. Read `references/exploration.md` when direction,
reference interpretation, or feedback needs work.

## Make the design inspectable

Develop and self-check a recommended direction before asking the person to do
design work. Compare alternatives when a meaningful choice remains: usually
two, with more only for a distinct consequential direction or an explicit
request. Do not manufacture alternatives for a settled or narrow correction.
Show differences through the same realistic content and comparable conditions.
Explain benefits and costs in everyday terms and identify the recommendation
as a proposal. Select only within existing delegation or the person's decision.

Use the medium that answers the question. Images can establish composition and
art direction; working UI can establish interaction, states, and adaptation.
Use both when necessary. Read `references/prototypes.md` to create, inspect,
present, and retain mockups. Use the host and project's existing tools; image
or browser unavailability is an evidence gap, never a choice or approval.

Before showing the result, check its purpose, hierarchy, content, and relevant
states in the rendered surface. Read `references/verification.md` for the
affected checks. Fix material defects within scope. A screenshot or automated
scan alone does not prove usability, interaction, or design quality.

## Refine without starting over

Connect feedback to the shown direction, region, and state. Accept ordinary
language, a pointed-out element, or an annotated image. Preserve what the person
accepted while changing the cause of the problem. When combining parts from
different options, reconcile their hierarchy, component language, and behavior.
Repeated rejection calls for a different diagnosis or comparison, not another
color swap. Do not require a fixed interview, variant count, or feedback round.

Finish when the requested scope has an inspectable result, material choices
are decided or delegated, relevant defects are resolved, and verification
limits are clear. Human preference belongs to the person; never report it as
AI-verified. Continue product implementation when it was requested and the
necessary choices are resolved. Otherwise hand off the design.

Return the result or its exact path and viewing instructions, the chosen
direction and reasons, material behavior and adaptation decisions, and what
was actually checked. Read `references/continuity.md` when choices must survive
this session or another screen or worker will rely on them.

## Work inside Align

This handoff applies when the person explicitly invokes both skills.
Align supplies the goal, target, constraints, settled choices, authority and
delegation, and unresolved visual decisions.
Use those directly. Design owns the visual exploration, mockups, feedback, and
design evidence; Align owns the overall decision frontier and agreement.

Return the shown options and paths, recommendation and reasoning, the person's
selection or delegated choice, material reference influences, and verification
limits. Return newly discovered product choices to Align with their consequences;
do not start a second product interview or recursively invoke Align. Align owns
its artifact format and persistence. A direct Design request needs no separate
Align session or artifact merely to use this process.

## Load knowledge for the work

| When it matters | Read |
|---|---|
| Purpose, hierarchy, density, generic or overworked composition | `references/judgment.md` |
| Direction, ordinary-language feedback, references, expressive variation | `references/exploration.md` |
| Images, working prototypes, comparison and element feedback | `references/prototypes.md` |
| Rendered quality, stress cases, fidelity, regression, completion | `references/verification.md` |
| Existing systems, reusable decisions, artifact ownership and handoff | `references/continuity.md` |
| Upstream sources and the primary standards for layout, type, color, interaction, accessibility, motion, and adaptation | `references/sources.md` |

Hope keeps process guidance here and leaves craft knowledge to the model and
the primary standards. For typography, color, interaction states, keyboard and
screen-reader behavior, motion, responsive and native adaptation, and asset
production, apply current practice, verify conformance claims against the
standards linked in `references/sources.md`, and follow the project's existing
system. Diagrams and charts inside a design use ordinary tools within the
current task and keep the product's visual system. Specialized image, document,
or presentation work uses the available tools for that medium under the same
scope. Design does not require an external skill installation.