---
name: design-resource-authoring
description: Use when the user explicitly asks to generate, author, commission, iterate or recover design resources; use Open Design; create a scoped wireframe, prototype, visual candidate, component/control state study or implementation handoff; or asks to 生成设计资源, 使用 Open Design, 生成原型图, 生成高保真/低保真设计, 为开发准备设计资源, 恢复设计资源任务, or 先看一个控件/页面效果 in a Minimal Context Harness project. Do not trigger for generic design discussion, UX audits, ordinary UI implementation, local CSS fixes, durable Design Authority adoption, initial product-proposal authoring or Long-Task execution.
---

# Design Resource Authoring

Commission the smallest sufficient resource set for the user's explicit output/development scope. “Smallest” limits artifact count and surrounding scope, never material information granularity. Open Design or another selected provider owns generation; this Skill owns task-local scoping, provider adaptation, iteration, selection reconciliation and handoff preparation—not provider prompts/runtime, Design Authority, product meaning or acceptance.

## Hard boundaries

- A raw proposal, plan, brief, screenshot or existing resource is valid input. Never require or create a special intermediary planning format, and never rewrite caller-owned Source except for the one explicitly selected proposal reconciliation.
- The explicit output/development scope is a hard ceiling. Necessary surrounding context may orient the slice but cannot expand it. Report an outside-ceiling effect as existing `decision-required` with reason `scope-expansion-required`; only explicit user expansion changes the ceiling.
- Candidates are ordinary external Source. They do not select themselves, become `exact-target`, update `DESIGN.md`/Context or prove implementation acceptance.
- Keep candidate effects in a task-local buffer. Only after explicit selection or explicitly delegated selection may accepted decisions be reconciled once and idempotently into the initial proposal; never write rejected/unresolved meaning as accepted.
- Never mutate `project_context/**`, `DESIGN.md`, a Delivery Contract, production code or tests as a resource-authoring side effect.
- Do not require a prototype, fidelity pair, provider-native file, fixed directory, variant count, resource pack or one artifact per control. Reuse selected component families and group repeated controls.
- Visual resources may express user-visible interaction/presentation but cannot invent or become sole owner of business, data, permission or algorithmic rules.
- A Web/App implementation resource must be feasible on the real project substrate. DRA may enumerate Source-backed feasible realizations and blockers, but it cannot select a production owner or required realization unless an exact current marked technical Source Item already makes that choice. Role labels, same-file prose and path-only claims are not authority.
- Before commissioning a page, flow or complex control, consume controlling Product/Surface/Screen Source for target user/context, client/host, page duty, primary task outcome, primary work object/task loop, operation-object-feedback and applicable state/recovery/accessibility meaning. Separately consume `DESIGN.md` and selected exact-target/constraint Source for visual-system and selected-design conditions. If the requested direction requires durable Product/Surface/Screen/Design meaning to change, route to and update the actual owner before resuming generation; do not design against stale Source.
- Non-authoritative task-level UI/UX analysis may inform candidate comparison but cannot supply missing product or surface meaning. A Provider must not infer that meaning from a feature list, screenshot, route tree, component inventory or analysis output.
- Do not install/configure MCP, plugins, authentication or disclosure paths without separate authorization. Create no provider registry, global workflow state, authority lifecycle, scheduler or acceptance record.

## Progressive references

1. Always read [resource-selection.md](references/resource-selection.md) to fix the scope ceiling, authoritative product/surface inputs, intent, input roles, style dependency and minimum commission.
2. Read [open-design-provider.md](references/open-design-provider.md) only before live capability discovery, provider execution, Design Authority binding, source acquisition or recovery.
3. Read [downstream-handoff.md](references/downstream-handoff.md) only when selection, proposal reconciliation or downstream handoff is material. A simple unselected preview may stop without it.
4. Read [implementation-feasibility.md](references/implementation-feasibility.md) before commissioning or publishing a Web/App implementation handoff against a real repository substrate. Reference-only and non-implementation resources never load it.
5. Read [formal-selected-web-app-handoff.md](references/formal-selected-web-app-handoff.md) completely only for an explicitly final selected Web/App implementation handoff. Exploration, unselected previews, reference-only resources and non-Web/App commissions never load this reference.

For simple-preview overhead accounting, the requested preview is neither additional Provider generation nor an added tool action.

## Workflow

