project-tiny-context-harness 0.8.11 → 0.8.13

package/assets/skills/design-resource-authoring/references/resource-selection.md

@@ -1,153 +1,139 @@
-# Dynamic Resource Selection
-
-Use this reference to derive a bounded design-resource commission from the actual request. It is a decision model, not a fixed production sequence.
-
-## 1. Establish the scope ceiling
-
-Extract the smallest explicit output or development boundary before interpreting the background:
-
-- subject: one control/component, one region, one page, named pages, a flow or a reusable system;
-- development coverage when the resource is an implementation handoff: named surfaces/routes, regions, component families, unique controls and conditions that will actually be built;
-- platform and viewport when known;
-- modes, states and transitions explicitly requested;
-- fidelity or editability requested, if any;
-- exclusions such as “other pages not included,” “preview only,” “no Figma” or “do not update files.”
-
-Rich background improves a bounded artifact. It never authorizes more artifacts. Necessary surrounding context may show where a partial feature lives, but it does not place the rest of that page or product in scope. If the user supplies a complete app plan but asks to preview one button, generate at most the one-control resource. If the user asks for design resources for one development slice, cover that slice through its material controls and conditions, not the whole background product.
-
-## 2. Choose the intent
-
-| Intent | User decision being supported | Default stopping point |
-| --- | --- | --- |
-| `exploration` | “What might this look or feel like?” | Visible scoped candidate plus minimal sanity review |
-| `handoff` | “Can another designer/developer reliably consume this without inventing material in-scope UI/UX decisions?” | Minimum sufficient project-native resources plus scope-bound coverage, provenance, limitations and relevant checks |
-| `selected-source-preparation` | “Preserve this explicitly selected direction for later use.” | Immutable identity or approved snapshot, explicit selection basis and downstream notes |
-
-Intent and style dependency are task-local and need not be persisted. Selected-source preparation does not itself adopt Design Authority.
-
-Classify each commission before capability selection:
-
-- `style-bearing`: high-fidelity/branded output, visual-direction candidate, typography/color/density treatment, component visual specification or production-style prototype;
-- `non-fidelity`: low-fidelity hierarchy, IA/flow topology, semantics-only interaction/state study or explicitly non-fidelity prototype.
-
-Mixed work is style-bearing unless it can be split into a genuinely independent non-fidelity commission. Style-bearing work requires configured project Design Authority and an Open Design project bound to the adopted system. Missing authority stops and points to the explicitly invoked `$design-system-authoring`; it never triggers that Skill automatically.
-
-## 3. Inventory relevant input roles
-
-Preserve each supplied item's actual role:
-
-- `exact-target`: already authoritative only for its declared conditions;
-- `constraint`: a rule that controls only its stated scope;
-- `inspiration`: directionally useful but not fidelity authority;
-- `current-implementation-evidence`: evidence of current behavior, not desired behavior by default;
-- `background`: product/technical context that informs but does not expand generation scope.
-
-An optional Source Plan is one possible input. Raw notes or an initial proposal are equally valid. Never require one merely to make the other usable.
-
-## 4. Derive development-corresponding coverage
-
-For an implementation handoff, use this task-local equation:
-
-```text
-resources to commission
-  = material UI/UX decisions inside the explicit development scope
-  - decisions sufficiently covered by selected existing Source
-```
-
-A decision is material when changing it would materially change what the user sees, understands, can do or receives as feedback. Pure code structure and non-user-visible implementation choices are not design gaps.
-
-Account for the applicable meaning at each level; do not require filler for non-applicable dimensions:
-
-| Coverage level | Material UI/UX meaning |
-| --- | --- |
-| Surface/flow | information hierarchy, page/route composition, layout grid/constraints, region relationships, stacking/overlay, scrolling/overflow, navigation, branching and recovery context |
-| Visual treatment/content | typography, color, spacing, border, radius, elevation, iconography, imagery, density, exact copy/labels, formatting, localization and content presentation |
-| Component/control | anatomy, dimensions, hit area, variants, defaults, visibility/availability and mapping of repeated controls to an existing component family |
-| State/interaction | trigger/input, validation, loading/empty/success/failure/disabled/permission states, transitions, gestures, navigation result, focus/selection behavior, feedback and recovery |
-| Motion | animated property, start/end state, duration, easing, sequencing, interruption and reduced-motion behavior when motion matters |
-| Adaptation/input | viewport/breakpoint, safe area, theme/mode, platform convention, pointer/touch/keyboard behavior, orientation and content stress |
-| Accessibility | label/role, focus order/visibility, keyboard path, touch target, contrast and other applicable assistive behavior |
-| Assets | exact icons, illustrations, media, sound/haptic cues or other bespoke content whose appearance or feedback affects the result |
-
+# Dynamic Resource Selection
+
+Use this reference to derive a bounded design-resource commission from the actual request. It is a decision model, not a fixed production sequence.
+
+## 1. Establish the scope ceiling
+
+Extract the smallest explicit output or development boundary before interpreting the background:
+
+- subject: one control/component, one region, one page, named pages, a flow or a reusable system;
+- development coverage when the resource is an implementation handoff: named surfaces/routes, regions, component families, unique controls and conditions that will actually be built;
+- platform and viewport when known;
+- modes, states and transitions explicitly requested;
+- fidelity or editability requested, if any;
+- exclusions such as “other pages not included,” “preview only,” “no Figma” or “do not update files.”
+
+Rich background improves a bounded artifact. It never authorizes more artifacts. Necessary surrounding context may show where a partial feature lives, but it does not place the rest of that page or product in scope. If the user supplies a complete app plan but asks to preview one button, generate at most the one-control resource. If the user asks for design resources for one development slice, cover that slice through its material controls and conditions, not the whole background product.
+
+## 2. Choose the intent
+
+| Intent | User decision being supported | Default stopping point |
+| --- | --- | --- |
+| `exploration` | “What might this look or feel like?” | Visible scoped candidate plus minimal sanity review |
+| `handoff` | “Can another designer/developer reliably consume this without inventing material in-scope UI/UX decisions?” | Minimum sufficient project-native resources plus scope-bound coverage, provenance, limitations and relevant checks |
+| `selected-source-preparation` | “Preserve this explicitly selected direction for later use.” | Immutable identity or approved snapshot, explicit selection basis and downstream notes |
+
+Intent and style dependency are task-local and need not be persisted. Selected-source preparation does not itself adopt Design Authority.
+
+Classify each commission before capability selection:
+
+- `style-bearing`: high-fidelity/branded output, visual-direction candidate, typography/color/density treatment, component visual specification or production-style prototype;
+- `non-fidelity`: low-fidelity hierarchy, IA/flow topology, semantics-only interaction/state study or explicitly non-fidelity prototype.
+
+Mixed work is style-bearing unless it can be split into a genuinely independent non-fidelity commission. Style-bearing work requires configured project Design Authority and an Open Design project bound to the adopted system. Missing authority stops and points to the explicitly invoked `$design-system-authoring`; it never triggers that Skill automatically.
+
+## 3. Inventory relevant input roles
+
+Preserve each supplied item's actual role:
+
+- `exact-target`: already authoritative only for its declared conditions;
+- `constraint`: a rule that controls only its stated scope;
+- `inspiration`: directionally useful but not fidelity authority;
+- `current-implementation-evidence`: evidence of current behavior, not desired behavior by default;
+- `background`: product/technical context that informs but does not expand generation scope.
+
+An optional pre-existing planning document is one possible input. Raw notes or an initial proposal are equally valid. Never require a special intermediary format merely to make another input usable.
+
+## 4. Derive development-corresponding coverage
+
+For an implementation handoff, use this task-local equation:
+
+```text
+resources to commission
+  = material UI/UX decisions inside the explicit development scope
+  - decisions sufficiently covered by selected existing Source
+```
+
+A decision is material when changing it would materially change what the user sees, understands, can do or receives as feedback. Pure code structure and non-user-visible implementation choices are not design gaps.
+
+Account for the applicable meaning at each level; do not require filler for non-applicable dimensions:
+
+| Coverage level | Material UI/UX meaning |
+| --- | --- |
+| Surface/flow | information hierarchy, page/route composition, layout grid/constraints, region relationships, stacking/overlay, scrolling/overflow, navigation, branching and recovery context |
+| Visual treatment/content | typography, color, spacing, border, radius, elevation, iconography, imagery, density, exact copy/labels, formatting, localization and content presentation |
+| Component/control | anatomy, dimensions, hit area, variants, defaults, visibility/availability and mapping of repeated controls to an existing component family |
+| State/interaction | trigger/input, validation, loading/empty/success/failure/disabled/permission states, transitions, gestures, navigation result, focus/selection behavior, feedback and recovery |
+| Motion | animated property, start/end state, duration, easing, sequencing, interruption and reduced-motion behavior when motion matters |
+| Adaptation/input | viewport/breakpoint, safe area, theme/mode, platform convention, pointer/touch/keyboard behavior, orientation and content stress |
+| Accessibility | label/role, focus order/visibility, keyboard path, touch target, contrast and other applicable assistive behavior |
+| Assets | exact icons, illustrations, media, sound/haptic cues or other bespoke content whose appearance or feedback affects the result |
+
 For every material in-scope item, record one task-local disposition: `existing-covered`, `new-resource-needed`, `not-applicable`, `excluded-by-scope`, `decision-required` or `unavailable`. This accounting is reasoning/handoff metadata, not a required file, persistent coverage registry, Design Authority or acceptance result.
 
 Existing coverage is sufficient only for the conditions it explicitly specifies or demonstrates. Seeing a control in one default page frame does not cover its variants, dynamic states, feedback, motion, responsive behavior or accessibility. Conversely, a selected component source may cover many control instances, so do not commission duplicate designs merely because several stable control keys map to it.
 
 Design resources express user-visible interaction semantics and the presentation of product rules. Business, data, permission and algorithmic rules remain owned by product/technical Source; reference those rules and show their visible consequences without inventing them or making a visual artifact their sole owner.
 
