project-tiny-context-harness 0.8.11 → 0.8.13

package/assets/skills/context_uiux_design/SKILL.md

@@ -1,172 +1,49 @@
----
-name: context_uiux_design
-description: Use when the user explicitly asks to establish, adopt or repair durable UI/UX Design Authority, DESIGN.md, design-system governance, visual standards, stable interaction/surface Context, Impeccable review, visual polish, frontend redesign, or when material production UI lacks sufficient or consistent Design Authority in a Minimal Context Harness project. For standalone generation of low/high-fidelity wireframes, visual candidates, a design prototype or implementation resource handoff, use design-resource-authoring instead; do not trigger this Skill solely for resource generation, routine implementation with sufficient authority, local CSS fixes, UI bugs, explicit throwaway prototypes or generic mentions of design.
----
-
-# Context UIUX Design
-
-## Package-Managed Boundary
-
-This Skill is generated by `ty-context sync` and owned by the Harness package. Do not edit the generated `context_uiux_design` Skill directly.
-
-Project-specific UI/UX and visual design rules belong in a separate project-local Skill under `<harnessRoot>/skills/uiux_design/SKILL.md`. When a project-local Skill and this package-managed Skill both apply, use the more specific project-local Skill as the primary instruction source while keeping durable conclusions in `project_context/**` and `DESIGN.md`. Keep the project-local Skill front matter `description` trigger keywords aligned with this package-managed Skill and the project `AGENTS.md` role-trigger rule; if the project adds or narrows trigger terms, update both places together so agent activation and Tiny Context guidance do not drift apart.
-
-## 目标
-
-帮助 agent 在开发工作流中审查、采纳或修复设计权威，把已经选定的界面、交互和视觉结论沉淀成可恢复的 Minimal Context 和 `DESIGN.md`，并保持实现与验证对齐。
-
-## Design Context Depth / 设计上下文深度
-
-按需使用而不是默认加载全部层级：全局体验原则；跨 surface 的 Product Surface Contract；单屏 Screen Contract；可复用的 Control interaction Context；`DESIGN.md` 视觉系统/引用解释；项目原生 authored targets；verification Context。继续使用现有 `global`、`contract`、area/subdomain、`decision-rationale`、`verification` 和 `implementation-index` 角色，不新增笼统 `design` 或 `screen` 角色。
-
-一项事实只有一个主要 owner：跨页面职责属于 Surface Context，稳定的单屏层级/交互属于 Screen/interaction Context，视觉 token/rationale 属于 `DESIGN.md`，具体构图属于 selected target，交付范围与证明属于当前任务或现有 Delivery Contract/verification。使用稳定 surface/control/target key 连接，不复制成彼此竞争的说明。
-
-## Design Source Projection / 设计资源事实投影
-
-消费已选资源时，先把每项 material fact 在内部分类为：已有 durable owner、需要更新 owner、task-local、out of scope 或 decision required；不要持久化这张映射。
-
-- `surface_flow`：长期跨页面职责进入 Product Surface Context；稳定单屏层级/region/navigation 进入 Screen Contract；本次交付路径留在任务/Contract。
-- `visual_content`：长期视觉系统、token、组件族视觉规则和 rationale 进入 `DESIGN.md`；产品文案/信息语义进入 Screen/Control Context；精确构图、数值和条件差异留在 immutable target。
-- `component_control` 与 `state_interaction`：可复用的控件任务、可见性、输入/校验、状态、反馈、恢复、权限和导航语义进入 Screen/interaction Context；本次实现细节留在任务/Contract。
-- `motion`：系统级 motion/reduced-motion policy 进入 `DESIGN.md`；交互行为进入 Screen/Control Context；精确 timeline/easing/关键帧留在 target/handoff。
-- `adaptation_input` 与 `accessibility`：长期响应式、平台/input/focus/语义替代规则进入 Screen/Control Context；精确 condition/value 留在 target；可重复检查入口进入 verification Context。
-- `assets`：长期资产使用/归属政策进入 owning Context 或 `DESIGN.md`；精确文件、字节和 digest 留在 target/handoff。
-- provider provenance、source profile/dependencies、coverage/applicability cells、typed locators、交付 blockers、Claims/Assertions/Progress/Final Gate 不是 durable UI/UX Context；只有它们暴露的稳定产品决定、风险或可重复验证路径才投影到对应 owner。
-
-每个 adopted target 只能有一个 canonical adoption record。项目级、系统级或 component-family target 由 `DESIGN.md` 记录；单 screen/interaction target 由 owning Screen Contract 记录。canonical record 独占 interpretation、selection basis、immutable locator/digest、condition coverage 和 editable upstream owner/locator/update route；其他 Context、handoff 或 Contract 只保留 stable target key、canonical owner/anchor 与本层 applicability。handoff 的变化型 coverage index 不复制进 Context。
-
-## External Design Resource Consumption / 外部设计资源消费
-
-- `design-resource-authoring` 可以按明确请求在上游动态委托 Open Design 产生 flow、低保真、候选方向、组件族/独特复杂控件状态、交互原型或实现级资源；它以明确输出/开发内容为上限，在范围内补齐材料性 UI/UX 含义但不要求逐控件一份稿，不复制 provider 的提示词/模板，也不把任何资源设为全局必选。
-- `design-system-authoring` 是另一个仅显式调用的冷启动/修复 Skill：它用 Open Design 生成或选择候选，经过明确或受托选择后，把结果采纳到 canonical `DESIGN.md`、唯一 token source/direction 与 owning Context。缺少设计系统不会让本 Skill 或 `design-resource-authoring` 自动调用它。
-- 本 Skill 不承担独立资源生产。只有进入默认开发流程或 Long-Task、需要采纳稳定结论时，本 Skill 才消费这些或其他外部设计 Source。
-- 如果上游交付是用于实现的已选资源，先要求一个通过 `ty-context design-resource preflight <handoff.md>` 的 `design-resource-handoff-v1`。正式 Web/App target 必须完整取得 canonical entry、依赖闭包和 frozen-Inspector Fact manifest，并证明 `Expected Fact Universe = Canonical Resource Facts = Handoff Indexed Facts`。作者端在生成前从需求、产品语义、设计系统和目标环境推导全集；原子身份是 `subject × target × condition × variation × property`，包含组件 instance/Anatomy Part/primitive/relation、动态 population、全部适用 condition/variation 组合、完整标准/自定义属性、显式 N/A/exclusion、每个 property 要求的 Fact × method proof、设计系统 lineage、资产和 blocker。Control 是产品交互语义单位，八个 UI/UX dimension 是 roll-up，都不是 UI Fact 粒度上限；默认页面、状态汇总字符串、抽样或截断都不能代替原子枚举。精确值只留在 canonical resource，handoff 用 typed located digest、comparator/tolerance/mask、Oracle/environment 和 sensitivity policy 投影而不复制 CSS。探索候选不需要此文件；provider/preflight 只证明相对于 named Inspector/Oracle TCB 的输入闭包，不等于采纳或生产验收。
-- 候选、灵感和未选定输出不是 Context readiness 或实现权威，不能写入 selected registry；选定目标仍必须完成 UI Authority Closure 和 `Context Delta`。
-- 消费时沿 owning Context 的 surface/control/target key 到 canonical adoption record，主动打开每个受影响的 selected `exact-target`/`constraint`，而不是把登记存在视为已消费。核对产品 Source、Screen/Control Context、token owner、不可变 adopted locator/digest、完整 Fact Cell/Fact/proof/resource closure、Inspector Census、条件/variation/property 集、设计系统 effective-value/conflict lineage 以及 editable upstream owner/locator/update route；`exact-target` 每个条件必须具备整目标 layout 与 pixel Facts，否则应保持 partial `constraint` 或阻断。按 Design Source Projection 只把长期稳定且无冲突的事实写入其唯一 owner，精确值仍留在 canonical resource，不要求统一 pack、目录或工具格式。
-- 缺失、不可读、过期或冲突的 adopted resource 对受影响 claim 一律 fail closed。若 immutable adopted target 可读而 editable upstream 不可用，可以继续理解/实现既有目标，但修改资源必须保留为明确人工/外部边界。更新经 upstream 完成后生成/批准新 immutable version 并更新 owning reference，不能静默覆盖旧基线。
-- 设计资源生成本身不改 `project_context/**`、`DESIGN.md` 或 production code；定稿后只可一次性回改初始方案。设计系统采纳则由显式 `design-system-authoring` 完成。下游实现与验证仍由当前 Workflow Contract 或 `long-task-workflow` 负责。
-
-## 工作方式
-
-1. 先读取 `project_context/global.md` 和 `project_context/context.toml`，按 default area、triggers、read_when 选择相关 context。
-2. 如果项目存在 `DESIGN.md`，先读取其 Design Authority 状态、唯一 token 源/生成方向和由它 canonical owning 的项目/系统/component-family targets；screen-specific target 则跟随 pointer 读取 owning Screen Contract。仅当当前开发工作流经 UI Authority Closure 判断长期视觉体系需要采纳或修复时，按 Google `@google/design.md` 的格式创建或更新根目录 `DESIGN.md`；独立资源生成阶段不写入。
-3. 读取已有外部设计资源或其他 selected Source。若有 implementation handoff，先运行共享 preflight，再主动打开 handoff 索引的 exact/constraint 资源和 canonical Fact manifest；不能用索引、Inspector `complete`、provider 成功或 hash 替代资源消费。按稳定 subject/target/condition/variation/property/Fact/Source-item key 应用 Design Source Projection，并为每个 adopted target 确认 exactly-one canonical owner。若当前请求只是生成资源，转到 `design-resource-authoring`；不要在本 Skill 内复制 provider 生成流程或另建交付格式。
-4. 涉及 Product Surface（Web 页面、移动/桌面屏幕、游戏 UI/HUD/菜单、CLI/TUI 输出、扩展或设备界面）、前端布局、UI/UX、产品模块边界或信息放置时，把产品/页面定位检查作为前置动作：用户在这个 surface 要完成的判断、产品必须提供的信息/动作/反馈、不应常驻的信息、主层/下钻/运维/诊断/详情归属、布局和信息密度是否匹配任务。多 surface、多平台或多模块归属不清时，先读取相关 Context、搜索入口并结合已有 UI 代码/截图做信息架构 sweep，必要时使用 `context_surface_contract` 做 Surface Contract Check，再收窄到具体视觉或交互实现。该检查是下一步变更分类的输入；只有形成长期 surface 职责、信息架构、交互契约或模块边界结论时才更新 Context 或 `DESIGN.md`。
-   - 若存在 Product Surface Contract，读取并对齐 primary user question、main allows/forbids、drilldown ownership、long-task state 和 verification。
-   - 若缺失且本任务改变 durable surface responsibility，将唯一 `Context Delta` 设为 `required`，把界面职责写入 `project_context/**`；视觉 token、颜色、字体、间距、圆角和视觉 rationale 仍写入 `DESIGN.md`。
-5. 涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或加载/空态/错误态等 UI 控件时，用“控件交互框架”检查控件语义、反馈状态、校验、错误预防、可供性和信息密度；这只是通用判断框架，不是固定控件处方。
-6. 界面职责、流程归属和长期交互契约以 `project_context/**` 为准；`DESIGN.md` 负责视觉 token、视觉 rationale、唯一 authored token source/generation direction 和设计引用解释；versioned authored targets 保留在项目原生路径，代码与生成截图只说明当前实现状态。Context 决定“应该是什么”，代码和实现截图揭示“现在是什么”，代码不能静默重定义 Context。
-7. 设计判断或第一处实现编辑前，执行 UI Authority Closure，并给出唯一长期事实判断 `Context Delta: none|required`。对 affected stable surface/control/target keys，在 agent 内部逐项判断 durable surface / IA / interaction / verification constraint 已被 Context / `DESIGN.md` 覆盖、需要先更新、仅属 task-local、显式 out-of-scope 或需要真实用户决策；不要创建 `plan.md`、Task Contract 文件或 Markdown 映射表。冲突的 controlling owners 必须修正 Source/Context/target 或保留 decision required，不能让当前实现或 YAML 静默决定。
-8. 普通 UI bug、局部样式或 CSS 修复、测试修复或探索性 spike 不更新 Context，可先改代码；一旦形成长期交互或视觉结论，继续对齐或交付前必须回写 Context 或 `DESIGN.md`。不要把 Context 机械补成代码改动摘要。
-9. 如果二者冲突，显式标记为实现漂移、缺失工作或 Context 过期。
-10. 如果涉及已有 UI，优先结合代码入口、运行截图或用户提供的参考图来描述差异。
-11. 当任务涉及设计稿、重做设计、视觉方案、设计系统、visual polish、frontend redesign 或 frontend styling，且存在可扫描的 UI 代码、页面文件、构建产物目录或本地/远程 URL 时，默认运行 `npx impeccable detect <target>`；实现前可用于识别既有视觉问题，实现后或交付前用于审查结果。没有可扫描目标、命令不可用或扫描失败时，说明原因并继续。
-12. 需要长期沉淀时：
-   - 项目级体验原则和屏幕清单写入 `global.md`。
-   - 模块级 screen contract、state、interaction 和视觉约束写入对应 area / subdomain Context。
-   - 颜色、字体、间距、圆角、组件视觉 token 和视觉 rationale 写入 `DESIGN.md`。
-   - 新 UI context unit 可新增 `project_context/areas/<unit>.md`，并更新 `global.md#Context Index`；复杂项目同时更新 `project_context/context.toml`。
-   - 如果 `upgrade` 自动把深层 `.md` 注册成 area，但语义上更像 foundation / contract / archive，后续应显式调整 manifest role；不要依赖自动迁移判断语义。
-13. Context 只能声明设计验收入口或 smoke 入口，不能伪造“已验证通过”。
-14. Verification / Deployment Role Context 只记录长期可复用的设计验证、smoke、部署或运行初始化路径事实：特殊准备、最短命令或路径、预期阶段 / 信号、可接受 warning、已排除的重复探索点。不要记录一次性测试日志、完整输出、临时 JSON、CI artifact、测试报告、release ledger、secret、token、cookie、device id、raw payload 或完整截图报告。
-15. 收尾时做 `Contract Conformance` 和 Context drift check，只报告轻量状态：`Context: 已更新 ...` 或 `Context: 本次无长期事实变化`。Conformance 说明本次契约满足情况、未满足或延期项和截图 / 手动检查入口；一次性证据、截图结果、测试日志、任务契约和实现摘要不写入 Context。
-
-## 内部执行约束与 Conformance
-
-- `Context Delta` 只能是 `none` 或 `required`。`required` 先更新 owning Context 或 `DESIGN.md`；`none` 按现有事实工作，不制造 Context 噪音。
-- Agent 内部计划应保持页面 / 组件任务、用户判断、主辅信息归属、动作层级、输入语义、loading / empty / no-results / stale / error / degraded / success 状态、布局稳定性、非目标与验收入口清晰。
-- 触及 Product Surface 时，同时保持 surface platform、primary user question、main allows/forbids、drilldown ownership、long-task state requirement 和 verification 清晰；字段、枚举、JSON 和截图仅是实现证据。
-- 当 Product Surface 粒度不足以支持 material screen 时，使用 `screen-contract.md` 的按需结构保持 entry/exit/shared state、information hierarchy、regions、fixed/scroll/overlay ownership、navigation/variants 和 material controls 清晰；局部样式修复不补建 Screen Contract。
-- 外部来源的重要约束在内部分类为 Context / `DESIGN.md` 已覆盖、已更新、task-local、显式 out-of-scope 或需要用户决策；存在未处理项时不能声称全量完成。
-- 默认流程不要求或验证固定 `plan.md`、Task Contract 文件、Source-to-Context 表、Context-to-Implementation 表、matrix、verdict 或 evidence ledger；可选 scratch 没有固定名称或权威。
-- `Contract Conformance` 直接检查 controlling Context / `DESIGN.md` 是否到达正确 surface、状态、交互与验证路径并避开 forbidden shortcut。实现偏差修实现；缺少长期事实则返回 `Context Delta: required`，先更新长期事实再对齐。
-- small code task、普通 UI bug、局部 CSS 修复、小重构、测试修复或探索性 spike 不创建额外流程 artifact。
-
-## 信息呈现校准
-
-- 页面设计先回答：产品/页面定位是什么、要解决什么问题、用户需要什么、页面需要提供什么内容/能力/反馈；再决定元素放什么、放哪里、为什么。这是页面变更前置判断，不是实现后的视觉润色。常驻元素应证明它比位置、图标、状态、数据或交互提示更能省注意力。
-- 追求有效信息密度，而不是塞满页面。判断标准是更少无效 chrome、更少解释、更靠近真实内容和可执行动作；警惕用大标题、大容器、空卡片、假摘要或装饰区块制造仪式感。
-- 对返回、刷新、同步、关闭、搜索、展开/收起等熟悉动作，比较 icon-only、紧凑控件、文字按钮和图标+文字哪种最省注意力；如果使用 icon-only，必须保留 `aria-label`、`title`、tooltip 或 hover/focus 说明。动作不熟悉、风险高或需要区分多个相近命令时，文字通常更合适。
-- 常驻文字要克制。用户已经知道且不帮助行动的页面标题、面包屑、说明句或分区名，先判断是否可以删除，而不是先润色；必要解释可进入 tooltip、hover/focus 展开层、空态、详情页、帮助或 Context。
-- 空间应由内容价值支撑。内容少时布局可以收缩到内容附近；警惕保留一整行只有几个字的 header、空指标槽、空列表容器或没有真实数据支撑的摘要。
-- 信息架构按归属放置：真正跨页面的动作可放系统级 chrome，模块动作放模块内部，运维/连接/缓存/后台任务状态只在影响用户判断或行动时进入主工作面，低频系统解释放详情、日志、调试视图或文档。
-- 空态、加载态和错误态必须真实。不要用 fixture、看似真实的 fallback 行或“这里不展示示例数据”这类元说明遮住没有数据；筛选无结果、系统无数据和连接失败要视觉上可区分。
-- 页面稳定性是 UX 合同。滚动条出现、列表加载、tab 切换、虚拟列表高度变化、面板展开收起都不应导致布局跳动；需要时预留 `scrollbar-gutter`、稳定容器尺寸、固定关键控件尺寸和可预测的 loading skeleton。
-- 文案服务任务，不解释设计。主界面避免内部黑话、实现边界说明、生产/示例数据规则和后端来源说明；必要技术细节放到详情、日志、调试视图或运维区域。
-
-## 控件交互框架
-
-- 当界面涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或状态反馈时，先判断控件承载的交互语义，而不是直接沿用后端字段形态。
-- 判断输入数据是自由文本、枚举、实体选择、时间/区间、数量/预算还是规则配置；不同语义需要不同的可供性、约束、校验和错误恢复。
-- 明确用户完成动作前后需要的反馈状态：loading、empty、no results、error、disabled、saving、success 和 validation feedback 应该支持用户判断下一步。
-- 检查控件是否给足单位、范围、默认值、示例、推荐值、风险/成本/影响提示；解释应靠近决策点，低频细节可以进 tooltip、详情或帮助。
-- 检查可见标签、helper text、错误文案和状态文案是否是用户语言，而不是内部字段、接口名或枚举名。
-- 自由输入不是禁用项，但要和错误成本匹配：当格式固定、错误代价高或反馈复杂时，应考虑更明确的约束、选择机制或校验反馈。
-- 不把本框架读成固定控件清单：搜索是否自动触发、时间是否用 picker、预算是否用 stepper，都应由数据规模、API 成本、用户任务、错误成本和项目组件体系决定。
-
-## 视觉质量校准
-
-- 先判断界面 register：品牌页、营销页、作品集等让设计承载表达；产品工具、后台、dashboard、表单等让设计服务任务。品牌界面可以更强烈地使用图像、色彩和编排；产品界面优先可扫读、稳定组件、熟悉交互和任务效率。
-- 已有 UI 优先保持身份连续性：先找现有 token、组件库、全局 CSS、Tailwind config、截图或代表性页面；除非用户明确要求重设计，不要推翻已建立的字体、颜色、组件语言。
-- 绿色地设计视觉体系时，先说明场景和色彩策略，再选 token：谁在什么环境下使用、界面应该 restrained / committed / full palette / drenched 到什么程度。不要按品类套默认审美。
-- 做设计方案或视觉规范时，显式检查：文字对比度、65-75ch 正文行长、清晰字号层级、响应式边界、44px 触控目标、焦点态、hover/active/disabled/loading/error/success 状态、空态/错误态/长文本、reduced motion 和文本不溢出。
-- 避免常见 AI 视觉反模式：嵌套卡片、无意义玻璃拟态、紫蓝渐变或渐变文字、灰字压在彩色背景上、默认米色/奶油色大背景、过度圆角、边框加大模糊阴影的幽灵卡片、每段一个圆角 icon tile、每节重复小号全大写 eyebrow 或 `01 / 02 / 03` 标记、bounce/elastic easing、空泛营销 buzzword。
-- 视觉审查时先分清问题类型：a11y / responsive / theming / interaction / copy / performance / anti-pattern。把真正影响用户理解、操作或品牌信任的问题列为高优先级；少量纯审美偏好不要淹没关键问题。
-- Harness 默认携带 Impeccable CLI 能力；做设计稿、重做设计、视觉设计方案、设计系统方案、frontend redesign、visual polish 或既有 UI 视觉审查时，默认尝试运行 `npx impeccable detect <target>` 作为辅助证据，不必等待用户点名。其输出只能作为设计缺陷线索，不是 Harness gate，也不能替代人工截图检查、项目测试或 `validate-context`。
-
-## Design Authority Readiness / 设计权威就绪
-
-Use this check before material production UI: a new or redesigned screen, primary layout/navigation/theme/component system, high-fidelity implementation or substantial visual polish. Routine implementation with sufficient authority, local style fixes and explicit throwaway prototypes stay on the lightweight path.
-
-Configured is system-level visual authority only, not surface implementation-ready status. `DESIGN.md` 被识别为 configured 只说明项目级视觉系统不是 starter，不表示任一页面已可高保真实现。affected surface 还必须拥有充分的 Screen/Control meaning、覆盖该 claim 的 selected target/constraints、唯一 token source 和项目可执行的验证路径；任何缺失都按 UI Authority Closure 路由，而不是伪造一个全局 readiness 状态。
-
-- Read the owning surface/interaction Context, `DESIGN.md`, the authored exact-value token source and generation direction, existing production components/routes and every affected selected exact/constraint resource through its immutable locator; also resolve its editable upstream/update route before authoring a resource change.
-- Classify each reference as `exact-target`, `constraint` or `inspiration`. Record the affected surface/route/component, project path or URI and relevant viewport/theme/mode/state. Exact targets authorize fidelity comparison only for those conditions; constraints authorize only their named rule; inspiration proves no reproduction claim.
-- Treat a missing `DESIGN.md`, its package starter with Design authority status: `unconfigured`, style-only prose, an inspiration-only set or conflicting references as insufficient authority for invented production layout.
-- If the user explicitly asks to initialize/generate/select/adopt the project design system, use the explicit-only `design-system-authoring`; never infer it from a missing starter. If the user explicitly delegates standalone resource generation, use `design-resource-authoring`. Style-bearing resources must stop on unconfigured authority and bind the adopted Open Design system; low-fidelity/IA/semantics-only resources remain lightweight. After final selection, resource authoring may reconcile accepted decisions into the initial proposal once, but this downstream Skill adopts durable target meaning only after UI Authority Closure.
-- Never use the implementation's own generated screenshot or diff as the target it claims to match. A target is selected Source; an implementation render is evidence. Baseline replacement requires deliberate review and cannot merely erase a failure.
-- Keep resource integrity and implementation conformance separate: a valid file hash, provider extraction/export, registry entry or resource count proves only acquisition/integrity, not that the production route/component renders or behaves like the selected target under the declared conditions.
-- Do not require Figma, a fixed `docs/design/**` tree, an image for every local change or a universal numeric pixel tolerance. For a selected `exact-target`, however, require project-owned condition-specific full-target layout and pixel comparison; if the resource or oracle cannot support that claim, classify it as a constraint or blocking gap. Use project-native design assets and the smallest authority sufficient for the claimed fidelity.
-
-## Visual Delivery Coverage / 视觉交付覆盖
-
-For material design-system, redesign, high-fidelity implementation or visual-polish work, keep a task-local **Visual Coverage Set** before implementation and verification. When external design Source declares coverage, reconcile it with current delivery scope rather than creating competing authority. The downstream working set remains internal planning, not a required file, matrix, Context role, workflow artifact or completion authority.
-
-- Start from the complete set of combinations that authoritative Source, selected targets/constraints and applicable Control semantics declare across production surface/route/component, viewport, theme or product mode, interaction/state, content stress and accessibility/motion conditions. Risk-proportional reasoning may prioritize execution order or add exploratory combinations beyond that authority, but must never prune a declared/applicable combination or replace it with representative/pairwise sampling unless authoritative Source explicitly narrows the scope or a project-owned proof establishes equivalence. Do not invent a Cartesian product across dimensions outside declared scope, and never claim an unchecked combination.
-- Cover relevant states such as default, hover, focus, active, disabled, loading, empty/no-results, error, success and long/extreme content. Use the project's declared viewport, contrast, target-size, reduced-motion and localization rules rather than inventing universal thresholds.
-- Keep the authority split explicit: `project_context/**` owns durable surface/interaction responsibility and `DESIGN.md` owns durable visual-system semantics and rationale. Record one authored exact-value token source and one generation direction; generated CSS/theme/export files are implementation outputs, not competing authored truth. If `DESIGN.md` is not the machine-token source, name the project-native source it governs instead of hand-maintaining the same exact values twice.
-- Map every claimed fidelity combination to its selected `exact-target` or named `constraint`; do not let the Visual Coverage Set turn inspiration or missing authority into an implicit target.
-- Inspect production components or real product routes. A detached static kit, mock, poster, marketing specimen or generated showcase may guide design review, but it cannot be the only evidence for product UI behavior or fidelity.
-- For each selected combination, identify the cold-start real-user entry journey. A first useful runnable production slice is a recommended real-entry feedback point when early localization is worth its cost, not a prerequisite for expanding implementation; deep links remain supplemental when users normally enter through a shell or navigation owner. Always rerun the affected cold-start journey on the final candidate.
-- Render and inspect the declared coverage with project-owned browser/component tests plus screenshots or manual review as appropriate. Report the combinations actually checked and any omitted or external review explicitly. A screenshot baseline may be updated only through deliberate review; replacing it merely to erase a diff is not verification.
-
-## 输出边界
-
-- 不默认创建 `.work_products/**`、UI/UX 独立文档、handoff matrix、review/test/release 文档。
-- 不要求 lifecycle phase、plan task、phase gate 或阶段 Skill。
-- 如果用户明确要求初始化/生成/选择/采纳项目设计系统，使用仅显式调用的 `design-system-authoring`；如果明确要求独立设计稿、mock、线框图、原型或 implementation resource/handoff，使用 `design-resource-authoring`。本 Skill 只在后续开发流程中采纳其他长期事实。
-- `DESIGN.md` 是视觉设计系统事实源；项目流程、模块契约和下一步动作仍以 `project_context/**` 为准。
-- 如果普通页面实现已经有充分 Design Authority，或用户只要求修复 UI bug、局部改 CSS、换颜色、明确的 throwaway prototype，或只是泛泛提到“设计 / design / user experience”，不需要触发本 Skill；durable 视觉体系/Context 采纳，或 material production UI 缺失/冲突的 Design Authority 才使用。明确要求设计资源产物但尚未进入采纳/实现流程时使用 `design-resource-authoring`。
-
-## DESIGN.md 使用规则
-
-- 使用 Google `@google/design.md` 格式：YAML front matter 存 tokens，Markdown body 存设计理由。
-- 优先包含 `name`、`colors`、`typography`、`spacing`、`rounded` 和必要 `components` token。
-- 在 `Overview` 内维护 Design Authority 状态、唯一 authored token source/generation direction，以及仅由 `DESIGN.md` canonical owning 的项目/系统/component-family target records。每条 canonical record 记录 stable id、interpretation、selection basis、immutable path/URI + digest、condition coverage 和 editable upstream/update route。screen-specific target 只记录 stable id + owning Screen Contract anchor，不在两处重复完整 metadata。不要添加 Google schema 不支持的 front-matter keys。
-- Markdown section 顺序优先为：`Overview`、`Colors`、`Typography`、`Layout`、`Elevation & Depth`、`Shapes`、`Components`、`Do's and Don'ts`。
-- 写入或修改后，如本地可用，运行 `npx @google/design.md lint DESIGN.md` 检查结构；不要把 lint 结果写成“已通过”除非本轮真实执行。
-- 需要给工程消费 token 时，可用 `npx @google/design.md export --format css-tailwind DESIGN.md` 或 `json-tailwind` 生成临时输出。
-
-## 建议沉淀位置
-
-- `global.md#UX / Screen Brief`：全局体验原则、主要屏幕、跨模块流程。
-- `areas/*.md#User / System Contract`：页面、组件、状态、交互和数据展示契约。
-- `areas/*.md#Key Constraints`：responsive、a11y、品牌/视觉边界、加载/空态/错误态约束。
-- role=`contract` Context：跨页面 / 跨域界面契约及其 durable rationale。
-- role=`decision-rationale` Context：更大或跨切面的稳定交互、信息架构或 surface ownership 取舍原因。
-- `areas/*/verification.md` 或 role=`verification` Context：UI smoke、截图验收、可访问性检查或项目自己的关键验证重复执行路径。
-- `areas/*/deployment.md` 或 role=`deployment` Context：前端部署、预览环境、运行拓扑或健康检查重复执行路径。
-- `project_context/context.toml`：复杂项目的产品域 area/context_unit、role、触发词、按需读取策略和可选边界规则。
-- `DESIGN.md`：视觉 identity、design tokens、组件视觉规则、do/don't、视觉 rationale、唯一 token source/generation direction，以及项目/系统/component-family target 的 canonical adoption records；screen-specific target 只保留 owner/anchor pointer。
-
-不要编造 rationale；仅由当前代码或截图形态反推的理由、实现摘要、PR notes、命令输出、测试通过声明、截图审查、debug 过程和 agent reasoning 不进入 Context 或 `DESIGN.md`。
+---
+name: context_uiux_design
+description: Use when the user explicitly asks to establish, adopt or repair durable UI/UX Design Authority, DESIGN.md, design-system governance, visual tokens/rationale, adopted target interpretation, UI Authority Closure, selected-design alignment, or durable visual standards in a Minimal Context Harness project. Do not trigger for product/surface responsibility, design-resource generation, ordinary UI implementation, local CSS/UI fixes, copy edits, or an unselected visual exploration.
+---
+
+# Context UI/UX Design
+
+## Ownership
+
+Own durable Design Authority only: root `DESIGN.md`, visual identity and exact-value token source/generation direction, visual rationale, canonical adopted-target interpretation/selection basis, adoption records, UI Authority Closure and selected-design alignment.
+
+This Skill does not own product goals/business rules/acceptance (`context_product_plan`), information/action/feedback and main/drilldown responsibility (`context_surface_contract`), resource generation (`design-resource-authoring`), implementation, or acceptance. Route rather than duplicate those owners.
+
+Project-specific UI/UX rules may live in `<harnessRoot>/skills/uiux_design/SKILL.md`; durable facts remain in `DESIGN.md` and owning `project_context/**`. Active Long-Task retains its one Source/Contract lifecycle and Final Gate; this Skill contributes authority closure only.
+
+## UI Authority Closure
+
+1. Read core/default and owning surface/interaction Context, root `DESIGN.md`, its authored token source/generation direction, existing production route/components and every affected selected `exact-target` or `constraint` through its immutable locator. Run `ty-context design-resource preflight <handoff.md>` before treating a formal handoff as input.
+2. Classify references as `exact-target`, `constraint` or `inspiration`. Inspiration authorizes no reproduction claim. Provider success, a hash/index or an implementation screenshot proves neither selection nor fidelity.
+3. For every affected stable surface/control/target key, classify durable meaning as Context/`DESIGN.md` covered, requiring update, task-local, out of scope or decision-required. Conflicting, missing, stale, unreadable or unselected authority fails closed for the affected claim.
+4. Confirm exactly one canonical adoption record per adopted target:
+   - project/system/component-family targets are fully owned by `DESIGN.md`;
+   - screen/interaction targets are fully owned by the owning Screen Contract, with `DESIGN.md` keeping only the stable key and owner/anchor;
+   - the record preserves interpretation, selection basis, immutable path/URI and digest, applicable conditions and editable upstream owner/locator/update route.
+5. Never overwrite an adopted baseline. Create a new immutable version/digest, review it deliberately and update the unique canonical record. An implementation render/diff is evidence and cannot become the target it claims to match.
+6. Decide exactly one `Context Delta: none|required`. Durable visual-system, token, rationale, adopted interpretation, owner/anchor or verification-route change is `required`; ordinary UI/CSS fixes that preserve authority are `none`.
+7. Route unresolved surface placement to `context_surface_contract`; route any request to generate/iterate a wireframe, prototype, visual candidate, state study or handoff to `design-resource-authoring`. Do not invoke resource generation implicitly.
+
+## Selected-design alignment
+
+For a selected implementation handoff, consume the actual canonical resource and its dependency/Fact closure; do not stop at an index or aggregate `complete` label. Preserve exact located values and design-system lineage through stable keys rather than duplicating them into Context.
+
+An `exact-target` claim requires condition-specific full-target layout and pixel comparison through a project-owned Oracle; a named constraint requires proof of that constraint only. Validate affected state, viewport/platform, theme/mode, content stress, accessibility/input and motion conditions declared by Source. Never replace declared combinations with representative/pairwise sampling unless Source narrows scope or a project-owned complete equivalence proof exists.
+
+Implementation conformance runs on the real production route/component and affected cold-start journey after the final change. Detached specimens and deep links are supplemental. Report conditions not established; resource integrity/preflight is not production conformance, and screenshot baseline replacement merely to erase a failure is forbidden.
+
+## DESIGN.md boundary
+
+Use Google `@google/design.md` compatible structure: supported YAML tokens plus Markdown rationale. Maintain Design Authority status, one authored exact-value token source/generation direction and the canonical records owned at project/system/component-family scope. Do not add unsupported front-matter keys or duplicate exact values already owned by a project-native token source.
+
+If available after a change, run `npx @google/design.md lint DESIGN.md`. Exported CSS/theme files are generated implementation outputs, not competing authored truth.
+
+Missing/unconfigured authority blocks invented style-bearing production design. Only an explicit request to initialize/generate/select/adopt the project design system routes to `design-system-authoring`; local fixes and explicit non-fidelity prototypes remain lightweight.
+
+## Output
+
+Report affected authority owners/keys, selected resource classification and condition coverage, immutable/editable provenance, closure/update decisions, implementation-alignment checks, unresolved claims and `Context: updated ...` or `Context: no durable fact change`.
+
+Do not create a UI lifecycle, resource pack, Product Surface Contract, acceptance record, fixed plan/matrix, phase or second Authority/Gate. Do not write one-time screenshots, test logs, debug notes or implementation summaries into Context/`DESIGN.md`.

