constellai 0.3.0

package/skills/design/corporate/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: corporate
+description: Professional, brand-aligned design with structured grids, minimalist layouts, and consistent enterprise patterns.
+license: MIT
+metadata:
+  author: typeui.sh
+---
+
+<!-- TYPEUI_SH_MANAGED_START -->
+# Corporate Design System Skill (Universal)
+
+## Mission
+You are an expert design-system guideline author for Corporate.
+Create practical, implementation-ready guidance that can be directly used by engineers and designers.
+
+## Brand
+Corporate UI/UX design focuses on professionalism, consistency, and brand alignment, typically featuring minimalist layouts, structured grids, and, in 2026, AI-driven personalization
+
+## Style Foundations
+- Visual style: enterprise, premium
+- Typography scale: desktop-first expressive scale | Fonts: primary=Open Sans, display=Poppins, mono=IBM Plex Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
+- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#3B82F6, secondary=#8B5CF6, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#111827
+- Spacing scale: 8pt baseline grid
+
+
+## Accessibility
+WCAG 2.2 AA, keyboard-first interactions, visible focus states, semantic HTML before ARIA, screen-reader tested labels, reduced-motion support, 44px+ touch targets, high-contrast support
+
+## Writing Tone
+concise, confident, helpful, clear, professional, action-oriented, low-jargon
+
+## Rules: Do
+- prefer semantic tokens over raw values
+- preserve visual hierarchy
+- keep interaction states explicit
+- design for empty/loading/error states
+- ensure responsive behavior by default
+- document accessibility rationale
+
+## Rules: Don't
+- avoid low contrast text
+- avoid inconsistent spacing rhythm
+- avoid decorative motion without purpose
+- avoid ambiguous labels
+- avoid mixing multiple visual metaphors
+- avoid inaccessible hit areas
+
+## Expected Behavior
+- Follow the foundations first, then component consistency.
+- When uncertain, prioritize accessibility and clarity over novelty.
+- Provide concrete defaults and explain trade-offs when alternatives are possible.
+- Keep guidance opinionated, concise, and implementation-focused.
+
+## Guideline Authoring Workflow
+1. Restate the design intent in one sentence before proposing rules.
+2. Define tokens and foundational constraints before component-level guidance.
+3. Specify component anatomy, states, variants, and interaction behavior.
+4. Include accessibility acceptance criteria and content-writing expectations.
+5. Add anti-patterns and migration notes for existing inconsistent UI.
+6. End with a QA checklist that can be executed in code review.
+
+## Required Output Structure
+When generating design-system guidance, use this structure:
+- Context and goals
+- Design tokens and foundations
+- Component-level rules (anatomy, variants, states, responsive behavior)
+- Accessibility requirements and testable acceptance criteria
+- Content and tone standards with examples
+- Anti-patterns and prohibited implementations
+- QA checklist
+
+## Component Rule Expectations
+- Define required states: default, hover, focus-visible, active, disabled, loading, error (as relevant).
+- Describe interaction behavior for keyboard, pointer, and touch.
+- State spacing, typography, and color-token usage explicitly.
+- Include responsive behavior and edge cases (long labels, empty states, overflow).
+
+## Quality Gates
+- No rule should depend on ambiguous adjectives alone; anchor each rule to a token, threshold, or example.
+- Every accessibility statement must be testable in implementation.
+- Prefer system consistency over one-off local optimizations.
+- Flag conflicts between aesthetics and accessibility, then prioritize accessibility.
+
+## Example Constraint Language
+- Use "must" for non-negotiable rules and "should" for recommendations.
+- Pair every do-rule with at least one concrete don't-example.
+- If introducing a new pattern, include migration guidance for existing components.
+
+<!-- TYPEUI_SH_MANAGED_END -->

package/skills/design/cosmic/DESIGN.md

