Agent skill

Cavekit Design System

by JuliusBrussee in JuliusBrussee/caveman-code

How to write and maintain DESIGN.md as the visual specification layer for Cavekit projects.

MITAuto-check passedFrontend & Design

Install Cavekit Design System

skills CLI
$ npx skills add JuliusBrussee/caveman-code --skill cavekit-design-system -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install JuliusBrussee/caveman-code cavekit-design-system --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/JuliusBrussee/caveman-code.git skills-src && mkdir -p .claude/skills && cp -r skills-src/packages/coding-agent/skills/cavekit-design-system .claude/skills/cavekit-design-system && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
cavekit-design-system
GitHub stars
942
Token cost
~4.5k tokens
SKILL.md length
1,232 words
Files
1
Skills in repo
6
Repo updated
First seen
Licence
MIT

At a glance

How to write and maintain DESIGN.md as the visual specification layer for Cavekit projects.

  • Works in 4 steps: Before implementing: Read DESIGN.md (or… → During implementation: Use design… → In commit messages: Note which DESIGN.md… → …
  • Revising visual identity
  • SKILL.md covers Core Principle: DESIGN.md…, The 9-Section Stitch Format, Design Token Conventions and Integration with Kits, plus 3 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Cavekit Design System is an agent skill from JuliusBrussee/caveman-code. How to write and maintain DESIGN.md as the visual specification layer for Cavekit projects. Nine-section format, design tokens, accessibility, integration with kits/plans. Use when defining or revising visual identity, importing a third-party design system, or auditing UI code against design tokens.

Its SKILL.md is about 4.5k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Frontend & Design, covering Design tokens, Design systems and Logo and visual identity. The repository describes itself as: Frozen — terminal coding agent measured at 1.93× fewer tokens than Codex CLI. Still works; active development moved to JuliusBrussee/caveman (caveman wrap). The licence is MIT.

When your agent uses it

  • Revising visual identity
  • Importing a third-party design system
  • Auditing UI code against design tokens

Example prompts

  • “/cavekit-design-system”

Requirements

  • Pre-approved tools (allowed-tools): read, grep, edit

Workflow steps

4 steps, taken from the first numbered list in SKILL.md.

  1. Before implementing: Read DESIGN.md (or the specific sections referenced in the task)
  2. During implementation: Use design tokens, not hardcoded values
  3. In commit messages: Note which DESIGN.md sections were followed
  4. If a new pattern is needed: Implement it following existing DESIGN.md conventions and flag for design update

What it can do on your machine

Read from SKILL.md and the folder at commit 3a21be1. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • read
    • grep
    • edit

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown and css).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • stitch.withgoogle.com
    • github.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Cavekit Design System loads about 4.5k tokens when it runs. Until then it costs about 81 tokens; SKILL.md has 1,232 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~81
When it runs · the whole SKILL.md, loaded when a task matches
~4.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from JuliusBrussee/caveman-code at commit 3a21be1, republished under its MIT licence (© JuliusBrussee). 1,232 words, ~4,484 tokens.