package/assets/skills/design-resource-authoring/SKILL.md

@@ -1,88 +1,54 @@
----
-name: design-resource-authoring
-description: Use when the user explicitly asks to generate, author, plan, commission, or iterate design resources; use Open Design; create a scoped wireframe, prototype, visual candidate, component/control state study, implementation handoff, or the design resources needed for an explicitly named development scope from raw drafts, product/technical plans, visual briefs, screenshots, or existing design resources; or asks to “生成设计资源”, “使用 Open Design”, “生成原型图”, “生成高保真/低保真设计”, “为开发准备设计资源”, or “先看一个控件/页面效果” in a Minimal Context Harness project. Do not trigger for generic design discussion, UX audits, ordinary UI implementation without an explicit resource request, local CSS fixes, durable Design Authority adoption, initial-proposal authoring itself, or Long-Task execution.
----
-
-# Design Resource Authoring
-
-Commission the smallest sufficient set of design resources for the explicitly requested output or development scope from live Open Design capabilities. “Smallest” governs artifact count and surrounding scope, never information granularity. For a formal selected Web/App implementation handoff, first derive the complete material in-scope Expected Fact Universe from requirements, product semantics, adopted design system, target platforms and observable conditions; then require canonical resources to express it and a frozen Inspector to enumerate it. The default identity is one atomic Fact Cell—not a Product Control, page, screenshot, broad dimension row or provider summary—and exact targets additionally require condition-specific full-target layout and pixel facts. This Skill is a thin task-local planner, provider adapter, iteration guide, final proposal reconciler and handoff layer; Open Design owns generation logic and Tiny Context owns neither its prompts nor runtime.
-
-## Hard boundaries
-
-- A raw initial proposal is a valid input. Never require, invoke, regenerate or edit a Source Plan.
-- During candidate iteration, keep accepted/rejected/unresolved proposal effects in a task-local delta buffer. Only after a direction is final may this Skill reconcile the initial proposal once. Never continuously rewrite it.
-- Proposal reconciliation changes only the initial proposal: never mutate `project_context/**`, `DESIGN.md`, a Source Plan, Delivery Contract, production code or tests as a design-resource side effect.
-- Never make a prototype, wireframe, high-fidelity candidate, design-system slice, provider-native file, variant count or directory layout universally mandatory.
-- Treat the user's explicit output/development scope as the hard ceiling. Include only the surrounding context needed to design that slice.
-- Never require one artifact per control. Reuse selected component sources and group repeated controls by family; commission a dedicated study only for unique or complex uncovered meaning.
-- Do not confuse Product Control granularity with design-fact granularity. An image, text run, icon, component part, smaller visual primitive, layout relation, geometry/style/token/content/state/behavior fact remains independently material when the selected resource expresses it.
-- For a formal selected Web/App handoff, do not let initially generated output define its own obligation universe. Derive that universe before commissioning from scoped subjects, target conditions, subject-local variations and the atomic property catalog. A label such as `all-states`, one default page, representative screenshots, pairwise sampling or an Inspector `complete` Boolean cannot stand in for enumerated identities.
-- Artifact grouping and exact-value ownership remain separate: one HTML/CSS/JS/JSON/SVG source set may carry thousands of atomic facts. Exact values stay in that canonical source; the manifest, residual handoff and downstream Contract preserve typed locators, digests, comparison authority and Fact identities rather than copying CSS into a second value owner.
-- Never infer that a page frame or prototype covers states, responsiveness, accessibility or interaction it does not explicitly specify or demonstrate.
-- Exploration and unselected previews stay schema-free. Only a final selected implementation handoff requires the shared strict Markdown adapter; this is input preparation, not a resource pack or acceptance result.
-- Design resources may express user-visible interaction and presentation, but must not invent or become sole owner of business, data, permission or algorithmic rules.
-- Candidates are ordinary external Source. They do not select themselves, become `exact-target`, create Design Authority or prove acceptance.
-- Do not install or persistently configure MCP, plugins, authentication or disclosure paths without separate authorization.
-- Do not create a resource pack, provider registry, workflow state, Contract artifact, acceptance record or parallel authority lifecycle.
-
-## Read the references
-
-1. Always read [resource-selection.md](references/resource-selection.md) before deciding what to generate or whether the request is style-bearing.
-2. Read [open-design-provider.md](references/open-design-provider.md) before capability discovery, Design Authority gating, provider execution, implementation-source acquisition or recovery.
-3. Read [downstream-handoff.md](references/downstream-handoff.md) before final selection, initial-proposal reconciliation, handoff or downstream use. A simple unselected non-fidelity preview may stop before this reference.
-
-## Core workflow
-
-1. **Fix the scope ceiling.** Name in-scope surfaces, flows, regions, component families, unique controls, conditions, necessary context, exclusions and whether the intent is exploration, handoff or selected-source preparation.
-2. **Inventory inputs.** Accept initial proposals, notes, product/technical plans, visual briefs, screenshots, references and existing resources. Preserve each role as exact target, constraint, inspiration, current-implementation evidence or background; report unreadable/unused material.
-3. **Classify visual-style dependency.** Mark the commission `style-bearing` when it materially expresses visual fidelity, brand, typography/color/density, component visual treatment or a production-style prototype. Mark it `non-fidelity` for IA/flow topology, low-fidelity structure, semantics-only behavior/state studies or an explicitly non-fidelity prototype. Mixed work is style-bearing unless split into an independent non-fidelity commission.
-4. **Apply the conditional Design Authority gate.** For style-bearing work, read `DESIGN.md` and its token source. If authority is unconfigured, stop before project/run creation and tell the user to explicitly invoke `$design-system-authoring`; do not invoke it automatically. A combined explicit request authorizes running that Skill first and then resuming this one. Non-fidelity work remains allowed.
-5. **Derive the authoring obligation universe before generation.** For a formal selected Web/App handoff, start from requested Surfaces/flows, product semantics, adopted design-system snapshot and target platforms—not from whatever a first render happens to contain. Enumerate stable subjects and hierarchy for every Surface, region, overlay/system UI, component family and instance, Control, Anatomy Part/slot, primitive, text, icon, media, asset and typed multi-subject relation. Explicitly disposition every standard condition axis—platform/OS/device/form factor, exact viewport, orientation, density, Safe Area, window/fold/display/color modes, locale/language/script/direction/pseudo-localization, content/data stress, text scale, input/assistive technology, motion/transparency/contrast/bold text/button shapes, system UI/IME, permission/capability/connectivity/lifecycle—plus scoped custom axes. For each subject enumerate `variant × state × interaction_phase × presence_phase × instance_case`, including compound precedence, conditional/lazy/virtualized/portal population and exact exclusions. Apply the standard atomic property catalog across geometry, layout/scroll, typography/color/decoration/content/icon/media, interaction/navigation/motion/feedback, responsive, accessibility, assets/system and relations; add inspector-declared custom properties without weakening the standard set. The Expected Fact Universe is the exact applicable `subject × target × condition × variation × property` cell set. Every cell is covered or has an exact source/basis-backed `not_applicable`/`excluded_by_scope`; `decision_required`/`unavailable` remains blocking. Continuous widths, text pressure and animation expose breakpoints/ranges/interpolation/reflow/timeline rules rather than only sampled snapshots. Never truncate, sample, summarize the remainder or let aggregate strings such as `all-states` impersonate atomic identities.
-6. **Discover live capabilities.** Inspect the current Open Design agent/model, skills, templates, design systems, plugins and export paths. Treat absent/non-enumerable capabilities honestly.
-7. **Choose the minimum sufficient commission.** Give each considered resource `selected`, `optional`, `not-needed`, `unavailable` or `decision-required` with one reason. Ask only when a missing preference materially changes the commission.
-8. **Bind and commission through Open Design.** For style-bearing work, create or verify the Open Design project with the adopted design-system ID and require `get_project.designSystemId` to match. Send the bounded product commission and the derived obligation universe through structured MCP: require the canonical implementation source to encode every applicable atomic value/behavior and require explicit dispositions for non-applicable, excluded or unresolved cells. Use documented fallbacks only when required; if the live provider cannot emit/read a required fact family, preserve that gap as blocking rather than silently narrowing the commission.
-9. **Acquire complete canonical source and its independent Fact manifest.** For Web/App implementation handoff, require Open Design to emit a canonical machine-readable entry, the full locally resolvable dependency set and one `design-resource-observable-fact-manifest-v1` inside that closure—not only a screenshot, preview or prose spec. The manifest freezes the design-system snapshot; exact Inspector identity/version/digest or named external TCB, capabilities, input paths/digests, complete enumeration and dynamic-discovery policy; addressable resource/node/declaration/token/asset/relation/variant/state/interaction/dynamic-population Census; all condition and variation axes/combinations; subject hierarchy; property catalog; Fact Cells/Facts; value and design-system lineage; evidence; Fact × required-method proof obligations; comparator/tolerance/mask, Oracle and render-environment authority; asset bindings; blockers; and non-sampling/non-truncating collection counts/digests. Enumerate and retrieve every selected file without truncation, preserve exact bytes/digests, record one `implementation_web` or `implementation_app` source profile with `acquisition: complete`, and make all local source, token, SVG, font, image, media, worker and asset dependencies resolve inside that frozen set. Non-Web resources use the bounded `reference` profile and are not forced into HTML.
-10. **Inspect, compare and iterate to exact closure.** Run the frozen Inspector over the frozen canonical entry/dependencies. Require every Census item to map to Facts/Fact Cells or a source/basis-backed `non_material` disposition, and require the manifest Fact universe to equal the precommission Expected Fact Universe. Exercise every required verification method with its method-compatible evidence, comparator, Oracle and environment; preserve design-system token/override/conflict lineage and exact asset consumers. Iterate the provider until `Expected Fact Universe = Canonical Resource Facts = Handoff Indexed Facts` can hold. Keep provider execution, artifact readiness and design suitability separate, and keep proposal effects only in the delta buffer while candidates remain unsettled.
-11. **Finalize selection and reconcile once.** After explicit human selection or explicit delegated selection, preserve immutable identity and consolidate accepted, rejected and unresolved effects. Apply only accepted decisions once to a writable initial-proposal file; if it exists only in conversation, return one complete revised proposal. Preserve original intent/provenance and make reruns idempotent. Do not write unresolved or rejected choices as requirements.
-12. **Compile the residual implementation handoff when requested.** Keep each canonical per-target `design-resource-observable-fact-manifest-v1` as the sole complete index for Inspector inputs/Census, axes and exclusions, conditions, subjects and variations, properties and lineage, Fact Cells/Facts, evidence/proofs, Oracles/environments, assets and blockers. Do not copy those collections into handoff YAML. For each target, author one small project-native Markdown draft with readable, target-attributed `ty-source-item` facts and exactly one fenced `design-resource-handoff-v1` block whose `representation` is `manifest_backed`. The block contains only residual scope/provenance, resource identities, that one target/profile, resource-fact closure, coverage and proposal binding. Shared meaning is atomized into uniquely keyed target-attributed Source facts without dropping its original predicate or provenance. Freeze the explicit canonical manifest path set and choose an actual UTF-8 byte ceiling before draft generation. Ensure the authorized output parent already exists, then call `ty-context design-resource bundle <draft-dir> <new-output-dir> --manifest <facts.json> [...] --max-handoff-bytes <bytes>`. The command rejects embedded/full-array drafts, multi-target drafts, over-budget descriptors, missing/extra/duplicate targets, manifest path/SHA drift, invalid collection count/identity digests, any normalized preflight failure and any existing final directory; it processes one target at a time in a same-volume temporary directory and publishes the complete target set with one atomic directory rename. Validation is an invariant check on the already compact representation, never a post-hoc splitting pass. On failure only the command-owned temporary directory is removed; drafts and existing/adopted handoffs remain unchanged. Do not author the older embedded V1 representation; it remains readable only for compatibility. Preflight hydrates the omitted collections directly from the declared canonical manifest snapshot and runs the same full semantic validator, so `Expected Fact Universe = Canonical Resource Facts = Handoff Indexed Facts` remains exact without duplicate YAML. File/model/parser/memory pressure never permits pruning, sampling, truncation, coarser Facts, implicit defaults or broader exclusions. If the truthful residual descriptor cannot meet the declared byte ceiling, treat the ceiling as incompatible and fail closed; never split a semantic target. Do not create these files for exploration.
-13. **Return an intent-sized result.** Exploration shows the artifact promptly. An implementation handoff returns the atomically published handoff directory and every target/path mapping, selected immutable resources, stable-key coverage, manifest path/SHA plus collection count/identity-digest conservation, provenance, binding, limitations and successful bundle/preflight result. Include the reconciled initial proposal or its updated path when final selection occurred.
-
-## Conditional Design Authority gate
-
-Unconfigured means `DESIGN.md` is missing, explicitly says `Design authority status: unconfigured`, remains a starter, contains only style prose/inspiration, or lacks one authored exact-value token source/generation direction. This gate applies only to style-bearing resource authoring; it is not a general project-init gate and configured system-level authority does not by itself prove surface-level implementation readiness.
-
-The stop message must state:
-
-```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.
-```
-
-## Initial-proposal reconciliation
-
-The normal design-first loop is:
-
-```text
-initial proposal
-  -> bounded Open Design candidates
-  -> feedback and iteration with a task-local delta buffer
-  -> explicit or delegated final selection
-  -> one consolidated, idempotent initial-proposal reconciliation
-  -> revised proposal + selected immutable resources
-     + canonical source-rich resource set
-  -> validated residual design-resource-handoff-v1 (implementation intent only)
-  -> default Goal execution or long-task-workflow
-```
-
-Small requests may complete generation, selection and reconciliation in one turn; the invariant is one final semantic writeback, not an artificial pause. Reconciliation may clarify product information, controls/states, interaction and visual constraints supported by the selected resource. It preserves original requirements and records selected resource keys/locators/digests without turning provider output into product authority. If selection never occurs, return candidates and the buffered delta only; do not rewrite.
-
-## Stop and route elsewhere
-
-- Route explicit design-system initialization/adoption to `design-system-authoring`.
-- Route broader durable UI/UX authority repair during development to `context_uiux_design`.
-- Route ordinary implementation with sufficient authority to the default Workflow Contract and current native Goal.
-- Route a complete explicit Single-Goal delivery, using the revised proposal plus selected resources, to `long-task-workflow`.
-- If no new resource is justified, say so instead of generating filler.
-
-## Completion response
-
-Report scope, necessary context/exclusions, style dependency and gate result; selected/omitted/unavailable resources; visible artifacts/typed locators; provider, project/run and design-system binding status; review and selection basis; immutable provenance; implementation source profile, entry/dependency closure and acquisition completeness when applicable; material applicability/coverage and unresolved decisions; proposal reconciliation status/path; and forbidden inferences. For implementation intent, report the published directory, every target-to-handoff mapping, canonical manifest path/SHA and collection count/identity-digest conservation, and successful bundle/preflight result; never call a failing, unresolved or incomplete target set ready.
+---
+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.
+- 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.
+- 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, 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 [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`.
+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.
+5. 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.
+6. 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, final selection and authority adoption distinct.
+7. Iterate within scope. Exploration returns a visible candidate after minimal sanity review. Do not burden it with handoff schema, hashes, complete Fact closure or downstream validation.
+8. After final selection, preserve immutable identity and editable-upstream provenance; reconcile accepted proposal effects once. If an implementation handoff was requested, use the applicable downstream reference—and the formal reference only for selected Web/App targets.
+
+## 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.