PK!Dww dash/SKILL.md--- name: dash description: Build or review interfaces using HASH's DASH design system. Use for DASH component selection, Panda setup, token styling, or interface review in projects that use or are adopting DASH. --- # Build with DASH Deliver the requested interface using the target project's DASH packages, visual conventions, and interaction patterns. Preserve the user's chosen design and task scope. A review request produces findings; it does not authorize implementation or package upgrades. ## Establish the implementation context Read the repository instructions and inspect the target application's dependency versions, Panda configuration, generated CSS entry point, theme and font setup, and a nearby working interface. For available imports, props, tokens, and behavior, use the installed package's exports, types, documentation, and source. Use the application's approved design and HASH's foundation guidance for visual decisions. When the website and installed package differ, explain the mismatch and use the installed API; propose an upgrade only if the task needs it. Do not invent a component or prop to match a mock-up. The canonical documentation is https://hash.design. Start at [llms.txt](https://hash.design/llms.txt), then read relevant pages as Markdown by appending `.mdx` to their paths. Prefer a few targeted pages over the full documentation dump. A component directory illustration is not evidence that its API is published. If network access is unavailable, use local package docs and report what could not be verified. ## Load only the reference needed - Read [setup.md](references/setup.md) when adopting DASH, changing dependencies, configuring Panda or fonts, or diagnosing missing styles. - Read [implementation.md](references/implementation.md) when choosing components, composing a screen, styling states, or adapting a layout. - Read [review.md](references/review.md) when reviewing an interface or checking an implementation before handoff. Scale the checks to the changed behavior. ## Make the interface work Identify the user's task, the data it needs, and the states that affect the requested change. Reuse existing application components and DASH components where their documented behavior fits. Read the relevant component examples before composing them; keep their keyboard, focus, labeling, and controlled-state contracts intact. Use the project's Panda styling path and semantic tokens. Check token names against the installed helpers. A generated class name alone does not load the corresponding CSS. Keep style choices statically discoverable by Panda; map runtime values to a bounded set of declared styles. Use the documented pattern for forms, saving, loading, empty results, and errors when it applies. Preserve entered data through validation and request failures. Keep task outcomes and uncertainty visible in text, including for people who cannot see a color change or animation. Treat the page's status as part of its guidance. Proposed features do not establish runtime authorization, guarantee accessibility, or provide a published component API. Verify support in the target project before relying on a behavior. Use ordinary implemented controls for current work; isolate an explicitly requested research prototype and describe its limits. Use approved assets for the intended brand. Follow the target project's font setup and the relevant usage terms. HASH's commercial font licenses do not grant third parties permission to use the fonts. ## Finish with evidence Run relevant configured checks and exercise the changed interaction in the browser when available. Review keyboard operation, the applicable states, narrow layouts, both supported themes, and reduced motion where the change affects them. A small text edit does not need an entire application audit. Report the result, the package versions or docs that informed non-obvious decisions, what was tested, and any remaining mismatch or untested behavior. Fix issues within scope. Ask for a decision only when missing information prevents a sound implementation, such as choosing a replacement for an unavailable component or changing a dependency beyond the requested work. PK!Undash/agents/openai.yamlinterface: display_name: "DASH" short_description: "Build and review interfaces with HASH's design system" default_prompt: "Use $dash to implement or review this interface with the project's installed DASH packages." PK!!dash/references/implementation.md# Compose a DASH interface Use this reference for implementation and component selection. Start from the actual task and approved design, then read the component pages needed for that work. ## Choose the interaction before its appearance | User need | Documentation to inspect | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Enter and validate information | [Forms](https://hash.design/patterns/forms.mdx), [Form](https://hash.design/components/form.mdx), and the relevant input component. | | Save or submit work | [Saving](https://hash.design/patterns/saving.mdx), [Button](https://hash.design/components/button.mdx), and [Error handling](https://hash.design/patterns/error-handling.mdx). | | Filter or sort a collection | [Filtering and sorting](https://hash.design/patterns/filtering-sorting.mdx), then Select, Combobox, or Menu as appropriate. | | Reveal detail or request confirmation | [Progressive disclosure](https://hash.design/patterns/progressive-disclosure.mdx), then Dialog, Drawer, or Popover. | | Explain an in-progress or absent result | [Loading](https://hash.design/patterns/loading.mdx) and [Empty states](https://hash.design/patterns/empty-states.mdx). | | Communicate a result or recoverable problem | [Notifications](https://hash.design/patterns/notification-messaging.mdx). | | Arrange a screen | [UI layout](https://hash.design/patterns/ui-layout.mdx) and [Responsiveness](https://hash.design/foundations/responsiveness.mdx). | Resolve exact component names and import paths from the [Components directory](https://hash.design/components) and the installed package. Prefer an application wrapper when it already implements the required behavior. A component label in a prototype or a related-components list is not proof of an export. For an unavailable component, explain the gap and use a supported composition if it meets the task; otherwise propose a specific alternative. Published component Markdown may contain JSX demo references. Read the baked-in example code, local declarations, and corresponding stories when the text alone does not establish usage. Preserve the compound-component structure and state callbacks shown by that version. ## Compose with tokens Use semantic foreground, background, and border roles for interface content. Raw palette steps belong in deliberate palette previews or brand artwork; an arbitrary fixed hex value should not substitute for a theme-aware role. Verify actual contrast, including muted text and status colors. Use the shared spacing, radius, shadow, type, and duration scales when the design calls for them. Density and available width are separate concerns. The reference preset leaves named viewport breakpoints to the consuming application: inspect its configuration before using names such as `md` or `lg`. Retain readable DOM and focus order when a layout changes. For custom motion, start from the component's behavior and shared duration tokens. Respect `_motionReduce` or the corresponding media query. Keep meaningful status visible in the still state; give repeating demonstrations a pause control and stop unnecessary animation offscreen. ## Keep the complete task usable - Give controls visible labels or suitable accessible names. An icon-only button needs a name; a tooltip alone does not establish that name. Decorative icons should stay out of the accessibility tree. - Preserve keyboard and focus behavior when wrapping a component. Confirm how a dialog opens, closes, and returns focus, and how a menu or selection control handles its documented keys. - Decide which component or parent owns controlled state. Connect real values, callbacks, validation, and disabled or pending behavior. A convincing static example is not a working interaction. - Preserve entered values when validation or a request fails. Show the next useful action, and keep loading, empty results, and errors distinct. - Use native navigation and action semantics. Verify important actions with a keyboard and touch; essential behavior cannot depend on hover alone. - Handle long labels, dense content, and narrow widths. Contain genuinely two-dimensional content without making the whole page scroll sideways. ## Research and brand boundaries Verify that the installed package implements any proposed behavior before relying on it. A styling token or “verified” label does not enforce permissions. Preserve the application's actual authorization and confirmation logic. Make unsupported research concepts explicit when asked to prototype them. Use the appropriate [brand assets and terms](https://hash.design/brands.mdx). Keep the product's identity and approved design rather than copying the documentation site's layout into every application. Licensed font files and other restricted assets are not supplied by this skill. PK!IOOdash/references/review.md# Review and verify a DASH interface Use this reference for a requested review or the handoff of an implementation. Review the changed task and the components it depends on. Scale the scope to the change, and separate observed failures from concerns that still need a check. ## Match the installed system Confirm imports, props, and token names against the installed exports and types. Check that the application generates and loads the required CSS. Inspect the computed theme and fonts when appearance differs from the design. Identify proposed or unavailable APIs explicitly. For a review-only request, report findings with file or interaction references and their practical effect. Prioritize broken tasks, data loss, misleading states, and keyboard or focus failures before cosmetic differences. ## Exercise the changed flow | Area | Evidence to collect when relevant | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Outcome and state | Complete the intended action. Check empty data, pending work, success, errors, validation, and retry where the change affects them. Verify that errors preserve entered values. | | Keyboard and focus | Reach every action, use the component's documented keys, see the focus indicator, and verify overlay dismissal and focus return. | | Labels and announcements | Inspect accessible names and input/error associations. Check that meaningful asynchronous results are announced without repeated or distracting updates. | | Theme and contrast | Review supported light and dark states against actual backgrounds. Required text and status must remain readable. Color alone cannot carry a state. | | Reflow and input | Check narrow and wide layouts, intermediate widths, long content, zoom, and touch targets. Ordinary content should reflow at 320 CSS pixels; contain data tables or other two-dimensional content. | | Motion | Check reduced motion, interruption, repeated activation, and the still state. Verify pause behavior for looping demonstrations. | Use the [Accessibility guidance](https://hash.design/foundations/accessibility.mdx) for criteria and exceptions, and [Responsiveness](https://hash.design/foundations/responsiveness.mdx) for layout choices. Passing automated checks or using an accessible primitive alone does not establish accessibility conformance for a composed screen. ## Run the project's checks Use the repository's configured type, lint, build, and relevant interaction tests. Add tests for changed behavior when they can catch a meaningful regression; do not add tests that only restate a style value or implementation detail. Distinguish a failure introduced by the change from a pre-existing failure, and report both accurately. If a browser or assistive technology is unavailable, complete the checks that are possible and name the missing verification. Do not describe an unobserved interaction as tested. ## Handoff State what changed or what needs fixing, why it matters for the task, and the evidence supporting the conclusion. Include the checks actually run, the states exercised, and any unresolved package or documentation mismatch. Cite relevant documentation or code when it explains a decision. Keep research proposals and unverified assumptions separate from implemented behavior. PK!Nחdash/references/setup.md# DASH setup and compatibility Use this reference for adoption, dependency changes, missing styles, or theme and font setup. Start with the target repository's working examples and scripts. ## Package ownership This reference was checked against `@hashintel/ds-components` 0.5.1, `@hashintel/ds-helpers` 0.2.2, and `@hashintel/ds-icons` 0.0.3. These are a reference snapshot, not versions every application must install. | Package or entry point | Responsibility | | --------------------------------- | ------------------------------------------------------------------------------------------- | | `@hashintel/ds-components` | React components built on Ark UI and Panda CSS. Inspect its root and per-component exports. | | `@hashintel/ds-components/preset` | The current Panda preset and configuration helpers. | | `@hashintel/ds-components/tokens` | The package-owned token definitions. | | `@hashintel/ds-helpers/css` | Generated `css`, `cva`, and `cx` helpers. | | `@hashintel/ds-helpers/tokens` | Token lookup helpers, including `token.var`. | | `@hashintel/ds-icons` | Optional HASH icon components and integration helpers. | In this snapshot, the former `ds-theme` preset ownership has moved into `ds-components`. Check an older application's setup before migrating it. Keep the repository's package manager and lockfile, and inspect peer requirements rather than assuming that any React or Ark UI version is compatible. ## Panda integration Confirm all of the following in the consuming application: - Its Panda configuration includes the DASH preset from `@hashintel/ds-components/preset` and uses `@hashintel/ds-helpers` as its `importMap`. - Its extraction inputs cover application files that declare styles and the component package's published `panda.buildinfo.json`. Use the package's `resolvePandaBuildInfoPath` helper when its setup example requires it. - If rendering the published documentation blocks, include the separate `docs/panda.buildinfo.json`. Ordinary product screens do not need those documentation blocks. - If using `ds-icons`, include its build information and `dsIconsPandaPreset` for its animation styles. - The repository's code-generation and CSS-generation commands run, and the resulting stylesheet is loaded by the application. Importing `css` does not do that loading. Follow the application's existing choices for output directories, preflight, theme scoping, and bundling. Avoid replacing a working configuration with a generic full-file example. Prefer existing strict-token checks, and justify literal CSS values that are needed for a layout or custom effect. ## Tokens and runtime styles Style properties use short token names; token lookup uses a category path: ```tsx import { css } from "@hashintel/ds-helpers/css"; import { token } from "@hashintel/ds-helpers/tokens"; const panel = css({ padding: "4", borderRadius: "lg", backgroundColor: "bg.surface", color: "fg.body", }); const externalStyle = { padding: token.var("spacing.4"), borderRadius: token.var("radii.lg"), }; ``` `token.var` keeps the CSS variable reference. This matters when the value responds to theme or density. Avoid constructing token names or class names from arbitrary strings at runtime; declare a map of supported states that Panda can extract. ## Theme and fonts Inspect the actual preset and the host's theme provider. The published preset supports root `light` and `dark` classes; preserve how the application chooses and persists the theme. Semantic colors need the correct theme context, including in portals. HASH's typography guidance uses KH Teka, KH Teka Mono, and limited editorial use of KH Giga. The package snapshot's default stacks can still name Inter, Inter Tight, and Geist Mono. Loading a font alone does not change those stacks. Use the host's approved theme overrides or font variables and verify the computed font. Preserve suitable system fallbacks. Use only fonts the project is authorized to serve. ## Missing styles: inspect before replacing components If a component looks unstyled, check its import against exports, CSS extraction inputs, the generated stylesheet request, and computed styles. If only an overlay is wrong, inspect its portal and theme context. If only an icon fails, check its build information and animation preset. Read version-matched examples before changing props or inventing CSS fixes. ## Relevant documentation - [DASH setup](https://hash.design/foundations/design-system.mdx). - [Typography and font stacks](https://hash.design/foundations/type.mdx). - [Icons](https://hash.design/foundations/icons.mdx). - [Libraries](https://hash.design/libs.mdx) and [Changelog](https://hash.design/changelog.mdx). PK!Dww dash/SKILL.mdPK!Undash/agents/openai.yamlPK!!dash/references/implementation.mdPK!IOO'dash/references/review.mdPK!Nחp7dash/references/setup.mdPK\gK