@@ -0,0 +1,55 @@
+---
+name: Cosmic
+colors:
+  primary: "#3B82F6"
+  secondary: "#8B5CF6"
+  success: "#16A34A"
+  warning: "#D97706"
+  danger: "#DC2626"
+  surface: "#FFFFFF"
+  text: "#111827"
+  neutral: "#FFFFFF"
+typography:
+  h1:
+    fontFamily: "Audiowide"
+    fontSize: 2rem
+  body-md:
+    fontFamily: "Audiowide"
+    fontSize: 1rem
+  label-caps:
+    fontFamily: "JetBrains Mono"
+    fontSize: 0.75rem
+  sourceScale: "12/14/16/20/24/32"
+  weights: "400"
+rounded:
+  sm: 4px
+  md: 8px
+spacing:
+  sm: 4px
+  md: 8px
+  sourceScale: "4/8/12/16/24/32"
+---
+
+## Overview
+
+Futuristic sci-fi aesthetic with dark themes, vibrant neon accents, and immersive spatial elements.
+
+## Style Foundations
+
+- **Visual style:** playful, premium
+- **Typography scale:** 12/14/16/20/24/32
+- **Typography fonts:** primary=Audiowide, display=Audiowide, mono=JetBrains Mono
+- **Typography weights:** 400
+- **Color palette:** primary, neutral, success, warning, danger
+- **Spacing scale:** 4/8/12/16/24/32
+
+## Colors
+
+- **Primary (#3B82F6):** Token from style foundations.
+- **Secondary (#8B5CF6):** Token from style foundations.
+- **Success (#16A34A):** Token from style foundations.
+- **Warning (#D97706):** Token from style foundations.
+- **Danger (#DC2626):** Token from style foundations.
+- **Surface (#FFFFFF):** Token from style foundations.
+- **Text (#111827):** Token from style foundations.
+- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.

package/skills/design/cosmic/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: cosmic
+description: Futuristic sci-fi aesthetic with dark themes, vibrant neon accents, and immersive spatial elements.
+license: MIT
+metadata:
+  author: typeui.sh
+---
+
+<!-- TYPEUI_SH_MANAGED_START -->
+# Cosmic Design System Skill (Universal)
+
+## Mission
+You are an expert design-system guideline author for Cosmic.
+Create practical, implementation-ready guidance that can be directly used by engineers and designers.
+
+## Brand
+Cosmic UI/UX design is a futuristic, sci-fi-inspired style characterized by dark themes, vibrant neon accents, and immersive, spatial elements
+
+## Style Foundations
+- Visual style: playful, premium
+- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Audiowide, display=Audiowide, mono=JetBrains Mono | weights=400
+- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#3B82F6, secondary=#8B5CF6, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#111827
+- Spacing scale: 4/8/12/16/24/32
+
+
+## Accessibility
+WCAG 2.2 AA, keyboard-first interactions, visible focus states
+
+## Writing Tone
+concise, confident, helpful
+
+## Rules: Do
+- prefer semantic tokens over raw values
+- preserve visual hierarchy
+- keep interaction states explicit
+
+## Rules: Don't
+- avoid low contrast text
+- avoid inconsistent spacing rhythm
+- avoid ambiguous labels
+
+## Expected Behavior
+- Follow the foundations first, then component consistency.
+- When uncertain, prioritize accessibility and clarity over novelty.
+- Provide concrete defaults and explain trade-offs when alternatives are possible.
+- Keep guidance opinionated, concise, and implementation-focused.
+
+## Guideline Authoring Workflow
+1. Restate the design intent in one sentence before proposing rules.
+2. Define tokens and foundational constraints before component-level guidance.
+3. Specify component anatomy, states, variants, and interaction behavior.
+4. Include accessibility acceptance criteria and content-writing expectations.
+5. Add anti-patterns and migration notes for existing inconsistent UI.
+6. End with a QA checklist that can be executed in code review.
+
+## Required Output Structure
+When generating design-system guidance, use this structure:
+- Context and goals
+- Design tokens and foundations
+- Component-level rules (anatomy, variants, states, responsive behavior)
+- Accessibility requirements and testable acceptance criteria
+- Content and tone standards with examples
+- Anti-patterns and prohibited implementations
+- QA checklist
+
+## Component Rule Expectations
+- Define required states: default, hover, focus-visible, active, disabled, loading, error (as relevant).
+- Describe interaction behavior for keyboard, pointer, and touch.
+- State spacing, typography, and color-token usage explicitly.
+- Include responsive behavior and edge cases (long labels, empty states, overflow).
+
+## Quality Gates
+- No rule should depend on ambiguous adjectives alone; anchor each rule to a token, threshold, or example.
+- Every accessibility statement must be testable in implementation.
+- Prefer system consistency over one-off local optimizations.
+- Flag conflicts between aesthetics and accessibility, then prioritize accessibility.
+
+## Example Constraint Language
+- Use "must" for non-negotiable rules and "should" for recommendations.
+- Pair every do-rule with at least one concrete don't-example.
+- If introducing a new pattern, include migration guidance for existing components.
+
+<!-- TYPEUI_SH_MANAGED_END -->

package/skills/design/creative/DESIGN.md

@@ -0,0 +1,55 @@
+---
+name: Creative
+colors:
+  primary: "#3B82F6"
+  secondary: "#8B5CF6"
+  success: "#16A34A"
+  warning: "#D97706"
+  danger: "#DC2626"
+  surface: "#FFFFFF"
+  text: "#111827"
+  neutral: "#FFFFFF"
+typography:
+  h1:
+    fontFamily: "Bangers"
+    fontSize: 2rem
+  body-md:
+    fontFamily: "Bangers"
+    fontSize: 1rem
+  label-caps:
+    fontFamily: "IBM Plex Mono"
+    fontSize: 0.75rem
+  sourceScale: "12/14/16/20/24/32"
+  weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
+rounded:
+  sm: 4px
+  md: 8px
+spacing:
+  sm: 4px
+  md: 8px
+  sourceScale: "4/8/12/16/24/32"
+---
+
+## Overview
+
+Playful, character-driven design with expressive typography and bold graphics for landing pages and creative projects.
+
+## Style Foundations
+
+- **Visual style:** playful
+- **Typography scale:** 12/14/16/20/24/32
+- **Typography fonts:** primary=Bangers, display=Bangers, mono=IBM Plex Mono
+- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
+- **Color palette:** primary, secondary, neutral, success, warning, danger
+- **Spacing scale:** 4/8/12/16/24/32
+
+## Colors
+
+- **Primary (#3B82F6):** Token from style foundations.
+- **Secondary (#8B5CF6):** Token from style foundations.
+- **Success (#16A34A):** Token from style foundations.
+- **Warning (#D97706):** Token from style foundations.
+- **Danger (#DC2626):** Token from style foundations.
+- **Surface (#FFFFFF):** Token from style foundations.
+- **Text (#111827):** Token from style foundations.
+- **Neutral (#FFFFFF):** Derived from the surface token for official format compatibility.

package/skills/design/creative/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: creative
+description: Playful, character-driven design with expressive typography and bold graphics for landing pages and creative projects.
+license: MIT
+metadata:
+  author: typeui.sh
+---
+
+<!-- TYPEUI_SH_MANAGED_START -->
+# Creative Design System Skill (Universal)
+
+## Mission
+You are an expert design-system guideline author for Creative.
+Create practical, implementation-ready guidance that can be directly used by engineers and designers.
+
+## Brand
+cerative style for landing  pages
+
+## Style Foundations
+- Visual style: playful
+- Typography scale: 12/14/16/20/24/32 | Fonts: primary=Bangers, display=Bangers, mono=IBM Plex Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
+- Color palette: primary, secondary, neutral, success, warning, danger | Tokens: primary=#3B82F6, secondary=#8B5CF6, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#111827
+- Spacing scale: 4/8/12/16/24/32
+
+
+## Accessibility
+WCAG 2.2 AA, keyboard-first interactions, visible focus states
+
+## Writing Tone
+concise, confident, helpful
+
+## Rules: Do
+- prefer semantic tokens over raw values
+- preserve visual hierarchy
+- keep interaction states explicit
+
+## Rules: Don't
+- avoid low contrast text
+- avoid inconsistent spacing rhythm
+- avoid ambiguous labels
+
+## Expected Behavior
+- Follow the foundations first, then component consistency.
+- When uncertain, prioritize accessibility and clarity over novelty.
+- Provide concrete defaults and explain trade-offs when alternatives are possible.
+- Keep guidance opinionated, concise, and implementation-focused.
+
+## Guideline Authoring Workflow
+1. Restate the design intent in one sentence before proposing rules.
+2. Define tokens and foundational constraints before component-level guidance.
+3. Specify component anatomy, states, variants, and interaction behavior.
+4. Include accessibility acceptance criteria and content-writing expectations.
+5. Add anti-patterns and migration notes for existing inconsistent UI.
+6. End with a QA checklist that can be executed in code review.
+
+## Required Output Structure
+When generating design-system guidance, use this structure:
+- Context and goals
+- Design tokens and foundations
+- Component-level rules (anatomy, variants, states, responsive behavior)
+- Accessibility requirements and testable acceptance criteria
+- Content and tone standards with examples
+- Anti-patterns and prohibited implementations
+- QA checklist
+
+## Component Rule Expectations
+- Define required states: default, hover, focus-visible, active, disabled, loading, error (as relevant).
+- Describe interaction behavior for keyboard, pointer, and touch.
+- State spacing, typography, and color-token usage explicitly.
+- Include responsive behavior and edge cases (long labels, empty states, overflow).
+
+## Quality Gates
+- No rule should depend on ambiguous adjectives alone; anchor each rule to a token, threshold, or example.
+- Every accessibility statement must be testable in implementation.
+- Prefer system consistency over one-off local optimizations.
+- Flag conflicts between aesthetics and accessibility, then prioritize accessibility.
+
+## Example Constraint Language
+- Use "must" for non-negotiable rules and "should" for recommendations.
+- Pair every do-rule with at least one concrete don't-example.
+- If introducing a new pattern, include migration guidance for existing components.
+
+<!-- TYPEUI_SH_MANAGED_END -->

package/skills/design/css-techniques/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: css-techniques
+description: Modern CSS layout and styling — grid, flexbox, container queries, custom properties; consult when building responsive, maintainable styles.
+domain: design
+category: design
+tags: [css, grid, flexbox, container-queries, custom-properties]
+official_sources:
+  - https://developer.mozilla.org/en-US/docs/Web/CSS
+  - https://web.dev/learn/css
+verified: 2026-06-16
+---
+
+# CSS Techniques
+
+## Overview
+Modern CSS provides dedicated layout systems (Grid for two dimensions, Flexbox for one), element-aware responsiveness (container queries), and reusable values (custom properties), replacing older float and hack-based approaches. MDN is the canonical reference; web.dev's Learn CSS is the official structured course. Read this when laying out pages and components or modernizing legacy stylesheets.
+
+## Official sources
+- MDN CSS reference: https://developer.mozilla.org/en-US/docs/Web/CSS
+- web.dev — Learn CSS: https://web.dev/learn/css
+
+## Core concepts
+- **Box model** — every element is a box of content, padding, border, and margin; `box-sizing` controls how width is computed (MDN/web.dev Box Model).
+- **Flexbox** — one-dimensional layout distributing space along a single axis (row or column) (MDN Flexbox; web.dev Flexbox).
+- **Grid** — two-dimensional layout using tracks, lines, and named areas for rows and columns simultaneously (MDN Grid; web.dev Grid).
+- **Container queries** — style elements based on the size (and style) of their container rather than the viewport (MDN Container Queries; web.dev module 38).
+- **Custom properties** — `--name` variables that cascade and can be read at runtime for theming (web.dev Custom Properties).
+- **Cascade, specificity, inheritance** — the rules that decide which declaration wins and which values pass to children (web.dev Cascade/Specificity/Inheritance).
+- **Logical properties** — writing-mode-aware properties (e.g. `margin-inline`) that adapt to text direction (web.dev Logical Properties).
+
+## Best practices
+- Choose Flexbox for one-axis distribution and Grid for two-axis layout instead of forcing one tool to do both (MDN layout modules).
+- Use container queries so components adapt to where they are placed, not just the viewport width (MDN Container Queries).
+- Drive theming and repeated values through custom properties to avoid magic numbers (web.dev Custom Properties).
+- Prefer logical properties (`inline`/`block`) for internationalized, direction-agnostic layouts (web.dev Logical Properties).
+
+## Common pitfalls
+- Using absolute positioning or floats for layout → use Grid/Flexbox, which handle alignment and spacing natively (MDN layout).
+- Fighting the cascade with `!important` → resolve via specificity and source order per the cascade rules (web.dev Cascade).
+- Assuming viewport media queries suffice for reusable components → add container queries so a component reflows in any context (MDN Container Queries).
+
+## Examples
+```css
+/* Responsive card grid: auto-fit tracks with a minimum width */
+.grid { display: grid; grid-template-columns: repeat(auto-fit, minmax(16rem, 1fr)); gap: 1rem; }
+
+/* Container query: stack below the container's own breakpoint */
+.card-wrap { container-type: inline-size; }
+@container (max-width: 24rem) { .card { flex-direction: column; } }
+```
+
+## Further reading
+- MDN CSS layout guides: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_grid_layout
+- web.dev Learn CSS full module list: https://web.dev/learn/css
+
+## Related skills
+- ../responsive-layout — fluid and intrinsic layout strategies built on these primitives
+- ../gradients — modern background/image techniques in CSS

package/skills/design/d3-visualization-playbook/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: d3-visualization-playbook
+description: |
+  Use this skill when Codex needs teaches the agent to produce D3 charts and interactive data visualizations. A comprehensive D3.js skill with examples across chart types and techniques giving the agent expert-level knowledge to compose complex, interactive visualizations. Helpful for editorial dashboards, reports, data-rich prototypes, and explanatory graphics. Recast from the original d3-visualization/SKILL.md material as the d3-visualization-playbook procedure.
+---
+
+# D3 Visualization Playbook
+
+## Role
+
+Use this skill when Codex needs teaches the agent to produce D3 charts and interactive data visualizations. A comprehensive D3.js skill with examples across chart types and techniques giving the agent expert-level knowledge to compose complex, interactive visualizations. Helpful for editorial dashboards, reports, data-rich prototypes, and explanatory graphics. Recast from the original d3-visualization/SKILL.md material as the d3-visualization-playbook procedure.
+
+## Source Trace
+
+- Original Markdown: `d3-visualization/SKILL.md`
+- Reformulated skill name: `d3-visualization-playbook`
+- Upstream reference: https://github.com/jiannanya/snow-d3/
+- Source category: `diagrams`
+
+## Operating Guidance
+
+Follow the rewritten material below as the working procedure. Keep code blocks, commands, file paths, URLs, dimensions, and API names exact when applying the skill.
+
+> Adapted from @jiannanya.
+
+## Purpose
+
+Teaches the agent to produce D3 charts and interactive data visualizations. A comprehensive D3.js skill with examples across chart types and techniques giving the agent expert-level knowledge to compose complex, interactive visualizations. Helpful for editorial dashboards, reports, data-rich prototypes, and explanatory graphics.
+
+## Origin
+
+- Upstream: https://github.com/jiannanya/snow-d3/
+- Category: `diagrams`
+
+## Procedure
+
+This catalogue entry advertises the skill in Open Design so the agent
+discovers it during planning. To execute the full upstream workflow with
+its original assets, scripts, and reference documents, install the upstream
+bundle into your active agent's skills directory:
+
+```bash
+# Inspect the upstream README for exact paths
+open https://github.com/jiannanya/snow-d3/
+
+# Clone or copy the snow-d3/ folder into your workspace's skills/ directory
+git clone https://github.com/jiannanya/snow-d3.git skills/snow-d3
+
+```
+
+Then request this skill by name (`d3-visualization`) or with
+one of the trigger phrases listed in this skill's frontmatter, e.g.:
+
+> "Produce a zoomable treemap for my sales data"
+> "Assemble a force-directed network graph like example 07 but for my own dataset"
+> "Compose a calendar heatmap in D3"

package/skills/design/dashboard/DESIGN.md

@@ -0,0 +1,55 @@
+---
+name: Dashboard
+colors:
+  primary: "#0C5CAB"
+  secondary: "#0a4a8a"
+  success: "#10b981"
+  warning: "#f59e0b"
+  danger: "#ef4444"
+  surface: "#09090b"
+  text: "#fafafa"
+  neutral: "#09090b"
+typography:
+  h1:
+    fontFamily: "IBM Plex Sans"
+    fontSize: 2rem
+  body-md:
+    fontFamily: "IBM Plex Sans"
+    fontSize: 1rem
+  label-caps:
+    fontFamily: "IBM Plex Sans"
+    fontSize: 0.75rem
+  sourceScale: "12/14/16/20/24/32"
+  weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
+rounded:
+  sm: 4px
+  md: 8px
+spacing:
+  sm: 8px
+  md: 16px
+  sourceScale: "8pt baseline grid"
+---
+
+## Overview
+
+Dark-themed cloud-platform aesthetic with modular grids, glass-like panels, and strong data hierarchy for productivity dashboards.
+
+## Style Foundations
+
+- **Visual style:** modern, clean, cloud-platform aesthetic (Heroku/Vercel/GitHub inspired), dark theme, subtle gradients, soft shadows, glass-like panels, rounded components
+- **Typography scale:** 12/14/16/20/24/32
+- **Typography fonts:** primary=IBM Plex Sans, display=IBM Plex Sans, mono=IBM Plex Sans
+- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
+- **Color palette:** primary, neutral, success, warning, danger
+- **Spacing scale:** 8pt baseline grid
+
+## Colors
+
+- **Primary (#0C5CAB):** Token from style foundations.
+- **Secondary (#0a4a8a):** Token from style foundations.
+- **Success (#10b981):** Token from style foundations.
+- **Warning (#f59e0b):** Token from style foundations.
+- **Danger (#ef4444):** Token from style foundations.
+- **Surface (#09090b):** Token from style foundations.
+- **Text (#fafafa):** Token from style foundations.
+- **Neutral (#09090b):** Derived from the surface token for official format compatibility.

package/skills/design/dashboard/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: dashboard
+description: Dark-themed cloud-platform aesthetic with modular grids, glass-like panels, and strong data hierarchy for productivity dashboards.
+license: MIT
+metadata:
+  author: typeui.sh
+---
+
+<!-- TYPEUI_SH_MANAGED_START -->
+# Dashboard Design System Skill (Universal)
+
+## Mission
+You are an expert design-system guideline author for Dashboard.
+Create practical, implementation-ready guidance that can be directly used by engineers and designers.
+
+## Brand
+Dashboard design emphasizes grids, modular components, and strong visual hierarchy to present complex data in a clear and accessible way. The interface is built for productivity, enabling users to monitor, analyze, and interact with information efficiently.
+
+## Style Foundations
+- Visual style: modern, clean, cloud-platform aesthetic (Heroku/Vercel/GitHub inspired), dark theme, subtle gradients, soft shadows, glass-like panels, rounded components
+- Typography scale: 12/14/16/20/24/32 | Fonts: primary=IBM Plex Sans, display=IBM Plex Sans, mono=IBM Plex Sans | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
+- Color palette: primary, neutral, success, warning, danger | Tokens: primary=#0C5CAB, secondary=#0a4a8a, success=#10b981, warning=#f59e0b, danger=#ef4444, surface=#09090b, text=#fafafa
+- Spacing scale: 8pt baseline grid
+
+
+## Accessibility
+WCAG 2.2 AA, keyboard-first interactions, visible focus states, semantic HTML before ARIA, screen-reader tested labels, reduced-motion support, 44px+ touch targets, high-contrast support
+
+## Writing Tone
+concise, confident, helpful, clear, friendly, professional, action-oriented, low-jargon
+
+## Rules: Do
+- prefer semantic tokens over raw values
+- preserve visual hierarchy
+- keep interaction states explicit
+- design for empty/loading/error states
+- ensure responsive behavior by default
+- document accessibility rationale
+
+## Rules: Don't
+- avoid low contrast text
+- avoid inconsistent spacing rhythm
+- avoid decorative motion without purpose
+- avoid ambiguous labels
+- avoid mixing multiple visual metaphors
+- avoid inaccessible hit areas
+
+## Expected Behavior
+- Follow the foundations first, then component consistency.
+- When uncertain, prioritize accessibility and clarity over novelty.
+- Provide concrete defaults and explain trade-offs when alternatives are possible.
+- Keep guidance opinionated, concise, and implementation-focused.
+
+## Guideline Authoring Workflow
+1. Restate the design intent in one sentence before proposing rules.
+2. Define tokens and foundational constraints before component-level guidance.
+3. Specify component anatomy, states, variants, and interaction behavior.
+4. Include accessibility acceptance criteria and content-writing expectations.
+5. Add anti-patterns and migration notes for existing inconsistent UI.
+6. End with a QA checklist that can be executed in code review.
+
+## Required Output Structure
+When generating design-system guidance, use this structure:
+- Context and goals
+- Design tokens and foundations
+- Component-level rules (anatomy, variants, states, responsive behavior)
+- Accessibility requirements and testable acceptance criteria
+- Content and tone standards with examples
+- Anti-patterns and prohibited implementations
+- QA checklist
+
+## Component Rule Expectations
+- Define required states: default, hover, focus-visible, active, disabled, loading, error (as relevant).
+- Describe interaction behavior for keyboard, pointer, and touch.
+- State spacing, typography, and color-token usage explicitly.
+- Include responsive behavior and edge cases (long labels, empty states, overflow).
+
+## Quality Gates
+- No rule should depend on ambiguous adjectives alone; anchor each rule to a token, threshold, or example.
+- Every accessibility statement must be testable in implementation.
+- Prefer system consistency over one-off local optimizations.
+- Flag conflicts between aesthetics and accessibility, then prioritize accessibility.
+
+## Example Constraint Language
+- Use "must" for non-negotiable rules and "should" for recommendations.
+- Pair every do-rule with at least one concrete don't-example.
+- If introducing a new pattern, include migration guidance for existing components.
+
+<!-- TYPEUI_SH_MANAGED_END -->

package/skills/design/deliverables-assembler-playbook/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: deliverables-assembler-playbook
+description: |
+  Use this skill when Codex needs suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn/ui). Recast from the original artifacts-builder/SKILL.md material as the deliverables-assembler-playbook procedure.
+---
+
+# Deliverables Assembler Playbook
+
+## Role
+
+Use this skill when Codex needs suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn/ui). Recast from the original artifacts-builder/SKILL.md material as the deliverables-assembler-playbook procedure.
+
+## Source Trace
+
+- Original Markdown: `artifacts-builder/SKILL.md`
+- Reformulated skill name: `deliverables-assembler-playbook`
+- Upstream reference: https://github.com/ComposioHQ/awesome-claude-skills/tree/master/artifacts-builder
+- Source category: `web-artifacts`
+
+## Operating Guidance
+
+Follow the rewritten material below as the working procedure. Keep code blocks, commands, file paths, URLs, dimensions, and API names exact when applying the skill.
+
+> Adapted from ComposioHQ awesome-claude-skills.
+
+## Purpose
+
+Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn/ui).
+
+## Origin
+
+- Upstream: https://github.com/ComposioHQ/awesome-claude-skills/tree/master/artifacts-builder
+- Category: `web-artifacts`
+
+## Procedure
+
+This catalogue entry advertises the skill in Open Design so the agent
+discovers it during planning. To execute the full upstream workflow with
+its original assets, scripts, and references, install the upstream
+bundle into your active agent's skills directory:
+
+```bash
+# Inspect the upstream README for exact paths
+open https://github.com/ComposioHQ/awesome-claude-skills/tree/master/artifacts-builder
+```
+
+Then request this skill by name (`artifacts-builder`) or with
+one of the trigger phrases listed in this skill's frontmatter.