1. Name in-scope surfaces/flows/regions/component families/unique controls, conditions, necessary context, exclusions and intent: `exploration`, `handoff` or `selected-source-preparation`. For a page, flow or complex control, first resolve controlling Product/Surface/Screen user/context, client/host, page-duty, primary-task, primary-work-object/task-loop, operation-object-feedback and applicable state/recovery/accessibility meaning; separately resolve `DESIGN.md` and selected-target visual conditions. Keep missing meaning unresolved, route a durable owner change before generation and keep outside-ceiling impact `decision-required` rather than filling it from task analysis or expanding scope.
2. Inventory every input as `exact-target`, `constraint`, `inspiration`, current-implementation evidence or background. Report unreadable/unused material.
3. Classify the commission `style-bearing` or `non-fidelity`. Style-bearing means high fidelity/brand/visual direction/typography/color/density/component treatment/production-style prototype. IA/flow topology, low-fidelity structure and semantics-only state studies are non-fidelity.
4. For style-bearing work, read configured Design Authority and its exact-value token source. If unconfigured, stop before provider project/run creation and route the user to explicit `$design-system-authoring`; never invoke it automatically. Non-fidelity work remains allowed.
   A combined explicit request authorizes running `$design-system-authoring` first and then resuming this Skill.
   Before every style-bearing generation or material revision, use the always-read resource-selection reference to close every applicable current-slice style-application dimension as `existing-covered`, `projected`, `not-applicable` or the existing `decision-required`. No applicable dimension may be silently omitted; `decision-required`, an undispositioned dimension or Source conflict blocks the Provider run. Complete current input-bound coverage permits omitting `style_application`, while the actual envelope contains only `projected` fields; generic design-system identity or Tokens alone are not current-slice coverage. Repeat the judgment for each material revision. A simple preview performs it through the current Source/envelope action without another tool action, persistent state or fixed extra user turn.
5. For a Web/App implementation handoff, inspect current technical Source for platform, framework/runtime, UI system, token/theming adapter, component-owner roots and route-owner roots. Owner roots are current no-follow repository directories, not arbitrary identifiers. Treat every unavailable or decision-required observation as target-wide: an exact Source-backed blocker naming that observation must reach every material component-family × condition cell, and a target with no family carrier cannot hide the unresolved observation. Cover every material component-family × target × condition profile, including the complete transitive family subject closure, with at least one Source-backed feasible realization or an explicit blocker. A candidate-bearing cell requires observed non-empty component-owner roots; unresolved roots force blocker-only coverage. Exact planned-owner authorization, required realization and blocker authority use the marked-Source decision projection defined by the feasibility reference. Keep canonical design values in design resources; never put them into any feasibility prose field, while explicit technical build/test/runtime costs may retain their time units.
6. Discover only the live provider capabilities needed by the bounded commission. For a formal generation, major revision or critical regeneration, apply the provider reference's `highest_available_capability + highest_supported_reasoning_effort` policy and fail closed when eligible candidates cannot be authoritatively ranked; never infer rank from price, name, release date or list order, and never claim an effective model/effort the run cannot confirm. Give every considered resource one disposition—`selected`, `optional`, `not-needed`, `unavailable` or `decision-required`—with a reason. Ask only when a missing preference materially changes the result.
7. Bind style-bearing provider work to the adopted design-system identity, send only the scoped product/resource commission and keep provider execution, model-selection verification, Artifact readiness, Design suitability, human selection and authority adoption distinct.
8. Iterate within scope. Re-review applicable suitability checks after every material revision. A first render with no material Source, feasibility or suitability defect may be selected directly; never require a revision merely to satisfy process. Exploration returns a visible candidate after minimal sanity review. When direction review or selection is material, use the downstream owner's `Design Resource Review & Selection Stop`; it is not approval, acceptance, formal completeness or persistent state. Do not burden exploration with handoff schema, hashes, complete Fact closure or downstream validation.
9. After direction selection, preserve canonical immutable identity and editable-upstream provenance. For a selected formal Web/App handoff, complete the formal reference's closure first and return to the review stop if it exposes a new visible decision. Reconcile accepted proposal effects once only after stable formal closure; non-formal small requests retain their one-turn option.

## Conditional Design Authority stop

Unconfigured includes a missing `DESIGN.md`, the starter/status `unconfigured`, style-only prose/inspiration or no authored exact-value token source/generation direction. Say:

```text
Style-bearing design resources require an adopted project design system. Explicitly invoke $design-system-authoring to generate/select/adopt one, then resume $design-resource-authoring. I will not initialize it automatically.
```

## Routing and output

Route durable system adoption/repair to `context_uiux_design`, surface responsibility to `context_surface_contract`, ordinary implementation to the default Workflow Contract/current Goal, and machine-assurance delivery to an explicitly selected/resumed `long-task-workflow`.

Report intent-sized results: scope/context/exclusions, style gate, input roles, resource dispositions, provider/binding status, visible artifacts/locators, selection basis, immutable/editable provenance, limitations/decision gaps and proposal-reconciliation status. A formal handoff additionally reports exactly what its dedicated reference requires. Never call a failing, unresolved, incomplete or unselected result ready.