[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6M9HPZ609HSVJMCPKSAXMAR":3,"skill-same:01M6M9HPZ609HSVJMCPKSAXMAR":90},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":61,"linkOnly":62,"markdownContent":63,"markdownBody":64,"frontMatter":65,"refName":66,"commitSha":67,"skillDirectory":68,"forksCount":69,"repositoryHtmlUrl":70,"repositoryHomepageUrl":71,"ownerHtmlUrl":72,"ownerBlogUrl":73,"ownerDescription":74,"updatedAt":75,"install":76,"resources":89},"01M6M9HPZ609HSVJMCPKSAXMAR","design-system",null,"How to write and maintain a DESIGN.md in the 9-section Google Stitch format.\nCovers the 9-section structure, design token conventions, quality standards,\nintegration with kits and build tasks, revision patterns, and collection import.\nTrigger phrases: \"design system\", \"DESIGN.md\", \"visual design spec\",\n\"design tokens\", \"create design system\", \"import design system\",\n\"visual identity\", \"UI spec\", \"design language\"","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1559,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FJuliusBrussee\u002Fblueprint\u002Fskills\u002Fdesign-system\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60],"design system","system","design","build","section","google stitch","design language","design spec","design token","revision","import","how to","tokens","token","visual","structure","maintain","stitch","visual design","standards","write","quality","how","collection","ui","create","tasks","identity","google","2026-11-10 10:12:30",false,"---\nname: design-system\ndescription: |\n  How to write and maintain a DESIGN.md in the 9-section Google Stitch format.\n  Covers the 9-section structure, design token conventions, quality standards,\n  integration with kits and build tasks, revision patterns, and collection import.\n  Trigger phrases: \"design system\", \"DESIGN.md\", \"visual design spec\",\n  \"design tokens\", \"create design system\", \"import design system\",\n  \"visual identity\", \"UI spec\", \"design language\"\n---\n\n# Design System: DESIGN.md for AI Agents\n\n## Core Principle: DESIGN.md Describes WHAT It Looks Like, Not HOW to Build It\n\nDESIGN.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.\n\n| Document | Defines | Audience |\n|----------|---------|----------|\n| CLAUDE.md | How to build the project | Coding agents |\n| Kits | What must be true (behavior) | All agents |\n| **DESIGN.md** | **What it looks like (visual)** | **UI-building agents** |\n| Plans | How to build it (tasks) | Builder agents |\n\n### Why a Dedicated Design System Document?\n\nWithout DESIGN.md, visual decisions scatter across kits, plans, and code:\n- Colors get hardcoded differently per component\n- Typography choices vary between agents and sessions\n- Spacing becomes inconsistent across the UI\n- New components reinvent patterns that already exist\n\nDESIGN.md centralizes these decisions. Every agent reads it before writing UI code.\n\n---\n\n## The 9-Section Stitch Format\n\nDESIGN.md follows the [Google Stitch format](https:\u002F\u002Fstitch.withgoogle.com\u002Fdocs\u002Fdesign-md\u002Foverview\u002F) — 9 sections that together define a complete visual language. Every DESIGN.md must contain all 9 sections.\n\n### Section 1: Visual Theme & Atmosphere\n\nThe design philosophy, mood, and overall aesthetic. Use evocative, specific language — not generic terms like \"clean and modern.\"\n\n```markdown\n## 1. Visual Theme & Atmosphere\n\nThis is a warm editorial experience built on natural materials. Think: a well-curated\nbookshop with soft overhead lighting and carefully chosen display shelves. The density\nis low — generous whitespace signals confidence and clarity. Every element earns its\nplace; nothing decorative exists without functional purpose.\n\n**Key attributes:** Warm, unhurried, editorial, confident\n**Density:** Low — generous whitespace, single-column focus\n**Personality:** Thoughtful librarian, not flashy storefront\n```\n\n**What good looks like:** A new designer reading this section could sketch a rough layout without seeing any other section.\n\n**Anti-pattern:** \"Clean, modern, and professional\" — this describes nothing specific.\n\n### Section 2: Color Palette & Roles\n\nEvery color needs three things: a semantic name, a hex value, and a functional role.\n\n```markdown\n## 2. Color Palette & Roles\n\n### Primary\n| Name | Hex | Role |\n|------|-----|------|\n| Terracotta Brand | #c96442 | Primary CTA, active states, brand anchors |\n| Terracotta Hover | #b85838 | Hover\u002Fpressed state for primary actions |\n\n### Neutral\n| Name | Hex | Role |\n|------|-----|------|\n| Near Black | #141413 | Primary text, headings |\n| Olive Gray | #5e5d59 | Secondary text, captions |\n| Parchment | #f5f4ed | Page background, default canvas |\n| Ivory White | #ffffff | Card surfaces, overlays |\n\n### Semantic\n| Name | Hex | Role |\n|------|-----|------|\n| Success Green | #2d7d46 | Confirmation, success states |\n| Warning Amber | #c27217 | Warnings, attention needed |\n| Error Red | #c24132 | Errors, destructive actions |\n| Info Blue | #3b6fb5 | Informational states, links |\n\n### Dark Mode (if applicable)\n| Light Name | Dark Equivalent | Hex |\n|------------|----------------|-----|\n| Parchment | Deep Charcoal | #1a1a1a |\n| Near Black | Off White | #e8e8e8 |\n```\n\n**Rules:**\n- Every hex value must be verified against the actual design or live site\n- Every color must have a clear functional role — no orphan colors\n- Name colors semantically (by role), not by hue (\"Primary CTA\" not \"Orange\")\n- If dark mode exists, map every light color to its dark equivalent\n\n### Section 3: Typography Rules\n\nComplete type hierarchy with specific values — no \"roughly 16px\" or \"medium weight.\"\n\n```markdown\n## 3. Typography Rules\n\n### Font Stack\n- **Display\u002FHeading:** \"Anthropic Serif\", Georgia, \"Times New Roman\", serif\n- **Body:** \"Anthropic Sans\", -apple-system, BlinkMacSystemFont, sans-serif\n- **Code:** \"Anthropic Mono\", \"SF Mono\", \"Fira Code\", monospace\n\n### Type Scale\n| Level | Size | Weight | Line Height | Letter Spacing | Font |\n|-------|------|--------|-------------|----------------|------|\n| H1 | 48px \u002F 3rem | 500 | 1.10 | -0.02em | Serif |\n| H2 | 36px \u002F 2.25rem | 500 | 1.15 | -0.01em | Serif |\n| H3 | 24px \u002F 1.5rem | 500 | 1.25 | 0 | Serif |\n| H4 | 20px \u002F 1.25rem | 600 | 1.30 | 0 | Sans |\n| Body | 16px \u002F 1rem | 400 | 1.60 | 0 | Sans |\n| Small | 14px \u002F 0.875rem | 400 | 1.50 | 0.01em | Sans |\n| Caption | 12px \u002F 0.75rem | 500 | 1.40 | 0.02em | Sans |\n\n### Principles\n- Headings use serif for warmth and authority\n- Body text uses sans-serif for readability at small sizes\n- Maximum line length: 65ch for body text\n- Minimum font size: 14px (never go below)\n```\n\n**Rules:**\n- Every level in the scale must have all 5 values (size, weight, line-height, letter-spacing, font)\n- Use rem alongside px for accessibility\n- Include font stack fallbacks\n\n### Section 4: Component Stylings\n\nConcrete styling for common components including interaction states.\n\n```markdown\n## 4. Component Stylings\n\n### Buttons\n**Primary:**\n- Background: Terracotta Brand (#c96442)\n- Text: Ivory White (#ffffff), 16px Sans, weight 500\n- Padding: 12px 24px\n- Border radius: 8px\n- Hover: Terracotta Hover (#b85838), translateY(-1px), shadow-sm\n- Active: translateY(0), shadow-none\n- Disabled: opacity 0.5, cursor not-allowed\n- Transition: all 150ms ease-out\n\n**Secondary:**\n- Background: transparent\n- Border: 1px solid Olive Gray (#5e5d59)\n- Text: Near Black (#141413)\n- Hover: background Parchment (#f5f4ed)\n\n### Cards\n- Background: Ivory White (#ffffff)\n- Border: 1px solid rgba(0,0,0,0.06)\n- Border radius: 12px\n- Padding: 24px\n- Shadow: 0 1px 3px rgba(0,0,0,0.04)\n- Hover: shadow 0 4px 12px rgba(0,0,0,0.08), translateY(-2px)\n\n### Inputs\n- Border: 1px solid #d0d0d0\n- Border radius: 8px\n- Padding: 10px 14px\n- Focus: border Terracotta Brand, ring 2px rgba(201,100,66,0.2)\n- Error: border Error Red, ring 2px rgba(194,65,50,0.2)\n\n### Navigation\n...\n```\n\n**Rules:**\n- Include hover, focus, active, and disabled states\n- Specify transition durations and easing\n- Include touch-target minimum sizes (44x44px)\n\n### Section 5: Layout Principles\n\nSpacing system, grid, containers, and whitespace philosophy.\n\n```markdown\n## 5. Layout Principles\n\n### Spacing Scale (base: 4px)\n| Token | Value | Usage |\n|-------|-------|-------|\n| space-1 | 4px | Tight gaps, icon margins |\n| space-2 | 8px | Related element spacing |\n| space-3 | 12px | Component internal padding |\n| space-4 | 16px | Standard gap between elements |\n| space-6 | 24px | Section padding, card padding |\n| space-8 | 32px | Between major sections |\n| space-12 | 48px | Page-level vertical rhythm |\n| space-16 | 64px | Hero\u002Fbanner spacing |\n\n### Grid\n- Max content width: 1200px\n- Column count: 12\n- Gutter: 24px (space-6)\n- Margin: 16px mobile, 24px tablet, auto desktop\n\n### Border Radius Scale\n| Token | Value | Usage |\n|-------|-------|-------|\n| radius-sm | 4px | Badges, tags |\n| radius-md | 8px | Buttons, inputs |\n| radius-lg | 12px | Cards, panels |\n| radius-xl | 16px | Modals, dialogs |\n| radius-full | 9999px | Avatars, pills |\n```\n\n### Section 6: Depth & Elevation\n\nShadow system and visual layering.\n\n```markdown\n## 6. Depth & Elevation\n\n### Shadow Scale\n| Level | Value | Usage |\n|-------|-------|-------|\n| shadow-none | none | Flat elements |\n| shadow-sm | 0 1px 2px rgba(0,0,0,0.04) | Subtle lift (cards at rest) |\n| shadow-md | 0 4px 12px rgba(0,0,0,0.08) | Hover states, active cards |\n| shadow-lg | 0 8px 24px rgba(0,0,0,0.12) | Dropdowns, popovers |\n| shadow-xl | 0 16px 48px rgba(0,0,0,0.16) | Modals, dialogs |\n\n### Surface Hierarchy\n1. **Base** — page background (Parchment)\n2. **Raised** — cards, panels (Ivory White + shadow-sm)\n3. **Floating** — dropdowns, tooltips (Ivory White + shadow-lg)\n4. **Overlay** — modals, dialogs (Ivory White + shadow-xl + scrim)\n```\n\n### Section 7: Do's and Don'ts\n\nConcrete examples with code — not just prose rules.\n\n```markdown\n## 7. Do's and Don'ts\n\n### DO: Use semantic color names\n```css\n\u002F* Good *\u002F\n.button-primary { background: var(--color-terracotta-brand); }\n```\n\n### DON'T: Hardcode color values\n```css\n\u002F* Bad *\u002F\n.button-primary { background: #c96442; }\n```\n\n### DO: Follow the spacing scale\n```css\n\u002F* Good — uses scale *\u002F\n.card { padding: var(--space-6); margin-bottom: var(--space-8); }\n```\n\n### DON'T: Use arbitrary spacing\n```css\n\u002F* Bad — 19px is not on the scale *\u002F\n.card { padding: 19px; margin-bottom: 37px; }\n```\n\n### DO: Include all interaction states\n### DON'T: Skip hover\u002Ffocus states on interactive elements\n### DO: Use the type scale for all text\n### DON'T: Introduce new font sizes not in the scale\n```\n\n### Section 8: Responsive Behavior\n\nBreakpoints, mobile patterns, and adaptation rules.\n\n```markdown\n## 8. Responsive Behavior\n\n### Breakpoints\n| Name | Width | Target |\n|------|-------|--------|\n| mobile | \u003C 640px | Phones |\n| tablet | 640–1024px | Tablets, small laptops |\n| desktop | > 1024px | Laptops, monitors |\n\n### Touch Targets\n- Minimum interactive element size: 44x44px\n- Minimum spacing between targets: 8px\n\n### Mobile Adaptations\n- Navigation collapses to hamburger menu below 640px\n- Cards stack single-column below 640px\n- Font sizes: H1 reduces to 32px on mobile, H2 to 28px\n- Side padding: 16px on mobile, 24px tablet, auto-center desktop\n\n### Behavior Patterns\n- Horizontal scrolling: never (use stacking or truncation)\n- Images: responsive with srcset, max-width: 100%\n- Tables: horizontal scroll wrapper below tablet breakpoint\n```\n\n### Section 9: Agent Prompt Guide\n\nHow AI agents should use this document when generating UI.\n\n```markdown\n## 9. Agent Prompt Guide\n\n### Quick Reference\n- Primary CTA color: Terracotta Brand (#c96442)\n- Background: Parchment (#f5f4ed)\n- Heading font: Serif, weight 500\n- Body font: Sans, weight 400\n- Standard spacing: 24px (space-6)\n- Card radius: 12px (radius-lg)\n\n### How to Use This Document\n1. Before writing any UI code, read the full DESIGN.md\n2. Reference specific section names when implementing: \"Following Section 4: Buttons\"\n3. Use design token names in CSS (var(--color-terracotta-brand)), not raw hex values\n4. Check Section 7 (Do's and Don'ts) before submitting\n5. If a component is not covered, create it following existing patterns and flag for DESIGN.md update\n\n### Example Component Prompt\n\"Create a hero section on Parchment (#f5f4ed) with a headline at H1 scale\n(48px Serif weight 500, line-height 1.10). Use Near Black (#141413) text.\nAdd a subtitle in Olive Gray (#5e5d59) at Body scale (16px Sans, line-height 1.60).\nPlace a Terracotta Brand (#c96442) primary button with Ivory text, radius-md (8px).\"\n\n### Iteration Guide\n- Change one component at a time\n- Reference specific color names and token values\n- Describe the component's state (default, hover, active, disabled)\n- Specify responsive behavior for the component\n```\n\n---\n\n## Design Token Conventions\n\nTokens are the bridge between DESIGN.md and code. Consistent naming ensures agents can translate design specs into CSS\u002FTailwind variables.\n\n### Naming Pattern\n\n```\n--{category}-{name}[-{modifier}]\n```\n\n| Category | Examples |\n|----------|---------|\n| `color-` | `--color-terracotta-brand`, `--color-near-black`, `--color-success-green` |\n| `space-` | `--space-1`, `--space-4`, `--space-8` |\n| `text-` | `--text-h1`, `--text-body`, `--text-caption` |\n| `radius-` | `--radius-sm`, `--radius-md`, `--radius-lg` |\n| `shadow-` | `--shadow-sm`, `--shadow-md`, `--shadow-lg` |\n| `font-` | `--font-serif`, `--font-sans`, `--font-mono` |\n\n### Mapping to CSS Custom Properties\n\nDESIGN.md tokens map directly to CSS custom properties:\n```css\n:root {\n  --color-terracotta-brand: #c96442;\n  --space-6: 24px;\n  --radius-lg: 12px;\n  --shadow-sm: 0 1px 2px rgba(0,0,0,0.04);\n}\n```\n\n### Mapping to Tailwind\n\nWhen using Tailwind, DESIGN.md tokens map to `tailwind.config.js` extensions. The builder agent should configure this once and reference throughout.\n\n---\n\n## Integration with Kits\n\nWhen DESIGN.md exists and kits contain UI requirements, acceptance criteria should reference design tokens by section and name. This creates a traceable chain:\n\n```\nDESIGN.md → Cavekit acceptance criterion → Plan task → Implementation\n```\n\n### How to Reference\n\n| In Cavekit Acceptance Criteria | Design Reference |\n|----------------------------------|-----------------|\n| \"CTA button uses primary brand styling\" | DESIGN.md Section 4: Buttons, primary variant |\n| \"Headings follow the type hierarchy\" | DESIGN.md Section 3: Type Scale |\n| \"Cards have subtle resting elevation\" | DESIGN.md Section 6: shadow-sm |\n| \"Layout uses the standard grid\" | DESIGN.md Section 5: Grid |\n| \"Colors adapt for dark mode\" | DESIGN.md Section 2: Dark Mode mapping |\n\n**Do NOT duplicate DESIGN.md content into kits.** Reference by section\u002Ftoken name only. If a color changes in DESIGN.md, kits should not need updating.\n\n### When No Design Reference Exists\n\nIf a cavekit needs a visual pattern not in DESIGN.md, the acceptance criterion should note this:\n```markdown\n- [ ] Component uses a card-like container [DESIGN.md: pattern not yet defined — flag for design update]\n```\n\nThis tells the inspect phase to check whether DESIGN.md needs a new pattern.\n\n---\n\n## Integration with Plans (Architect Phase)\n\nWhen the architect generates task descriptions for UI work, each task should include:\n\n```markdown\n**Design Reference:** DESIGN.md Section {N} — {section name}\n```\n\nThis tells the task-builder which DESIGN.md sections to read before implementing.\n\n---\n\n## Integration with Build Phase\n\nTask-builder agents follow this protocol for UI work:\n\n1. **Before implementing:** Read DESIGN.md (or the specific sections referenced in the task)\n2. **During implementation:** Use design tokens, not hardcoded values\n3. **In commit messages:** Note which DESIGN.md sections were followed\n4. **If a new pattern is needed:** Implement it following existing DESIGN.md conventions and flag for design update\n\n---\n\n## Revision Patterns\n\nWhen visual fixes are made manually (outside the Hunt loop), `\u002Fck:revise` traces them back to DESIGN.md:\n\n### Visual Fix Classification\n\n| Fix Type | DESIGN.md Action |\n|----------|-----------------|\n| Color change that should apply globally | Update DESIGN.md Section 2 with corrected value |\n| New component pattern not in DESIGN.md | Add to DESIGN.md Section 4 |\n| Spacing adjustment revealing wrong scale | Update DESIGN.md Section 5 scale |\n| Typography fix | Update DESIGN.md Section 3 type scale |\n| Responsive behavior change | Update DESIGN.md Section 8 |\n\n### Revision Protocol\n\n1. Identify the visual change in the diff\n2. Check if DESIGN.md covers this pattern\n3. If not covered: add the pattern to the appropriate section\n4. If covered but wrong: update the token\u002Fvalue\n5. Log the change to `context\u002Fdesigns\u002Fdesign-changelog.md`\n\n---\n\n## Collection Import\n\nThe [awesome-design-md](https:\u002F\u002Fgithub.com\u002FVoltAgent\u002Fawesome-design-md) repository contains 54+ curated design systems extracted from real products. These serve as starting points.\n\n### Import Workflow\n\n1. **Choose a template:** `vercel`, `claude`, `stripe`, `github`, `linear`, etc.\n2. **Fetch the raw DESIGN.md** from the collection\n3. **Present to the user** as a starting point — not a finished product\n4. **Walk through each section** for customization (brand colors, typography, specific component needs)\n5. **Write the customized version** to project root\n\n### After Import\n\nThe imported DESIGN.md becomes the project's own. Future updates are made directly — the import is a seed, not a dependency.\n\n---\n\n## Quality Standards\n\n### Completeness Checklist\n\n- [ ] All 9 sections present and non-empty\n- [ ] Every color has: semantic name + hex value + functional role\n- [ ] Complete typography table (all 5 values per level)\n- [ ] Component stylings include hover, focus, active, disabled states\n- [ ] Spacing scale is defined with consistent base unit\n- [ ] Shadow\u002Felevation scale is defined\n- [ ] Breakpoints have specific pixel values\n- [ ] Agent Prompt Guide has quick reference and example prompts\n\n### Specificity Requirements\n\nEvery value in DESIGN.md must be concrete and unambiguous:\n\n| Too Vague | Specific Enough |\n|-----------|----------------|\n| \"a warm blue\" | `#3b6fb5` (Info Blue) |\n| \"medium spacing\" | `24px` (space-6) |\n| \"slightly rounded\" | `8px` (radius-md) |\n| \"subtle shadow\" | `0 1px 2px rgba(0,0,0,0.04)` (shadow-sm) |\n| \"large heading\" | `48px \u002F 3rem, weight 500, line-height 1.10` |\n\n### Consistency Rules\n\n- Tokens used in Section 4 (Components) must exist in Sections 2, 3, 5, 6\n- Dark mode mappings must cover every color used in components\n- Responsive changes must reference defined breakpoints\n- All spacing values must be multiples of the base unit\n\n---\n\n## Anti-Patterns\n\n1. **Generic atmosphere** — \"Clean, modern, professional\" describes every SaaS app and none\n2. **Missing interaction states** — A button without hover\u002Ffocus is incomplete\n3. **Orphan colors** — Colors defined in the palette but never used in components\n4. **Arbitrary spacing** — Values that don't follow the spacing scale\n5. **Missing dark mode** — If the app supports dark mode, every light color needs a mapping\n6. **Hex-only references in components** — Use semantic names, not raw values\n7. **No Agent Prompt Guide** — Section 9 is what makes DESIGN.md actionable for AI agents\n8. **Duplicating DESIGN.md into kits** — Reference by section\u002Ftoken name only\n","# Design System: DESIGN.md for AI Agents\n\n## Core Principle: DESIGN.md Describes WHAT It Looks Like, Not HOW to Build It\n\nDESIGN.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.\n\n| Document | Defines | Audience |\n|----------|---------|----------|\n| CLAUDE.md | How to build the project | Coding agents |\n| Kits | What must be true (behavior) | All agents |\n| **DESIGN.md** | **What it looks like (visual)** | **UI-building agents** |\n| Plans | How to build it (tasks) | Builder agents |\n\n### Why a Dedicated Design System Document?\n\nWithout DESIGN.md, visual decisions scatter across kits, plans, and code:\n- Colors get hardcoded differently per component\n- Typography choices vary between agents and sessions\n- Spacing becomes inconsistent across the UI\n- New components reinvent patterns that already exist\n\nDESIGN.md centralizes these decisions. Every agent reads it before writing UI code.\n\n---\n\n## The 9-Section Stitch Format\n\nDESIGN.md follows the [Google Stitch format](https:\u002F\u002Fstitch.withgoogle.com\u002Fdocs\u002Fdesign-md\u002Foverview\u002F) — 9 sections that together define a complete visual language. Every DESIGN.md must contain all 9 sections.\n\n### Section 1: Visual Theme & Atmosphere\n\nThe design philosophy, mood, and overall aesthetic. Use evocative, specific language — not generic terms like \"clean and modern.\"\n\n```markdown\n## 1. Visual Theme & Atmosphere\n\nThis is a warm editorial experience built on natural materials. Think: a well-curated\nbookshop with soft overhead lighting and carefully chosen display shelves. The density\nis low — generous whitespace signals confidence and clarity. Every element earns its\nplace; nothing decorative exists without functional purpose.\n\n**Key attributes:** Warm, unhurried, editorial, confident\n**Density:** Low — generous whitespace, single-column focus\n**Personality:** Thoughtful librarian, not flashy storefront\n```\n\n**What good looks like:** A new designer reading this section could sketch a rough layout without seeing any other section.\n\n**Anti-pattern:** \"Clean, modern, and professional\" — this describes nothing specific.\n\n### Section 2: Color Palette & Roles\n\nEvery color needs three things: a semantic name, a hex value, and a functional role.\n\n```markdown\n## 2. Color Palette & Roles\n\n### Primary\n| Name | Hex | Role |\n|------|-----|------|\n| Terracotta Brand | #c96442 | Primary CTA, active states, brand anchors |\n| Terracotta Hover | #b85838 | Hover\u002Fpressed state for primary actions |\n\n### Neutral\n| Name | Hex | Role |\n|------|-----|------|\n| Near Black | #141413 | Primary text, headings |\n| Olive Gray | #5e5d59 | Secondary text, captions |\n| Parchment | #f5f4ed | Page background, default canvas |\n| Ivory White | #ffffff | Card surfaces, overlays |\n\n### Semantic\n| Name | Hex | Role |\n|------|-----|------|\n| Success Green | #2d7d46 | Confirmation, success states |\n| Warning Amber | #c27217 | Warnings, attention needed |\n| Error Red | #c24132 | Errors, destructive actions |\n| Info Blue | #3b6fb5 | Informational states, links |\n\n### Dark Mode (if applicable)\n| Light Name | Dark Equivalent | Hex |\n|------------|----------------|-----|\n| Parchment | Deep Charcoal | #1a1a1a |\n| Near Black | Off White | #e8e8e8 |\n```\n\n**Rules:**\n- Every hex value must be verified against the actual design or live site\n- Every color must have a clear functional role — no orphan colors\n- Name colors semantically (by role), not by hue (\"Primary CTA\" not \"Orange\")\n- If dark mode exists, map every light color to its dark equivalent\n\n### Section 3: Typography Rules\n\nComplete type hierarchy with specific values — no \"roughly 16px\" or \"medium weight.\"\n\n```markdown\n## 3. Typography Rules\n\n### Font Stack\n- **Display\u002FHeading:** \"Anthropic Serif\", Georgia, \"Times New Roman\", serif\n- **Body:** \"Anthropic Sans\", -apple-system, BlinkMacSystemFont, sans-serif\n- **Code:** \"Anthropic Mono\", \"SF Mono\", \"Fira Code\", monospace\n\n### Type Scale\n| Level | Size | Weight | Line Height | Letter Spacing | Font |\n|-------|------|--------|-------------|----------------|------|\n| H1 | 48px \u002F 3rem | 500 | 1.10 | -0.02em | Serif |\n| H2 | 36px \u002F 2.25rem | 500 | 1.15 | -0.01em | Serif |\n| H3 | 24px \u002F 1.5rem | 500 | 1.25 | 0 | Serif |\n| H4 | 20px \u002F 1.25rem | 600 | 1.30 | 0 | Sans |\n| Body | 16px \u002F 1rem | 400 | 1.60 | 0 | Sans |\n| Small | 14px \u002F 0.875rem | 400 | 1.50 | 0.01em | Sans |\n| Caption | 12px \u002F 0.75rem | 500 | 1.40 | 0.02em | Sans |\n\n### Principles\n- Headings use serif for warmth and authority\n- Body text uses sans-serif for readability at small sizes\n- Maximum line length: 65ch for body text\n- Minimum font size: 14px (never go below)\n```\n\n**Rules:**\n- Every level in the scale must have all 5 values (size, weight, line-height, letter-spacing, font)\n- Use rem alongside px for accessibility\n- Include font stack fallbacks\n\n### Section 4: Component Stylings\n\nConcrete styling for common components including interaction states.\n\n```markdown\n## 4. Component Stylings\n\n### Buttons\n**Primary:**\n- Background: Terracotta Brand (#c96442)\n- Text: Ivory White (#ffffff), 16px Sans, weight 500\n- Padding: 12px 24px\n- Border radius: 8px\n- Hover: Terracotta Hover (#b85838), translateY(-1px), shadow-sm\n- Active: translateY(0), shadow-none\n- Disabled: opacity 0.5, cursor not-allowed\n- Transition: all 150ms ease-out\n\n**Secondary:**\n- Background: transparent\n- Border: 1px solid Olive Gray (#5e5d59)\n- Text: Near Black (#141413)\n- Hover: background Parchment (#f5f4ed)\n\n### Cards\n- Background: Ivory White (#ffffff)\n- Border: 1px solid rgba(0,0,0,0.06)\n- Border radius: 12px\n- Padding: 24px\n- Shadow: 0 1px 3px rgba(0,0,0,0.04)\n- Hover: shadow 0 4px 12px rgba(0,0,0,0.08), translateY(-2px)\n\n### Inputs\n- Border: 1px solid #d0d0d0\n- Border radius: 8px\n- Padding: 10px 14px\n- Focus: border Terracotta Brand, ring 2px rgba(201,100,66,0.2)\n- Error: border Error Red, ring 2px rgba(194,65,50,0.2)\n\n### Navigation\n...\n```\n\n**Rules:**\n- Include hover, focus, active, and disabled states\n- Specify transition durations and easing\n- Include touch-target minimum sizes (44x44px)\n\n### Section 5: Layout Principles\n\nSpacing system, grid, containers, and whitespace philosophy.\n\n```markdown\n## 5. Layout Principles\n\n### Spacing Scale (base: 4px)\n| Token | Value | Usage |\n|-------|-------|-------|\n| space-1 | 4px | Tight gaps, icon margins |\n| space-2 | 8px | Related element spacing |\n| space-3 | 12px | Component internal padding |\n| space-4 | 16px | Standard gap between elements |\n| space-6 | 24px | Section padding, card padding |\n| space-8 | 32px | Between major sections |\n| space-12 | 48px | Page-level vertical rhythm |\n| space-16 | 64px | Hero\u002Fbanner spacing |\n\n### Grid\n- Max content width: 1200px\n- Column count: 12\n- Gutter: 24px (space-6)\n- Margin: 16px mobile, 24px tablet, auto desktop\n\n### Border Radius Scale\n| Token | Value | Usage |\n|-------|-------|-------|\n| radius-sm | 4px | Badges, tags |\n| radius-md | 8px | Buttons, inputs |\n| radius-lg | 12px | Cards, panels |\n| radius-xl | 16px | Modals, dialogs |\n| radius-full | 9999px | Avatars, pills |\n```\n\n### Section 6: Depth & Elevation\n\nShadow system and visual layering.\n\n```markdown\n## 6. Depth & Elevation\n\n### Shadow Scale\n| Level | Value | Usage |\n|-------|-------|-------|\n| shadow-none | none | Flat elements |\n| shadow-sm | 0 1px 2px rgba(0,0,0,0.04) | Subtle lift (cards at rest) |\n| shadow-md | 0 4px 12px rgba(0,0,0,0.08) | Hover states, active cards |\n| shadow-lg | 0 8px 24px rgba(0,0,0,0.12) | Dropdowns, popovers |\n| shadow-xl | 0 16px 48px rgba(0,0,0,0.16) | Modals, dialogs |\n\n### Surface Hierarchy\n1. **Base** — page background (Parchment)\n2. **Raised** — cards, panels (Ivory White + shadow-sm)\n3. **Floating** — dropdowns, tooltips (Ivory White + shadow-lg)\n4. **Overlay** — modals, dialogs (Ivory White + shadow-xl + scrim)\n```\n\n### Section 7: Do's and Don'ts\n\nConcrete examples with code — not just prose rules.\n\n```markdown\n## 7. Do's and Don'ts\n\n### DO: Use semantic color names\n```css\n\u002F* Good *\u002F\n.button-primary { background: var(--color-terracotta-brand); }\n```\n\n### DON'T: Hardcode color values\n```css\n\u002F* Bad *\u002F\n.button-primary { background: #c96442; }\n```\n\n### DO: Follow the spacing scale\n```css\n\u002F* Good — uses scale *\u002F\n.card { padding: var(--space-6); margin-bottom: var(--space-8); }\n```\n\n### DON'T: Use arbitrary spacing\n```css\n\u002F* Bad — 19px is not on the scale *\u002F\n.card { padding: 19px; margin-bottom: 37px; }\n```\n\n### DO: Include all interaction states\n### DON'T: Skip hover\u002Ffocus states on interactive elements\n### DO: Use the type scale for all text\n### DON'T: Introduce new font sizes not in the scale\n```\n\n### Section 8: Responsive Behavior\n\nBreakpoints, mobile patterns, and adaptation rules.\n\n```markdown\n## 8. Responsive Behavior\n\n### Breakpoints\n| Name | Width | Target |\n|------|-------|--------|\n| mobile | \u003C 640px | Phones |\n| tablet | 640–1024px | Tablets, small laptops |\n| desktop | > 1024px | Laptops, monitors |\n\n### Touch Targets\n- Minimum interactive element size: 44x44px\n- Minimum spacing between targets: 8px\n\n### Mobile Adaptations\n- Navigation collapses to hamburger menu below 640px\n- Cards stack single-column below 640px\n- Font sizes: H1 reduces to 32px on mobile, H2 to 28px\n- Side padding: 16px on mobile, 24px tablet, auto-center desktop\n\n### Behavior Patterns\n- Horizontal scrolling: never (use stacking or truncation)\n- Images: responsive with srcset, max-width: 100%\n- Tables: horizontal scroll wrapper below tablet breakpoint\n```\n\n### Section 9: Agent Prompt Guide\n\nHow AI agents should use this document when generating UI.\n\n```markdown\n## 9. Agent Prompt Guide\n\n### Quick Reference\n- Primary CTA color: Terracotta Brand (#c96442)\n- Background: Parchment (#f5f4ed)\n- Heading font: Serif, weight 500\n- Body font: Sans, weight 400\n- Standard spacing: 24px (space-6)\n- Card radius: 12px (radius-lg)\n\n### How to Use This Document\n1. Before writing any UI code, read the full DESIGN.md\n2. Reference specific section names when implementing: \"Following Section 4: Buttons\"\n3. Use design token names in CSS (var(--color-terracotta-brand)), not raw hex values\n4. Check Section 7 (Do's and Don'ts) before submitting\n5. If a component is not covered, create it following existing patterns and flag for DESIGN.md update\n\n### Example Component Prompt\n\"Create a hero section on Parchment (#f5f4ed) with a headline at H1 scale\n(48px Serif weight 500, line-height 1.10). Use Near Black (#141413) text.\nAdd a subtitle in Olive Gray (#5e5d59) at Body scale (16px Sans, line-height 1.60).\nPlace a Terracotta Brand (#c96442) primary button with Ivory text, radius-md (8px).\"\n\n### Iteration Guide\n- Change one component at a time\n- Reference specific color names and token values\n- Describe the component's state (default, hover, active, disabled)\n- Specify responsive behavior for the component\n```\n\n---\n\n## Design Token Conventions\n\nTokens are the bridge between DESIGN.md and code. Consistent naming ensures agents can translate design specs into CSS\u002FTailwind variables.\n\n### Naming Pattern\n\n```\n--{category}-{name}[-{modifier}]\n```\n\n| Category | Examples |\n|----------|---------|\n| `color-` | `--color-terracotta-brand`, `--color-near-black`, `--color-success-green` |\n| `space-` | `--space-1`, `--space-4`, `--space-8` |\n| `text-` | `--text-h1`, `--text-body`, `--text-caption` |\n| `radius-` | `--radius-sm`, `--radius-md`, `--radius-lg` |\n| `shadow-` | `--shadow-sm`, `--shadow-md`, `--shadow-lg` |\n| `font-` | `--font-serif`, `--font-sans`, `--font-mono` |\n\n### Mapping to CSS Custom Properties\n\nDESIGN.md tokens map directly to CSS custom properties:\n```css\n:root {\n  --color-terracotta-brand: #c96442;\n  --space-6: 24px;\n  --radius-lg: 12px;\n  --shadow-sm: 0 1px 2px rgba(0,0,0,0.04);\n}\n```\n\n### Mapping to Tailwind\n\nWhen using Tailwind, DESIGN.md tokens map to `tailwind.config.js` extensions. The builder agent should configure this once and reference throughout.\n\n---\n\n## Integration with Kits\n\nWhen DESIGN.md exists and kits contain UI requirements, acceptance criteria should reference design tokens by section and name. This creates a traceable chain:\n\n```\nDESIGN.md → Cavekit acceptance criterion → Plan task → Implementation\n```\n\n### How to Reference\n\n| In Cavekit Acceptance Criteria | Design Reference |\n|----------------------------------|-----------------|\n| \"CTA button uses primary brand styling\" | DESIGN.md Section 4: Buttons, primary variant |\n| \"Headings follow the type hierarchy\" | DESIGN.md Section 3: Type Scale |\n| \"Cards have subtle resting elevation\" | DESIGN.md Section 6: shadow-sm |\n| \"Layout uses the standard grid\" | DESIGN.md Section 5: Grid |\n| \"Colors adapt for dark mode\" | DESIGN.md Section 2: Dark Mode mapping |\n\n**Do NOT duplicate DESIGN.md content into kits.** Reference by section\u002Ftoken name only. If a color changes in DESIGN.md, kits should not need updating.\n\n### When No Design Reference Exists\n\nIf a cavekit needs a visual pattern not in DESIGN.md, the acceptance criterion should note this:\n```markdown\n- [ ] Component uses a card-like container [DESIGN.md: pattern not yet defined — flag for design update]\n```\n\nThis tells the inspect phase to check whether DESIGN.md needs a new pattern.\n\n---\n\n## Integration with Plans (Architect Phase)\n\nWhen the architect generates task descriptions for UI work, each task should include:\n\n```markdown\n**Design Reference:** DESIGN.md Section {N} — {section name}\n```\n\nThis tells the task-builder which DESIGN.md sections to read before implementing.\n\n---\n\n## Integration with Build Phase\n\nTask-builder agents follow this protocol for UI work:\n\n1. **Before implementing:** Read DESIGN.md (or the specific sections referenced in the task)\n2. **During implementation:** Use design tokens, not hardcoded values\n3. **In commit messages:** Note which DESIGN.md sections were followed\n4. **If a new pattern is needed:** Implement it following existing DESIGN.md conventions and flag for design update\n\n---\n\n## Revision Patterns\n\nWhen visual fixes are made manually (outside the Hunt loop), `\u002Fck:revise` traces them back to DESIGN.md:\n\n### Visual Fix Classification\n\n| Fix Type | DESIGN.md Action |\n|----------|-----------------|\n| Color change that should apply globally | Update DESIGN.md Section 2 with corrected value |\n| New component pattern not in DESIGN.md | Add to DESIGN.md Section 4 |\n| Spacing adjustment revealing wrong scale | Update DESIGN.md Section 5 scale |\n| Typography fix | Update DESIGN.md Section 3 type scale |\n| Responsive behavior change | Update DESIGN.md Section 8 |\n\n### Revision Protocol\n\n1. Identify the visual change in the diff\n2. Check if DESIGN.md covers this pattern\n3. If not covered: add the pattern to the appropriate section\n4. If covered but wrong: update the token\u002Fvalue\n5. Log the change to `context\u002Fdesigns\u002Fdesign-changelog.md`\n\n---\n\n## Collection Import\n\nThe [awesome-design-md](https:\u002F\u002Fgithub.com\u002FVoltAgent\u002Fawesome-design-md) repository contains 54+ curated design systems extracted from real products. These serve as starting points.\n\n### Import Workflow\n\n1. **Choose a template:** `vercel`, `claude`, `stripe`, `github`, `linear`, etc.\n2. **Fetch the raw DESIGN.md** from the collection\n3. **Present to the user** as a starting point — not a finished product\n4. **Walk through each section** for customization (brand colors, typography, specific component needs)\n5. **Write the customized version** to project root\n\n### After Import\n\nThe imported DESIGN.md becomes the project's own. Future updates are made directly — the import is a seed, not a dependency.\n\n---\n\n## Quality Standards\n\n### Completeness Checklist\n\n- [ ] All 9 sections present and non-empty\n- [ ] Every color has: semantic name + hex value + functional role\n- [ ] Complete typography table (all 5 values per level)\n- [ ] Component stylings include hover, focus, active, disabled states\n- [ ] Spacing scale is defined with consistent base unit\n- [ ] Shadow\u002Felevation scale is defined\n- [ ] Breakpoints have specific pixel values\n- [ ] Agent Prompt Guide has quick reference and example prompts\n\n### Specificity Requirements\n\nEvery value in DESIGN.md must be concrete and unambiguous:\n\n| Too Vague | Specific Enough |\n|-----------|----------------|\n| \"a warm blue\" | `#3b6fb5` (Info Blue) |\n| \"medium spacing\" | `24px` (space-6) |\n| \"slightly rounded\" | `8px` (radius-md) |\n| \"subtle shadow\" | `0 1px 2px rgba(0,0,0,0.04)` (shadow-sm) |\n| \"large heading\" | `48px \u002F 3rem, weight 500, line-height 1.10` |\n\n### Consistency Rules\n\n- Tokens used in Section 4 (Components) must exist in Sections 2, 3, 5, 6\n- Dark mode mappings must cover every color used in components\n- Responsive changes must reference defined breakpoints\n- All spacing values must be multiples of the base unit\n\n---\n\n## Anti-Patterns\n\n1. **Generic atmosphere** — \"Clean, modern, professional\" describes every SaaS app and none\n2. **Missing interaction states** — A button without hover\u002Ffocus is incomplete\n3. **Orphan colors** — Colors defined in the palette but never used in components\n4. **Arbitrary spacing** — Values that don't follow the spacing scale\n5. **Missing dark mode** — If the app supports dark mode, every light color needs a mapping\n6. **Hex-only references in components** — Use semantic names, not raw values\n7. **No Agent Prompt Guide** — Section 9 is what makes DESIGN.md actionable for AI agents\n8. **Duplicating DESIGN.md into kits** — Reference by section\u002Ftoken name only\n",{"name":5,"description":7},"main","2b63f856ce19c2a797929cacabd9e0fc936812fa","plugins\u002FJuliusBrussee\u002Fblueprint\u002Fskills\u002Fdesign-system",474,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-11 14:40:14",{"source":8,"skillName":5,"commands":77,"prompt":87,"zipAvailable":88},[78,81,84],{"tool":79,"command":80},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill design-system",{"tool":82,"command":83},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill design-system",{"tool":85,"command":86},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill design-system","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FJuliusBrussee\u002Fblueprint\u002Fskills\u002Fdesign-system\u002FSKILL.md",true,[],[91,99,106,113,139,164],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":98},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":98},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":98},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":61},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[120,121,122,123,124,125,126,127,128,34,129,130,131,132,133,134,135,136,137,138],"search","deja search","never","error","ready","memory","re","decide","fix","debugging","when","you","done","reviewer","io","change","cli","merge","past",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":61},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[146,147,148,134,149,150,151,152,153,154,155,156,157,158,125,159,160,161,162,163],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":177,"publishedAt":61},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[170,173,174],{"categoryNo":171,"categoryName":172,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":175,"categoryName":176,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[166,178,179,180,181,182,183,160,184,126,185,186,187,188,130,189,190,191,192,193],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]