-### Formal Web/App handoff granularity
+### Formal selected Web/App handoff
 
-The eight coverage dimensions above are review roll-ups, not atomic Fact identities. Before commissioning a formal selected Web/App handoff, expand the actual Expected Fact Universe:
+When—and only when—the direction is final-selected for a formal Web/App implementation handoff, load [formal-selected-web-app-handoff.md](formal-selected-web-app-handoff.md). That reference owns the complete atomic Expected Fact Universe, canonical acquisition, Inspector/Census, Fact × method proof and publication rules. Exploration never loads or approximates them.
 
-```text
-in-scope target
-× stable subject (including instance, Anatomy Part, primitive, asset and relation)
-× exact target condition
-× subject-local variant/state/interaction/presence/instance case
-× atomic observable property
-```
+## 5. Identify independent gaps
+
+For exploration, ask what remains uncertain inside the scope. For a handoff, ask which material coverage items remain `new-resource-needed`:
+
+- **structure:** information hierarchy, layout regions or page relationships;
+- **flow:** navigation, branching, recovery or multi-step sequence;
+- **behavior:** control states, transitions, gestures, feedback, loading/error/empty/disabled cases;
+- **visual direction:** composition, typography, color, density, imagery or brand character;
+- **platform/responsiveness:** safe areas, breakpoints, input methods or viewport behavior;
+- **system reuse:** tokens, component variants or cross-surface rules needed by more than the requested artifact;
+- **team editability/native inspection:** a real need for collaborative editable frames/libraries, inspectable component/token facts or an organizational native-platform handoff.
+
+Do not manufacture a gap already resolved by selected Source.
+
+## 6. Consider resources conditionally
+
+| Resource | Select when it closes this gap | Usually omit when |
+| --- | --- | --- |
+| Control/component state study | A unique or complex control has uncovered anatomy, variants, feedback, motion or edge states | A selected page/prototype or component source explicitly specifies and demonstrates the applicable conditions |
+| Low-fidelity wireframe | Hierarchy, topology or flow must be judged without visual-style distraction | Structure is settled and only visual direction is unknown |
+| High-fidelity visual candidate | Visual hierarchy, tone or composition needs selection | Existing selected targets already govern the requested conditions |
+| Interactive prototype | Transitions, navigation, state retention or task feel must be experienced | A static decision is sufficient or the provider cannot produce genuine interaction |
+| Flow/journey board | Multiple surfaces, branches or recovery paths must be compared together | The request is one isolated surface/control |
+| Design-system slice | Several requested artifacts need shared tokens/components or reuse rules | One exploratory candidate does not justify a system |
+| Component inventory/specification | Development handoff needs explicit reusable families, variants, state behavior or mappings for several control instances | Exploration is visual only, or selected component sources already cover every mapped instance |
+| Collaborative native design input | Existing team authority, editable collaboration, native component/library reuse or organizational handoff is explicitly valuable and the connector/auth/read/export path is operational | Open Design/project-native implementation source is sufficient or the native path would create a second synchronized representation |
+| Image/illustration/icon/media study | Bespoke content materially defines the selected direction | Generic placeholders answer the present decision |
+
+A prototype is often valuable for new Web/App flows, but it is never automatically required. Low- and high-fidelity resources may both be selected only when they answer independent questions. One comprehensive, inspectable artifact may cover page composition and several component families; a static frame cannot claim unseen interaction or state coverage merely because all controls appear in it.
 
