Carapace Compatibility Alias
This skill identifier remains available for existing skills-lock.json
entries during the v0.1.x migration. New installations should use
openclaw-carapace.
Use the shared package for foundations and framework-neutral visual primitives.
Keep consumer-specific behavior, data, routes, and layout composition local.
Before changing imports, inspect the consumer manifest: use
@openclaw/carapace when it is installed, otherwise preserve the legacy
@openclaw/design-system specifier until the dependency is migrated.
Workflow
- Read tokens.md before choosing colors, spacing, type, radii, or shadows.
- Read consumer-adapters.md for the current framework.
- Inspect the consumer's existing shared primitives before creating a component.
- Use semantic tokens for UI intent; use palette primitives only for documented exceptions.
- Keep application behavior, routes, and information architecture unchanged unless the task says otherwise.
- Validate the affected routes with existing tests and real browser screenshots.
Interface Rules
- Import the complete CSS contract or its focused exported entry points.
- Compose shared classes from
components.css before adding a one-off visual implementation.
- Use local shared primitives before raw controls or one-off component implementations.
- Keep one primary action per decision area.
- Use familiar icons for icon-only commands and provide accessible names.
- Use status colors for status, warning, success, error, and informational meaning.
- Keep cards, controls, and repeated fixed-format elements dimensionally stable.
- Avoid nested decorative cards and page sections styled as floating cards.
- Keep surfaces, controls, and insets square through their semantic radius tokens.
- Reserve round geometry for avatars, status dots, and other truly circular indicators.
- Keep focus, hover, active, disabled, loading, and invalid states coherent.
- Keep text within its container at supported viewport sizes.
- Prefer dense, scan-friendly composition for operational product surfaces.
Ownership
Move visual implementation into this repository when its interface is
framework-neutral and useful across consumers. Keep runtime behavior and
framework adapters local until at least two consumers need the same interface
and behavior.
1---2name: openclaw-design-system3description: Compatibility alias for existing OpenClaw installations that now applies Carapace semantic tokens, themes, shared CSS foundations, consumer adapters, and established local primitives.4---5
6# Carapace Compatibility Alias
7
8This skill identifier remains available for existing `skills-lock.json`
9entries during the `v0.1.x` migration. New installations should use
10`openclaw-carapace`.
11
12Use the shared package for foundations and framework-neutral visual primitives.
13Keep consumer-specific behavior, data, routes, and layout composition local.
14Before changing imports, inspect the consumer manifest: use
15`@openclaw/carapace` when it is installed, otherwise preserve the legacy
16`@openclaw/design-system` specifier until the dependency is migrated.
17
18## Workflow
19
201. Read [tokens.md](references/tokens.md) before choosing colors, spacing, type, radii, or shadows.
212. Read [consumer-adapters.md](references/consumer-adapters.md) for the current framework.
223. Inspect the consumer's existing shared primitives before creating a component.
234. Use semantic tokens for UI intent; use palette primitives only for documented exceptions.
245. Keep application behavior, routes, and information architecture unchanged unless the task says otherwise.
256. Validate the affected routes with existing tests and real browser screenshots.
26
27## Interface Rules
28
29- Import the complete CSS contract or its focused exported entry points.
30- Compose shared classes from `components.css` before adding a one-off visual implementation.
31- Use local shared primitives before raw controls or one-off component implementations.
32- Keep one primary action per decision area.
33- Use familiar icons for icon-only commands and provide accessible names.
34- Use status colors for status, warning, success, error, and informational meaning.
35- Keep cards, controls, and repeated fixed-format elements dimensionally stable.
36- Avoid nested decorative cards and page sections styled as floating cards.
37- Keep surfaces, controls, and insets square through their semantic radius tokens.
38- Reserve round geometry for avatars, status dots, and other truly circular indicators.
39- Keep focus, hover, active, disabled, loading, and invalid states coherent.
40- Keep text within its container at supported viewport sizes.
41- Prefer dense, scan-friendly composition for operational product surfaces.
42
43## Ownership
44
45Move visual implementation into this repository when its interface is
46framework-neutral and useful across consumers. Keep runtime behavior and
47framework adapters local until at least two consumers need the same interface
48and behavior.