Download SKILL.mdSave it as .claude/skills/cavekit-design-system/SKILL.md (or your agent's skills folder).
name
cavekit-design-system
description
How to write and maintain DESIGN.md as the visual specification layer for Cavekit projects. Nine-section format, design tokens, accessibility, integration with kits/plans. Use when defining or revising visual identity, importing a third-party design system, or auditing UI code against design tokens.
allowed-tools
read, grep, edit
effort
medium

Design System: DESIGN.md for AI Agents

Core Principle: DESIGN.md Describes WHAT It Looks Like, Not HOW to Build It

DESIGN.md is the visual equivalent of kits. It defines the project's visual language — colors, typography, spacing, components, responsive behavior — in a format AI agents can read and apply consistently. It is a parallel constraint layer that all Hunt phases consult.

DocumentDefinesAudience
CLAUDE.mdHow to build the projectCoding agents
KitsWhat must be true (behavior)All agents
DESIGN.mdWhat it looks like (visual)UI-building agents
PlansHow to build it (tasks)Builder agents
Why a Dedicated Design System Document?

Without DESIGN.md, visual decisions scatter across kits, plans, and code:

  • Colors get hardcoded differently per component
  • Typography choices vary between agents and sessions
  • Spacing becomes inconsistent across the UI
  • New components reinvent patterns that already exist

DESIGN.md centralizes these decisions. Every agent reads it before writing UI code.


The 9-Section Stitch Format

DESIGN.md follows the Google Stitch format — 9 sections that together define a complete visual language. Every DESIGN.md must contain all 9 sections.

Section 1: Visual Theme & Atmosphere

The design philosophy, mood, and overall aesthetic. Use evocative, specific language — not generic terms like "clean and modern."

markdown
## 1. Visual Theme & Atmosphere

This is a warm editorial experience built on natural materials. Think: a well-curated
bookshop with soft overhead lighting and carefully chosen display shelves. The density
is low — generous whitespace signals confidence and clarity. Every element earns its
place; nothing decorative exists without functional purpose.

**Key attributes:** Warm, unhurried, editorial, confident
**Density:** Low — generous whitespace, single-column focus
**Personality:** Thoughtful librarian, not flashy storefront

What good looks like: A new designer reading this section could sketch a rough layout without seeing any other section.

Anti-pattern: "Clean, modern, and professional" — this describes nothing specific.

Section 2: Color Palette & Roles

Every color needs three things: a semantic name, a hex value, and a functional role.

markdown
## 2. Color Palette & Roles

### Primary
| Name | Hex | Role |
|------|-----|------|
| Terracotta Brand | #c96442 | Primary CTA, active states, brand anchors |
| Terracotta Hover | #b85838 | Hover/pressed state for primary actions |

### Neutral
| Name | Hex | Role |
|------|-----|------|
| Near Black | #141413 | Primary text, headings |
| Olive Gray | #5e5d59 | Secondary text, captions |
| Parchment | #f5f4ed | Page background, default canvas |
| Ivory White | #ffffff | Card surfaces, overlays |

### Semantic
| Name | Hex | Role |
|------|-----|------|
| Success Green | #2d7d46 | Confirmation, success states |
| Warning Amber | #c27217 | Warnings, attention needed |
| Error Red | #c24132 | Errors, destructive actions |
| Info Blue | #3b6fb5 | Informational states, links |

### Dark Mode (if applicable)
| Light Name | Dark Equivalent | Hex |
|------------|----------------|-----|
| Parchment | Deep Charcoal | #1a1a1a |
| Near Black | Off White | #e8e8e8 |

Rules:

  • Every hex value must be verified against the actual design or live site
  • Every color must have a clear functional role — no orphan colors
  • Name colors semantically (by role), not by hue ("Primary CTA" not "Orange")
  • If dark mode exists, map every light color to its dark equivalent
Section 3: Typography Rules

Complete type hierarchy with specific values — no "roughly 16px" or "medium weight."

markdown
## 3. Typography Rules

### Font Stack
- **Display/Heading:** "Anthropic Serif", Georgia, "Times New Roman", serif
- **Body:** "Anthropic Sans", -apple-system, BlinkMacSystemFont, sans-serif
- **Code:** "Anthropic Mono", "SF Mono", "Fira Code", monospace

### Type Scale
| Level | Size | Weight | Line Height | Letter Spacing | Font |
|-------|------|--------|-------------|----------------|------|
| H1 | 48px / 3rem | 500 | 1.10 | -0.02em | Serif |
| H2 | 36px / 2.25rem | 500 | 1.15 | -0.01em | Serif |
| H3 | 24px / 1.5rem | 500 | 1.25 | 0 | Serif |
| H4 | 20px / 1.25rem | 600 | 1.30 | 0 | Sans |
| Body | 16px / 1rem | 400 | 1.60 | 0 | Sans |
| Small | 14px / 0.875rem | 400 | 1.50 | 0.01em | Sans |
| Caption | 12px / 0.75rem | 500 | 1.40 | 0.02em | Sans |

### Principles
- Headings use serif for warmth and authority
- Body text uses sans-serif for readability at small sizes
- Maximum line length: 65ch for body text
- Minimum font size: 14px (never go below)

Rules:

  • Every level in the scale must have all 5 values (size, weight, line-height, letter-spacing, font)
  • Use rem alongside px for accessibility
  • Include font stack fallbacks
Section 4: Component Stylings

Concrete styling for common components including interaction states.

markdown
## 4. Component Stylings

### Buttons
**Primary:**
- Background: Terracotta Brand (#c96442)
- Text: Ivory White (#ffffff), 16px Sans, weight 500
- Padding: 12px 24px
- Border radius: 8px
- Hover: Terracotta Hover (#b85838), translateY(-1px), shadow-sm
- Active: translateY(0), shadow-none
- Disabled: opacity 0.5, cursor not-allowed
- Transition: all 150ms ease-out

**Secondary:**
- Background: transparent
- Border: 1px solid Olive Gray (#5e5d59)
- Text: Near Black (#141413)
- Hover: background Parchment (#f5f4ed)

### Cards
- Background: Ivory White (#ffffff)
- Border: 1px solid rgba(0,0,0,0.06)
- Border radius: 12px
- Padding: 24px
- Shadow: 0 1px 3px rgba(0,0,0,0.04)
- Hover: shadow 0 4px 12px rgba(0,0,0,0.08), translateY(-2px)

### Inputs
- Border: 1px solid #d0d0d0
- Border radius: 8px
- Padding: 10px 14px
- Focus: border Terracotta Brand, ring 2px rgba(201,100,66,0.2)
- Error: border Error Red, ring 2px rgba(194,65,50,0.2)

### Navigation
...

Rules:

  • Include hover, focus, active, and disabled states
  • Specify transition durations and easing
  • Include touch-target minimum sizes (44x44px)
Section 5: Layout Principles

Spacing system, grid, containers, and whitespace philosophy.

markdown
## 5. Layout Principles

### Spacing Scale (base: 4px)
| Token | Value | Usage |
|-------|-------|-------|
| space-1 | 4px | Tight gaps, icon margins |
| space-2 | 8px | Related element spacing |
| space-3 | 12px | Component internal padding |
| space-4 | 16px | Standard gap between elements |
| space-6 | 24px | Section padding, card padding |
| space-8 | 32px | Between major sections |
| space-12 | 48px | Page-level vertical rhythm |
| space-16 | 64px | Hero/banner spacing |

### Grid
- Max content width: 1200px
- Column count: 12
- Gutter: 24px (space-6)
- Margin: 16px mobile, 24px tablet, auto desktop

### Border Radius Scale
| Token | Value | Usage |
|-------|-------|-------|
| radius-sm | 4px | Badges, tags |
| radius-md | 8px | Buttons, inputs |
| radius-lg | 12px | Cards, panels |
| radius-xl | 16px | Modals, dialogs |
| radius-full | 9999px | Avatars, pills |
Section 6: Depth & Elevation

Shadow system and visual layering.

markdown
## 6. Depth & Elevation

### Shadow Scale
| Level | Value | Usage |
|-------|-------|-------|
| shadow-none | none | Flat elements |
| shadow-sm | 0 1px 2px rgba(0,0,0,0.04) | Subtle lift (cards at rest) |
| shadow-md | 0 4px 12px rgba(0,0,0,0.08) | Hover states, active cards |
| shadow-lg | 0 8px 24px rgba(0,0,0,0.12) | Dropdowns, popovers |
| shadow-xl | 0 16px 48px rgba(0,0,0,0.16) | Modals, dialogs |

### Surface Hierarchy
1. **Base** — page background (Parchment)
2. **Raised** — cards, panels (Ivory White + shadow-sm)
3. **Floating** — dropdowns, tooltips (Ivory White + shadow-lg)
4. **Overlay** — modals, dialogs (Ivory White + shadow-xl + scrim)
Section 7: Do's and Don'ts

Concrete examples with code — not just prose rules.

markdown
## 7. Do's and Don'ts

### DO: Use semantic color names
```css
/* Good */
.button-primary { background: var(--color-terracotta-brand); }
DON'T: Hardcode color values
css
/* Bad */
.button-primary { background: #c96442; }
DO: Follow the spacing scale
css
/* Good — uses scale */
.card { padding: var(--space-6); margin-bottom: var(--space-8); }
DON'T: Use arbitrary spacing
css
/* Bad — 19px is not on the scale */
.card { padding: 19px; margin-bottom: 37px; }
DO: Include all interaction states
DON'T: Skip hover/focus states on interactive elements
DO: Use the type scale for all text
DON'T: Introduce new font sizes not in the scale

### Section 8: Responsive Behavior

Breakpoints, mobile patterns, and adaptation rules.

```markdown
## 8. Responsive Behavior

### Breakpoints
| Name | Width | Target |
|------|-------|--------|
| mobile | < 640px | Phones |
| tablet | 640–1024px | Tablets, small laptops |
| desktop | > 1024px | Laptops, monitors |

### Touch Targets
- Minimum interactive element size: 44x44px
- Minimum spacing between targets: 8px

### Mobile Adaptations
- Navigation collapses to hamburger menu below 640px
- Cards stack single-column below 640px
- Font sizes: H1 reduces to 32px on mobile, H2 to 28px
- Side padding: 16px on mobile, 24px tablet, auto-center desktop

### Behavior Patterns
- Horizontal scrolling: never (use stacking or truncation)
- Images: responsive with srcset, max-width: 100%
- Tables: horizontal scroll wrapper below tablet breakpoint
Section 9: Agent Prompt Guide

How AI agents should use this document when generating UI.

markdown
## 9. Agent Prompt Guide

### Quick Reference
- Primary CTA color: Terracotta Brand (#c96442)
- Background: Parchment (#f5f4ed)
- Heading font: Serif, weight 500
- Body font: Sans, weight 400
- Standard spacing: 24px (space-6)
- Card radius: 12px (radius-lg)

### How to Use This Document
1. Before writing any UI code, read the full DESIGN.md
2. Reference specific section names when implementing: "Following Section 4: Buttons"
3. Use design token names in CSS (var(--color-terracotta-brand)), not raw hex values
4. Check Section 7 (Do's and Don'ts) before submitting
5. If a component is not covered, create it following existing patterns and flag for DESIGN.md update

### Example Component Prompt
"Create a hero section on Parchment (#f5f4ed) with a headline at H1 scale
(48px Serif weight 500, line-height 1.10). Use Near Black (#141413) text.
Add a subtitle in Olive Gray (#5e5d59) at Body scale (16px Sans, line-height 1.60).
Place a Terracotta Brand (#c96442) primary button with Ivory text, radius-md (8px)."

### Iteration Guide
- Change one component at a time
- Reference specific color names and token values
- Describe the component's state (default, hover, active, disabled)
- Specify responsive behavior for the component

Design Token Conventions

Tokens are the bridge between DESIGN.md and code. Consistent naming ensures agents can translate design specs into CSS/Tailwind variables.

Naming Pattern
--{category}-{name}[-{modifier}]
CategoryExamples
color---color-terracotta-brand, --color-near-black, --color-success-green
space---space-1, --space-4, --space-8
text---text-h1, --text-body, --text-caption
radius---radius-sm, --radius-md, --radius-lg
shadow---shadow-sm, --shadow-md, --shadow-lg
font---font-serif, --font-sans, --font-mono
Mapping to CSS Custom Properties

DESIGN.md tokens map directly to CSS custom properties:

css
:root {
  --color-terracotta-brand: #c96442;
  --space-6: 24px;
  --radius-lg: 12px;
  --shadow-sm: 0 1px 2px rgba(0,0,0,0.04);
}
Mapping to Tailwind

When using Tailwind, DESIGN.md tokens map to tailwind.config.js extensions. The builder agent should configure this once and reference throughout.


Integration with Kits

When DESIGN.md exists and kits contain UI requirements, acceptance criteria should reference design tokens by section and name. This creates a traceable chain:

DESIGN.md → Cavekit acceptance criterion → Plan task → Implementation
How to Reference
In Cavekit Acceptance CriteriaDesign Reference
"CTA button uses primary brand styling"DESIGN.md Section 4: Buttons, primary variant
"Headings follow the type hierarchy"DESIGN.md Section 3: Type Scale
"Cards have subtle resting elevation"DESIGN.md Section 6: shadow-sm
"Layout uses the standard grid"DESIGN.md Section 5: Grid
"Colors adapt for dark mode"DESIGN.md Section 2: Dark Mode mapping

Do NOT duplicate DESIGN.md content into kits. Reference by section/token name only. If a color changes in DESIGN.md, kits should not need updating.

When No Design Reference Exists

If a cavekit needs a visual pattern not in DESIGN.md, the acceptance criterion should note this:

markdown
- [ ] Component uses a card-like container [DESIGN.md: pattern not yet defined — flag for design update]

This tells the inspect phase to check whether DESIGN.md needs a new pattern.


Integration with Plans (Architect Phase)

When the architect generates task descriptions for UI work, each task should include:

markdown
**Design Reference:** DESIGN.md Section {N} — {section name}

This tells the task-builder which DESIGN.md sections to read before implementing.


Show full SKILL.md (518 more words)Show less

Integration with Build Phase

Task-builder agents follow this protocol for UI work:

  1. Before implementing: Read DESIGN.md (or the specific sections referenced in the task)
  2. During implementation: Use design tokens, not hardcoded values
  3. In commit messages: Note which DESIGN.md sections were followed
  4. If a new pattern is needed: Implement it following existing DESIGN.md conventions and flag for design update

Revision Patterns

When visual fixes are made manually (outside the Hunt loop), /ck:revise traces them back to DESIGN.md:

Visual Fix Classification
Fix TypeDESIGN.md Action
Color change that should apply globallyUpdate DESIGN.md Section 2 with corrected value
New component pattern not in DESIGN.mdAdd to DESIGN.md Section 4
Spacing adjustment revealing wrong scaleUpdate DESIGN.md Section 5 scale
Typography fixUpdate DESIGN.md Section 3 type scale
Responsive behavior changeUpdate DESIGN.md Section 8
Revision Protocol
  1. Identify the visual change in the diff
  2. Check if DESIGN.md covers this pattern
  3. If not covered: add the pattern to the appropriate section
  4. If covered but wrong: update the token/value
  5. Log the change to context/designs/design-changelog.md

Collection Import

The awesome-design-md repository contains 54+ curated design systems extracted from real products. These serve as starting points.

Import Workflow
  1. Choose a template: vercel, claude, stripe, github, linear, etc.
  2. Fetch the raw DESIGN.md from the collection
  3. Present to the user as a starting point — not a finished product
  4. Walk through each section for customization (brand colors, typography, specific component needs)
  5. Write the customized version to project root
After Import

The imported DESIGN.md becomes the project's own. Future updates are made directly — the import is a seed, not a dependency.


Quality Standards

Completeness Checklist
  • All 9 sections present and non-empty
  • Every color has: semantic name + hex value + functional role
  • Complete typography table (all 5 values per level)
  • Component stylings include hover, focus, active, disabled states
  • Spacing scale is defined with consistent base unit
  • Shadow/elevation scale is defined
  • Breakpoints have specific pixel values
  • Agent Prompt Guide has quick reference and example prompts
Specificity Requirements

Every value in DESIGN.md must be concrete and unambiguous:

Too VagueSpecific Enough
"a warm blue"#3b6fb5 (Info Blue)
"medium spacing"24px (space-6)
"slightly rounded"8px (radius-md)
"subtle shadow"0 1px 2px rgba(0,0,0,0.04) (shadow-sm)
"large heading"48px / 3rem, weight 500, line-height 1.10
Consistency Rules
  • Tokens used in Section 4 (Components) must exist in Sections 2, 3, 5, 6
  • Dark mode mappings must cover every color used in components
  • Responsive changes must reference defined breakpoints
  • All spacing values must be multiples of the base unit

Anti-Patterns

  1. Generic atmosphere — "Clean, modern, professional" describes every SaaS app and none
  2. Missing interaction states — A button without hover/focus is incomplete
  3. Orphan colors — Colors defined in the palette but never used in components
  4. Arbitrary spacing — Values that don't follow the spacing scale
  5. Missing dark mode — If the app supports dark mode, every light color needs a mapping
  6. Hex-only references in components — Use semantic names, not raw values
  7. No Agent Prompt Guide — Section 9 is what makes DESIGN.md actionable for AI agents
  8. Duplicating DESIGN.md into kits — Reference by section/token name only

© JuliusBrussee, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in packages/coding-agent/skills/cavekit-design-system of JuliusBrussee/caveman-code.

Open the folder on GitHubat commit 3a21be1

Compare with similar skills

Cavekit Design System next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Cavekit Design System compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Cavekit Design System this skillJuliusBrussee/caveman-code942—~4.5kAutomated safety check: PassMIT
DesignOhh-889/skyroc7959 repos~3.1kAutomated safety check: PassMIT
Replica DesignJakeschincariol/replica-skill1.2k—~994Automated safety check: PassMIT
Shadcn Tailwind UILiarMTTT/TavernWeave153—~1.7kAutomated safety check: PassCustom licence
Brand DesignEliasOulkadi/shokunin114—~3kAutomated safety check: PassMIT
Figma Design System Builderwarpdotdev/warp65k2 repos~4.4kAutomated safety check: PassAGPL-3.0

Similar skills

  • Design

    Ohh-889/skyroc

    Comprehensive design skill: brand identity, design tokens, UI styling, logo generation (55 styles, Gemini AI), corporate identity program (50 deliverables, CIP mockups), HTML presentations…

    795 GitHub starsUsed in 9 repos~3.1k tokens
    Frontend & DesignAuto-check passed
  • Replica Design

    Jakeschincariol/replica-skill

    Rebuilds an app's design system for a clone: colour roles, type scale, spacing, radius, shadows and every component with its states, as design tokens plus component specs, with original assets…

    1.2k GitHub stars~994 tokensUpdated 6 days ago
    Frontend & DesignAuto-check passed
  • Shadcn Tailwind UI

    LiarMTTT/TavernWeave

    Build, restyle, or review accessible React interfaces that use shadcn/ui, Radix UI primitives, and Tailwind CSS.

    153 GitHub stars~1.7k tokensUpdated 5 days ago
    Frontend & DesignAuto-check passed
  • Brand Design

    EliasOulkadi/shokunin

    Generate brand guidelines, design systems with design tokens (W3C format), creative direction (SCAMPER, Design Thinking, TRIZ), and design briefs with scope and success criteria.

    114 GitHub stars~3k tokensUpdated 5 days ago
    Frontend & DesignAuto-check passed
  • Builds or updates a design system in Figma from a codebase in ordered phases: discovery, variables and tokens, components, theming and documentation, with checkpoints.

    65k GitHub starsUsed in 2 repos~4.4k tokens
    Frontend & DesignAuto-check passed
  • Required groundwork before any use_figma call: the rules and reference files for running JavaScript in a Figma file through the Plugin API without common failures.

    65k GitHub starsUsed in 4 repos~4.4k tokens
    Frontend & DesignAuto-check passed

More from JuliusBrussee/caveman-code

  • Cavekit Methodology

    JuliusBrussee/caveman-code

    Cavekit specification-driven development methodology — the Hunt lifecycle (Draft → Architect → Build → Inspect → Monitor) and how to apply it.

    942 GitHub stars~3.3k tokensUpdated 1 mo ago
    Auto-check passed
  • Cavekit Revision

    JuliusBrussee/caveman-code

    Trace bugs and manual fixes back to kits and prompts; fix at the source so the iteration loop can reproduce the fix autonomously.

    942 GitHub stars~3.6k tokensUpdated 1 mo ago
    Auto-check passed
  • Cavekit Validation First

    JuliusBrussee/caveman-code

    Validation-first design for Cavekit — every kit requirement must be automatically verifiable.

    942 GitHub stars~4.3k tokensUpdated 1 mo ago
    Auto-check passed
  • Caveman Memory File Compressor

    JuliusBrussee/caveman-code

    Rewrites a memory file such as CLAUDE.md or a todo list in terse caveman-style text to cut input tokens, saving a readable backup outside the project tree.

    942 GitHub stars~1.2k tokensUpdated 1 mo ago
    Auto-check passed
  • Plugin Creator

    JuliusBrussee/caveman-code

    Scaffold a complete cave plugin bundle — generates .cave-plugin/plugin.json manifest and the standard directory structure (commands/, skills/, agents/, themes/, hooks/).

    942 GitHub stars~1.1k tokensUpdated 1 mo ago
    Auto-check passed

Questions about Cavekit Design System

What does Cavekit Design System do?

How to write and maintain DESIGN.md as the visual specification layer for Cavekit projects. Cavekit Design System is an agent skill from JuliusBrussee/caveman-code.md as the visual specification layer for Cavekit projects.

When should I use Cavekit Design System?

Cavekit Design System fits situations like: revising visual identity; importing a third-party design system; auditing UI code against design tokens.

How do I install Cavekit Design System in Claude Code?

Run `npx skills add JuliusBrussee/caveman-code --skill cavekit-design-system -a claude-code`. Or copy the skill folder (packages/coding-agent/skills/cavekit-design-system in JuliusBrussee/caveman-code) into .claude/skills/cavekit-design-system in your project. Claude Code loads it when a task matches its description.

How do I install Cavekit Design System in Codex?

Run `npx skills add JuliusBrussee/caveman-code --skill cavekit-design-system -a codex`. Or copy the skill folder (packages/coding-agent/skills/cavekit-design-system in JuliusBrussee/caveman-code) into .agents/skills/cavekit-design-system in your project. Codex loads it when a task matches its description.

Can I use Cavekit Design System in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add JuliusBrussee/caveman-code --skill cavekit-design-system -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/cavekit-design-system, .gemini/skills/cavekit-design-system, .github/skills/cavekit-design-system and .opencode/skills/cavekit-design-system in your project.

What does Cavekit Design System need to run?

SKILL.md names no scripts, command-line tools or credentials: Cavekit Design System is instructions for the agent only. Its frontmatter pre-approves these tools: read, grep, edit.

Does Cavekit Design System access the network?

SKILL.md names 2 domains. As links in the text: stitch.withgoogle.com and github.com. This is read from the text; nothing was executed.

Is Cavekit Design System safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Cavekit Design System use?

Cavekit Design System is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Cavekit Design System use?

About 4.5k tokens (SKILL.md is roughly 18k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Cavekit Design System?

Skills that share tags, products or a category with Cavekit Design System: Design (Ohh-889/skyroc, 795 stars), Replica Design (Jakeschincariol/replica-skill, 1.2k stars), Shadcn Tailwind UI (LiarMTTT/TavernWeave, 153 stars) and Brand Design (EliasOulkadi/shokunin, 114 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Cavekit Design System?

JuliusBrussee (a GitHub user) maintains it in JuliusBrussee/caveman-code, which has 942 GitHub stars. The repository holds 6 skills in this directory. The repository was last updated on August 14, 2026.

Source: JuliusBrussee/caveman-code on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.