-Target conditions explicitly disposition platform, OS, device/form factor, exact viewport geometry, orientation, density, Safe Area, window/fold/display/color mode, locale/language/script/direction/pseudo-localization, content/data stress, text scale, input/assistive technology, motion/transparency/contrast/bold-text/button-shape preferences, system UI/IME, permission/capability/connectivity/lifecycle and scoped custom axes. Subject-local variation includes compound precedence, conditional/lazy/virtualized/portal presence and population identity. Atomic properties include exact page assembly and geometry, layout/scroll relations, typography/color/decoration/content/icon/media, interaction/navigation/motion/feedback, responsive rules, accessibility, asset/system behavior and multi-subject relations.
-
-Every applicable cell needs a canonical value and proof obligation; every removed cell needs an exact Source/Inspector basis and `not_applicable` or `excluded_by_scope`. `decision_required` and `unavailable` block a ready handoff. A default view, one state-board label, three viewport screenshots, pairwise sample, broad dimension fact, or string such as `all-21-states` cannot replace atomic expansion. Continuous width/text-pressure/motion behavior must expose exact ranges, breakpoints, interpolation, reflow or timeline rules between captured points.
-
-This does not imply one file per Fact or one image per component. A compact canonical HTML/CSS/JS/JSON/SVG/tokens/assets set can carry the entire universe. Resource minimization is valid only when no identity or value becomes implicit.
-
-## 5. Identify independent gaps
-
-For exploration, ask what remains uncertain inside the scope. For a handoff, ask which material coverage items remain `new-resource-needed`:
-
-- **structure:** information hierarchy, layout regions or page relationships;
-- **flow:** navigation, branching, recovery or multi-step sequence;
-- **behavior:** control states, transitions, gestures, feedback, loading/error/empty/disabled cases;
-- **visual direction:** composition, typography, color, density, imagery or brand character;
-- **platform/responsiveness:** safe areas, breakpoints, input methods or viewport behavior;
-- **system reuse:** tokens, component variants or cross-surface rules needed by more than the requested artifact;
-- **team editability/native inspection:** a real need for collaborative editable frames/libraries, inspectable component/token facts or an organizational native-platform handoff.
-
-Do not manufacture a gap already resolved by selected Source.
-
-## 6. Consider resources conditionally
-
-| Resource | Select when it closes this gap | Usually omit when |
-| --- | --- | --- |
-| Control/component state study | A unique or complex control has uncovered anatomy, variants, feedback, motion or edge states | A selected page/prototype or component source explicitly specifies and demonstrates the applicable conditions |
-| Low-fidelity wireframe | Hierarchy, topology or flow must be judged without visual-style distraction | Structure is settled and only visual direction is unknown |
-| High-fidelity visual candidate | Visual hierarchy, tone or composition needs selection | Existing selected targets already govern the requested conditions |
-| Interactive prototype | Transitions, navigation, state retention or task feel must be experienced | A static decision is sufficient or the provider cannot produce genuine interaction |
-| Flow/journey board | Multiple surfaces, branches or recovery paths must be compared together | The request is one isolated surface/control |
-| Design-system slice | Several requested artifacts need shared tokens/components or reuse rules | One exploratory candidate does not justify a system |
-| Component inventory/specification | Development handoff needs explicit reusable families, variants, state behavior or mappings for several control instances | Exploration is visual only, or selected component sources already cover every mapped instance |
-| Collaborative native design input | Existing team authority, editable collaboration, native component/library reuse or organizational handoff is explicitly valuable and the connector/auth/read/export path is operational | Open Design/project-native implementation source is sufficient or the native path would create a second synchronized representation |
-| Image/illustration/icon/media study | Bespoke content materially defines the selected direction | Generic placeholders answer the present decision |
-
-A prototype is often valuable for new Web/App flows, but it is never automatically required. Low- and high-fidelity resources may both be selected only when they answer independent questions. One comprehensive, inspectable artifact may cover page composition and several component families; a static frame cannot claim unseen interaction or state coverage merely because all controls appear in it.
-
 Do not translate Product Control closure into one artifact per control. Artifact grouping is an authoring optimization, while the later implementation handoff still inventories every observable design fact inside those artifacts, including component parts and smaller primitives. Map ordinary controls to selected shared component variants, group related states in one component-family board or workbench, and reserve dedicated resources for unique or complex controls whose material meaning is otherwise uncovered.
