# Agent Skills (/foundations/skills)



The `dash` skill helps coding agents use the design system in a real application: inspect the installed packages, choose supported components, apply tokens, and verify the finished interaction. It works with the project's existing design and repository instructions.

[Download the DASH skill (.zip)](/skills/dash.zip) · [Read SKILL.md](/skills/dash/SKILL.md) · [Documentation for agents](/llms.txt)

## Install the skill [#install-the-skill]

Download and extract the archive, then place the complete `dash` folder in your agent's skill directory. Keep the references beside `SKILL.md`; they contain the task-specific setup, implementation, and review guidance.

| Agent       | Project location       | Personal location        | Explicit invocation |
| ----------- | ---------------------- | ------------------------ | ------------------- |
| Codex       | `.agents/skills/dash/` | `~/.agents/skills/dash/` | `$dash`             |
| Claude Code | `.claude/skills/dash/` | `~/.claude/skills/dash/` | `/dash`             |

These are local coding-agent locations. See [OpenAI's skill documentation](https://learn.chatgpt.com/docs/build-skills) and [Claude Code's skill documentation](https://code.claude.com/docs/en/skills) for discovery, managed installations, and cloud-session differences. Other tools that support Agent Skills can use the same `SKILL.md` and references through their own installation mechanism.

For example, from your repository root, with the downloaded archive saved as `dash.zip`:

```sh
# Codex
mkdir -p .agents/skills
unzip dash.zip -d .agents/skills
```

For Claude Code, extract to `.claude/skills` instead. If you already have a `dash` skill, compare it before replacing it and retain any deliberate local changes. After installation, confirm that your agent can find the skill, then invoke it explicitly for a first task. Opening this documentation page alone does not install it.

The archive contains:

```text
dash/
├── SKILL.md
├── agents/
│   └── openai.yaml
└── references/
    ├── setup.md
    ├── implementation.md
    └── review.md
```

`agents/openai.yaml` supplies Codex display metadata. The shared workflow lives in the Markdown files and does not depend on a particular model, connector, or executable helper.

## Give the agent a useful brief [#give-the-agent-a-useful-brief]

Provide the task, the application or files to work in, a design reference when one exists, and the outcome that should work. Include known constraints such as preserving the current package version or keeping an existing layout. The agent should inspect the remaining repository context itself.

For an implementation in Codex:

```text
Use $dash to add a project settings form in this application.
Keep the current package versions and match the existing settings pages.
Support validation, saving, request failure, and retry without losing input.
Check keyboard use, narrow layouts, and both themes.
```

In Claude Code, start the request with `/dash` instead. For a review:

```text
Use $dash to review this screen against our installed DASH packages.
Report concrete problems with component usage, tokens, keyboard behavior,
and error states. Include evidence and proposed fixes; do not edit files.
```

For adoption in an application that does not yet use DASH, ask the agent to inspect compatibility and explain the required integration before changing dependencies. The skill supports that work without assuming every application should be migrated.

## What the skill covers [#what-the-skill-covers]

| Task                    | Guidance                                                                                                                     |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| Setup and compatibility | Find the actual package versions, preset ownership, Panda extraction inputs, generated stylesheet, theme context, and fonts. |
| Component selection     | Read version-matched examples and types. Distinguish a published API from an illustration or a proposed feature.             |
| Styling and composition | Apply semantic tokens, existing application patterns, and statically extractable Panda styles.                               |
| Complete interactions   | Handle the relevant validation, loading, saving, empty, error, and retry states while preserving entered values.             |
| Review and handoff      | Exercise the changed flow, run relevant checks, and report observed results and remaining limitations.                       |

The skill directs agents to the [component documentation](/components), [patterns](/patterns), and [foundations](/foundations) needed for the task. It keeps detailed API reference material in the installed package and this site, where it can be maintained with the implementation.

## How it makes decisions [#how-it-makes-decisions]

### Resolve package and documentation differences [#resolve-package-and-documentation-differences]

The installed package's exports, types, and matching documentation determine which APIs exist. The application's approved design and the foundation guidance determine visual intent. If these disagree, the agent should identify the mismatch and use a supported API rather than fabricate a prop or silently upgrade the project.

The bundled setup reference was checked against `ds-components` 0.5.1, `ds-helpers` 0.2.2, and `ds-icons` 0.0.3. It also calls out two sources of confusion: the preset now belongs to `ds-components`, and the package's default font stacks may differ from the KH typefaces documented here. The agent must check the consuming application rather than assume either setup is already in place.

### Keep research separate from available behavior [#keep-research-separate-from-available-behavior]

Proposed features do not establish a published API or enforce permissions in an application. Verify that the installed package implements a behavior before relying on it. The skill tells agents to use implemented components for current work and identify the limits of an explicitly requested research prototype.

### Verify the task, not just the appearance [#verify-the-task-not-just-the-appearance]

A screen can look correct while losing form values, trapping focus, or failing in another theme. The review reference asks for evidence from the changed interaction, with checks proportionate to its scope. It covers [accessibility](/foundations/accessibility), [reflow](/foundations/responsiveness), and [reduced motion](/foundations/motion) without treating a component library or automated test as a guarantee of conformance.

## Read the skill [#read-the-skill]

This is the same source file included in the download. The entry point contains the shared workflow and routes the agent to additional guidance only when it is relevant.

<DashSkillSource file="SKILL.md" />

## Supporting references [#supporting-references]

Each file can be read here, fetched directly by an agent, or used from the installed skill folder.

<details>
  <summary>
    Setup and compatibility
  </summary>

  [Read setup.md](/skills/dash/references/setup.md). Use it for adoption, dependency changes, missing styles, and theme or font configuration.

  <DashSkillSource file="references/setup.md" />
</details>

<details>
  <summary>
    Implementation and component selection
  </summary>

  [Read implementation.md](/skills/dash/references/implementation.md). Use it to choose components, compose states, and apply tokens and patterns.

  <DashSkillSource file="references/implementation.md" />
</details>

<details>
  <summary>
    Review and verification
  </summary>

  [Read review.md](/skills/dash/references/review.md). Use it for a requested review or for checks before handing off an implementation.

  <DashSkillSource file="references/review.md" />
</details>

## Why one skill [#why-one-skill]

DASH setup, implementation, and review share the same package context and design rules. We keep them in one focused skill, with the longer guidance in separate references. This follows [OpenAI's guidance on focused skill boundaries](https://developers.openai.com/plugins/build/skills) and [Anthropic's guidance on progressive disclosure](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices). Split out another skill when it has a distinct trigger and independently useful workflow, rather than creating a skill for each foundation or component.

## Maintain and evaluate [#maintain-and-evaluate]

Keep the skill with the version of DASH your team uses. Recheck its package guidance when adopting releases from the [changelog](/changelog), and update it when a real task exposes a missing decision or incorrect instruction.

Useful evaluation tasks include:

* Add a form with a failing save request and verify that values, errors, and focus behave correctly.
* Diagnose an unstyled component whose generated CSS is missing.
* Request an API shown in a mock-up but absent from the installed package, and check whether the agent identifies the gap.
* Review a screen without authorizing edits, and check whether the agent returns findings without changing files.
* Ask for a proposed feature absent from the installed package, and check whether the agent distinguishes a prototype from an implemented security mechanism.

Use a disposable project or read-only review for evaluation. Inspect the result and the agent's evidence; a valid `SKILL.md` file alone does not show that the workflow succeeds. Keep improvements tied to demonstrated failures, and avoid adding rules for unrelated tasks.