design-resource-authoringlisted

# 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. - 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 directo