-
-## 7. Assign a disposition to every considered resource
-
-- `selected`: required to close a current gap;
-- `optional`: useful, but not necessary for the current decision;
-- `not-needed`: redundant or outside the scope ceiling;
-- `unavailable`: justified but not currently supported/configured;
-- `decision-required`: a genuine unresolved preference changes the commission materially.
-
-Give one concrete reason. Do not turn `optional` into automatic extra work.
-
-## 8. Build the commission envelope
-
-The task-local envelope should contain only product-specific information:
-
-```yaml
-intent: exploration | handoff | selected-source-preparation
-scope:
-  subjects: [named surface/flow/region/component/control keys]
-  ceiling: one-control | one-region | one-page | named-pages | named-flow | system-slice
-  necessary_context: []
-  excluded: []
-  platform: known-or-unknown
-  viewports: []
+
+## 7. Assign a disposition to every considered resource
+
+- `selected`: required to close a current gap;
+- `optional`: useful, but not necessary for the current decision;
+- `not-needed`: redundant or outside the scope ceiling;
+- `unavailable`: justified but not currently supported/configured;
+- `decision-required`: a genuine unresolved preference changes the commission materially.
+
+Give one concrete reason. Do not turn `optional` into automatic extra work.
+
+## 8. Build the commission envelope
+
+The task-local envelope should contain only product-specific information:
+
+```yaml
+intent: exploration | handoff | selected-source-preparation
+scope:
+  subjects: [named surface/flow/region/component/control keys]
+  ceiling: one-control | one-region | one-page | named-pages | named-flow | system-slice
+  necessary_context: []
+  excluded: []
+  platform: known-or-unknown
+  viewports: []
 coverage:
   material_needs: []
   observable_fact_families: []
@@ -156,46 +142,37 @@ coverage:
   required_components_states: []
   required_interactions_motion: []
   required_adaptation_accessibility: []
-formal_handoff_obligation_universe:
-  subjects_and_hierarchy: []
-  condition_axis_dispositions: []
-  condition_combinations_and_exclusions: []
-  subject_variation_axes_and_combinations: []
-  standard_and_custom_atomic_properties: []
-  required_fact_methods: []
-  inspector_capabilities: []
-  unresolved_cells: []
 inputs:
   exact_targets: []
-  constraints: []
-  inspiration: []
-  background: []
-selected_capability:
-  kind: runtime-discovered-kind
-  id: runtime-discovered-id
-expected_entry: known-or-provider-native
-review_promise: minimal-sanity | handoff-checks | selected-source-snapshot
-```
-
-This is an explanatory shape, not a required file or schema. Never paste or paraphrase the Open Design capability's own seed/template prompt into it.
-
-## 9. Iterate and stop
-
-- Keep each revision inside the original scope ceiling unless the user explicitly expands it.
-- Reuse the current Open Design project when that preserves context and provenance; preserve the prior artifact hash before overwriting a selected candidate.
-- Do not create low-fi, high-fi, component boards or native-platform copies merely because a process diagram lists them.
-- For exploration, stop as soon as the requested decision is supported.
-- For a formal Web/App implementation handoff, stop only when the prederived Expected Fact Universe, the frozen Inspector's canonical resource Fact universe and the residual handoff's indexed universe are set-equal; every Census item and resource has an exact disposition; every Fact has all property-required proof methods; every collection proves no sampling/truncation; and no material user-visible design decision remains for the implementer to invent. An exact target also needs full-target layout and pixel Facts for every declared condition. Honest `decision_required` or `unavailable` items may stop further generation, but the result is a blocked authoring outcome: it cannot pass shared preflight, be called a ready implementation handoff or authorize fidelity work. This does not claim Design Authority or implementation acceptance.
-
-During iteration, keep accepted, rejected and unresolved implications in a task-local delta buffer. Do not require or emit an interim delta after every iteration and never continuously synchronize the initial proposal. After explicit human selection or explicitly delegated selection, consolidate the buffer once and reconcile only accepted decisions into the initial proposal. If it is a writable file, update it in place while preserving original intent/provenance; otherwise return one complete revised proposal. The operation must be idempotent, name selected artifact locators/hashes and affected stable keys, and exclude rejected/unresolved choices. Never write a Source Plan, Context, `DESIGN.md`, code, tests or Contract.
-
-## Worked scope examples
-
-- **Large draft, one filter control:** select a control-state study if anatomy and states are uncertain; omit page/flow resources.
-- **One page, style preview:** first require configured Design Authority and matching Open Design binding, then select one high-fidelity candidate; do not add a design-system pack or validator run.
-- **One page scheduled for development:** use a page/flow target for layout and context, map ordinary buttons/inputs to selected component variants, and add grouped component-state or dedicated complex-control studies only where relevant static/dynamic states, feedback, motion, responsiveness or accessibility remain uncovered.
-- **Local panel inside a large app:** include enough surrounding page context to place and size the panel, but generate detailed resources only for the panel, its in-scope controls and affected states.
-- **One comprehensive interactive artifact:** accept it as the minimum set when its sections and reachable states explicitly cover every material in-scope item; do not add duplicate control boards. If it exposes only a static/default view, commission the missing state/interaction coverage instead of inferring it.
-- **Three-screen interaction flow:** select a low-fi flow and an interactive high-fi prototype only if topology and interaction/visual behavior are independently unresolved.
-- **Local style fix with exact target:** select no new design resource and route to implementation.
-- **Initial proposal before execution:** iterate only requested candidates, keep one task-local delta buffer, then after selection reconcile accepted decisions once. Pass the revised proposal plus selected immutable resources directly to the default Goal or `long-task-workflow`.
+  constraints: []
+  inspiration: []
+  background: []
+selected_capability:
+  kind: runtime-discovered-kind
+  id: runtime-discovered-id
+expected_entry: known-or-provider-native
+review_promise: minimal-sanity | handoff-checks | selected-source-snapshot
+```
+
+This is an explanatory shape, not a required file or schema. Never paste or paraphrase the Open Design capability's own seed/template prompt into it.
+
+## 9. Iterate and stop
+
+- Keep each revision inside the original scope ceiling unless the user explicitly expands it.
+- Reuse the current Open Design project when that preserves context and provenance; preserve the prior artifact hash before overwriting a selected candidate.
+- Do not create low-fi, high-fi, component boards or native-platform copies merely because a process diagram lists them.
+- For exploration, stop as soon as the requested decision is supported.
+- For a final-selected formal Web/App implementation handoff, apply the dedicated formal reference's exact stop conditions. Honest `decision_required`, `unavailable` or capability gaps remain blocking; they cannot be called ready or authorize fidelity work.
+
+During simple iteration, keep accepted, rejected and unresolved implications in a task-local delta buffer. Do not require or emit an interim delta after every iteration and never continuously synchronize the initial proposal. If the loop requires durable semantic replay, a selected-Proposal file writeback or cross-interruption recovery, load [recovery-and-writeback.md](recovery-and-writeback.md) and use its independent origin/decision-authority/evidence/status model plus package helper; prompt prose alone cannot establish CAS or deterministic recovery. After explicit human selection or explicitly delegated selection, consolidate the buffer once and reconcile only accepted decisions into the initial proposal. If it exists only in conversation and safe materialization was not explicitly authorized, return one complete revised proposal and report cross-session deterministic recovery unavailable. Never create another intermediary planning document or mutate Context, `DESIGN.md`, code, tests or Contract.
+
+## Worked scope examples
+
+- **Large draft, one filter control:** select a control-state study if anatomy and states are uncertain; omit page/flow resources.
+- **One page, style preview:** first require configured Design Authority and matching Open Design binding, then select one high-fidelity candidate; do not add a design-system pack or validator run.
+- **One page scheduled for development:** use a page/flow target for layout and context, map ordinary buttons/inputs to selected component variants, and add grouped component-state or dedicated complex-control studies only where relevant static/dynamic states, feedback, motion, responsiveness or accessibility remain uncovered.
+- **Local panel inside a large app:** include enough surrounding page context to place and size the panel, but generate detailed resources only for the panel, its in-scope controls and affected states.
+- **One comprehensive interactive artifact:** accept it as the minimum set when its sections and reachable states explicitly cover every material in-scope item; do not add duplicate control boards. If it exposes only a static/default view, commission the missing state/interaction coverage instead of inferring it.
+- **Three-screen interaction flow:** select a low-fi flow and an interactive high-fi prototype only if topology and interaction/visual behavior are independently unresolved.
+- **Local style fix with exact target:** select no new design resource and route to implementation.
+- **Initial proposal before execution:** iterate only requested candidates, keep one task-local delta buffer, then after selection reconcile accepted decisions once. Pass the revised proposal plus selected immutable resources directly to the default Goal or `long-task-workflow`.

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

@@ -1,57 +1,57 @@
----
-name: design-system-authoring
-description: Use only when the user explicitly asks to initialize, generate, choose, adopt, replace or repair a project design system or design style with Open Design; asks for “初始化设计系统”, “生成设计系统”, “确定设计风格”, “采纳 Open Design 设计系统”, or explicitly invokes design-system-authoring in a Minimal Context Harness project. This cold-start capability never runs merely because DESIGN.md is missing, a project is new, another Skill needs visual style, or ordinary UI work begins.
----
-
-# Design System Authoring
-
-Generate or select an Open Design design system, obtain an explicit selection, and adopt that selection into the project's existing durable Design Authority. The user invokes this Skill at project cold start or later repair time; installation only makes it available.
-
-## Hard boundaries
-
-- Run only from an explicit user request. Never auto-run from `init`, `sync`, the default Workflow, `design-resource-authoring`, a missing/starter `DESIGN.md`, or a new-project inference.
-- A combined explicit user request to initialize the system and then generate resources authorizes that sequence; a resource gate alone does not.
-- Open Design owns generation, revision, previews and its catalogue. Use its live structured capabilities; do not copy its prompts, emulate its generator, vendor a catalogue or invent provider IDs.
-- Keep candidate generation, human/delegated selection and authority adoption distinct. A successful job or attractive preview is not selected and is not project authority.
-- Project `DESIGN.md` and its one declared authored exact-value token source or generation direction are canonical. An Open Design design-system record and project binding are provider synchronization, not a second authority.
-- Put durable surface, information-architecture and interaction facts in their owning `project_context/**`; put visual-system semantics, rationale, token direction and reference interpretation in `DESIGN.md`. Do not duplicate facts across owners.
-- Do not create a design registry, receipt, workflow state, Contract, acceptance gate or provider runtime inside Tiny Context.
-- Do not persistently install/configure MCP, plugins, authentication or disclosure paths without separate authorization. Task-local use of an already available Open Design MCP/daemon is allowed.
-- Do not implement production UI or claim downstream fidelity, accessibility, product correctness or acceptance.
-
-## Read the references
-
-1. Always read [open-design-design-system-provider.md](references/open-design-design-system-provider.md) before discovery, generation, revision, selection or provider synchronization.
-2. Always read [authority-adoption.md](references/authority-adoption.md) before changing `DESIGN.md`, its token source, relevant Context or provider bindings.
-
-## Core workflow
-
-1. **Confirm explicit intent and scope.** Identify whether the user wants a new system, selection from existing systems, repair, or replacement; capture the product/brand purpose, supported surface/platform, accessibility needs, required modes and supplied references. Ask only when an unresolved aesthetic or brand choice materially changes the candidates and the user has not delegated selection.
-2. **Inspect current authority.** Read core Context, relevant surface/interaction Context, `DESIGN.md`, its declared token source/generation direction and any recorded Open Design provenance. Classify the project as `unconfigured`, `configured`, or `configured-but-inconsistent`; this is a task-local finding, not new state.
-3. **Discover live Open Design capabilities.** Prefer structured MCP. List/read `od://design-systems/<id>/DESIGN.md`, inspect tool schemas, and feature-detect design-system creation/revision/acceptance plus project binding. Record the live provider/MCP version and any fallback used.
-4. **Reuse or generate candidates.** Reuse an existing provider system only when its identity and meaning fit. If a live MCP creation capability exists, use it. Otherwise use the official daemon generation-job API described in the provider reference. Keep every output a candidate until selection.
-5. **Review and iterate.** Inspect `DESIGN.md`, generated token files, preview/showcase and relevant workspace files. Use provider revision jobs for scoped feedback, poll boundedly, preserve diagnostics and keep pending revisions non-authoritative.
-6. **Obtain selection.** Require an explicit user/team selection, or an explicit instruction delegating selection with known criteria. Record the selection basis, provider design-system ID, selected revision when applicable and immutable content digest/snapshot. Reject or leave other candidates unselected.
-7. **Adopt once.** Reconcile the selected system through the authority-adoption procedure. Update root `DESIGN.md`, establish exactly one authored token source/generation direction, update only owning Context facts, and record provider provenance without making it authoritative.
-8. **Synchronize Open Design.** Accept the selected pending revision when applicable. Confirm MCP can read the adopted provider system. For later style-bearing resource work, create or verify an Open Design project with `create_project.designSystem` equal to the adopted provider ID.
-9. **Validate and report.** Run project-owned Context/design lint and source/package checks appropriate to the repository. Separately report provider execution, artifact readiness, selection, authority adoption, provider synchronization, verification and unresolved issues.
-
-## Readiness classification
-
-Treat Design Authority as unconfigured when `DESIGN.md` is absent, explicitly says `Design authority status: unconfigured`, remains an unedited starter, contains only style adjectives/inspiration, or lacks one authored exact-value token source/generation direction. A configured visual system still does not make every surface implementation-ready; selected exact/constraint targets and declared coverage remain separate.
-
-If authority is already configured and the user did not ask to replace or repair it, prefer reuse and explain the current system. Never generate a competing system as filler.
-
-## Completion response
-
-Report:
-
-- requested operation and design-system scope;
-- Open Design transport/version and capabilities actually used;
-- candidate IDs and review performed;
-- explicit or delegated selection basis;
-- adopted `DESIGN.md`, token source and Context owners changed;
-- provider ID, revision/digest and project-binding verification;
-- validations run, limitations and decisions still required.
-
-Always distinguish `provider succeeded`, `artifact ready`, `selected`, `authority adopted` and `binding verified`; none implies the next.
+---
+name: design-system-authoring
+description: Use only when the user explicitly asks to initialize, generate, choose, adopt, replace or repair a project design system or design style with Open Design; asks for “初始化设计系统”, “生成设计系统”, “确定设计风格”, “采纳 Open Design 设计系统”, or explicitly invokes design-system-authoring in a Minimal Context Harness project. This cold-start capability never runs merely because DESIGN.md is missing, a project is new, another Skill needs visual style, or ordinary UI work begins.
+---
+
+# Design System Authoring
+
+Generate or select an Open Design design system, obtain an explicit selection, and adopt that selection into the project's existing durable Design Authority. The user invokes this Skill at project cold start or later repair time; installation only makes it available.
+
+## Hard boundaries
+
+- Run only from an explicit user request. Never auto-run from `init`, `sync`, the default Workflow, `design-resource-authoring`, a missing/starter `DESIGN.md`, or a new-project inference.
+- A combined explicit user request to initialize the system and then generate resources authorizes that sequence; a resource gate alone does not.
+- Open Design owns generation, revision, previews and its catalogue. Use its live structured capabilities; do not copy its prompts, emulate its generator, vendor a catalogue or invent provider IDs.
+- Keep candidate generation, human/delegated selection and authority adoption distinct. A successful job or attractive preview is not selected and is not project authority.
+- Project `DESIGN.md` and its one declared authored exact-value token source or generation direction are canonical. An Open Design design-system record and project binding are provider synchronization, not a second authority.
+- Put durable surface, information-architecture and interaction facts in their owning `project_context/**`; put visual-system semantics, rationale, token direction and reference interpretation in `DESIGN.md`. Do not duplicate facts across owners.
+- Do not create a design registry, receipt, workflow state, Contract, acceptance gate or provider runtime inside Tiny Context.
+- Do not persistently install/configure MCP, plugins, authentication or disclosure paths without separate authorization. Task-local use of an already available Open Design MCP/daemon is allowed.
+- Do not implement production UI or claim downstream fidelity, accessibility, product correctness or acceptance.
+
+## Read the references
+
+1. Always read [open-design-design-system-provider.md](references/open-design-design-system-provider.md) before discovery, generation, revision, selection or provider synchronization.
+2. Always read [authority-adoption.md](references/authority-adoption.md) before changing `DESIGN.md`, its token source, relevant Context or provider bindings.
+
+## Core workflow
+
+1. **Confirm explicit intent and scope.** Identify whether the user wants a new system, selection from existing systems, repair, or replacement; capture the product/brand purpose, supported surface/platform, accessibility needs, required modes and supplied references. Ask only when an unresolved aesthetic or brand choice materially changes the candidates and the user has not delegated selection.
+2. **Inspect current authority.** Read core Context, relevant surface/interaction Context, `DESIGN.md`, its declared token source/generation direction and any recorded Open Design provenance. Classify the project as `unconfigured`, `configured`, or `configured-but-inconsistent`; this is a task-local finding, not new state.
+3. **Discover live Open Design capabilities.** Prefer structured MCP. List/read `od://design-systems/<id>/DESIGN.md`, inspect tool schemas, and feature-detect design-system creation/revision/acceptance plus project binding. Record the live provider/MCP version and any fallback used.
+4. **Reuse or generate candidates.** Reuse an existing provider system only when its identity and meaning fit. If a live MCP creation capability exists, use it. Otherwise use the official daemon generation-job API described in the provider reference. Keep every output a candidate until selection.
+5. **Review and iterate.** Inspect `DESIGN.md`, generated token files, preview/showcase and relevant workspace files. Use provider revision jobs for scoped feedback, poll boundedly, preserve diagnostics and keep pending revisions non-authoritative.
+6. **Obtain selection.** Require an explicit user/team selection, or an explicit instruction delegating selection with known criteria. Record the selection basis, provider design-system ID, selected revision when applicable and immutable content digest/snapshot. Reject or leave other candidates unselected.
+7. **Adopt once.** Reconcile the selected system through the authority-adoption procedure. Update root `DESIGN.md`, establish exactly one authored token source/generation direction, update only owning Context facts, and record provider provenance without making it authoritative.
+8. **Synchronize Open Design.** Accept the selected pending revision when applicable. Confirm MCP can read the adopted provider system. For later style-bearing resource work, create or verify an Open Design project with `create_project.designSystem` equal to the adopted provider ID.
+9. **Validate and report.** Run project-owned Context/design lint and source/package checks appropriate to the repository. Separately report provider execution, artifact readiness, selection, authority adoption, provider synchronization, verification and unresolved issues.
+
+## Readiness classification
+
+Treat Design Authority as unconfigured when `DESIGN.md` is absent, explicitly says `Design authority status: unconfigured`, remains an unedited starter, contains only style adjectives/inspiration, or lacks one authored exact-value token source/generation direction. A configured visual system still does not make every surface implementation-ready; selected exact/constraint targets and declared coverage remain separate.
+
+If authority is already configured and the user did not ask to replace or repair it, prefer reuse and explain the current system. Never generate a competing system as filler.
+
+## Completion response
+
+Report:
+
+- requested operation and design-system scope;
+- Open Design transport/version and capabilities actually used;
+- candidate IDs and review performed;
+- explicit or delegated selection basis;
+- adopted `DESIGN.md`, token source and Context owners changed;
+- provider ID, revision/digest and project-binding verification;
+- validations run, limitations and decisions still required.
+
+Always distinguish `provider succeeded`, `artifact ready`, `selected`, `authority adopted` and `binding verified`; none implies the next.

package/assets/skills/design-system-authoring/agents/openai.yaml

@@ -1,6 +1,6 @@
-interface:
-  display_name: "Design System Authoring"
-  short_description: "Generate and adopt a project design system"
-  default_prompt: "Use $design-system-authoring to generate, select, and adopt an Open Design design system for this project."
-policy:
-  allow_implicit_invocation: false
+interface:
+  display_name: "Design System Authoring"
+  short_description: "Generate and adopt a project design system"
+  default_prompt: "Use $design-system-authoring to generate, select, and adopt an Open Design design system for this project."
+policy:
+  allow_implicit_invocation: false