/create-component
Guided component creation with proper patterns
$ npx -y skills add wshobson/agents --agent claude-codeHow it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/create-component
Context preview
What this command does when you run it.
Guided component creation with proper patterns
Command definition
create-component.mddescription: "Guided component creation with proper patterns"
argument-hint: "[component-name]"
Create Component
Guided workflow for creating new UI components following established patterns and best practices.
Pre-flight Checks
1. Check if `.ui-design/` directory exists:
- If not: Create `.ui-design/` directory
- Create `.ui-design/components/` subdirectory for component tracking
2. Detect project configuration:
- Scan for framework (React, Vue, Svelte, Angular)
- Scan for styling approach (CSS Modules, Tailwind, styled-components, etc.)
- Check for existing component patterns in `src/components/` or similar
- Load `.ui-design/design-system.json` if exists
3. Load project context:
- Check for `conductor/tech-stack.md`
- Check for existing component conventions
4. If no framework detected:
I couldn't detect a UI framework. What are you using?
1. React
2. Vue 3
3. Svelte
4. Angular
5. Vanilla JavaScript/HTML
6. Other (specify)
Enter number:
Component Specification
**CRITICAL RULES:**
- Ask ONE question per turn
- Wait for user response before proceeding
- Build complete specification before generating code
Q1: Component Name (if not provided)
What should this component be called?
Guidelines:
- Use PascalCase (e.g., UserCard, DataTable)
- Be descriptive but concise
- Avoid generic names like "Component" or "Widget"
Enter component name:
Q2: Component Purpose
What is this component's primary purpose?
1. Display content (cards, lists, text blocks)
2. Collect input (forms, selects, toggles)
3. Navigation (menus, tabs, breadcrumbs)
4. Feedback (alerts, toasts, modals)
5. Layout (containers, grids, sections)
6. Data visualization (charts, graphs, indicators)
7. Other (describe)
Enter number or description:
Q3: Component Complexity
What is the component's complexity level?
1. Simple - Single responsibility, minimal props, no internal state
2. Compound - Multiple parts, some internal state, few props
3. Complex - Multiple subcomponents, state management, many props
4. Composite - Orchestrates other components, significant logic
Enter number:
Q4: Props/Inputs Specification
What props/inputs should this component accept?
For each prop, provide:
- Name (camelCase)
- Type (string, number, boolean, function, object, array)
- Required or optional
- Default value (if optional)
Example format:
title: string, required
variant: "primary" | "secondary", optional, default: "primary"
onClick: function, optional
Enter props (one per line, empty line when done):
Q5: State Requirements
Does this component need internal state?
1. Stateless - Pure presentational, all data via props
2. Local state - Simple internal state (open/closed, hover, etc.)
3. Controlled - State managed by parent, component reports changes
4. Uncontrolled - Manages own state, exposes refs for parent access
5. Hybrid - Supports both controlled and uncontrolled modes
Enter number:
Q6: Composition Pattern (if complexity > Simple)
How should child content be handled?
1. No children - Self-contained component
2. Simple children - Accepts children prop for content
3. Named slots - Multiple content areas (header, body, footer)
4. Compound components - Exports subcomponents (e.g., Card.Header, Card.Body)
5. Render props - Accepts render function for flexibility
Enter number:
Q7: Accessibility Requirements
What accessibility features are needed?
1. Basic - Semantic HTML, aria-labels where needed
2. Keyboard navigation - Full keyboard support, focus management
3. Screen reader optimized - Live regions, announcements
4. Full WCAG AA - All applicable success criteria
Enter number:
Q8: Styling Approach
How should this component be styled?
Detected: {detected_approach}
1. Use detected approach ({detected_approach})
2. CSS Modules
3. Tailwind CSS
4. Styled Components / Emotion
5. Plain CSS/SCSS
6. Other (specify)
Enter number:State Management
Create `.ui-design/components/{component_name}.json`:
{
"name": "{ComponentName}",
"created_at": "ISO_TIMESTAMP",
"purpose": "{purpose}",
"complexity": "{level}",
"props": [
{
"name": "{prop_name}",
"type": "{type}",
"required": true,
"default": null,
"description": "{description}"
}
],
"state_pattern": "{pattern}",
"composition": "{pattern}",
"accessibility_level": "{level}",
"styling": "{approach}",
"files_created": [],
"status": "in_progress"
}Component Generation
1. Create Directory Structure
Based on detected patterns or ask user:
Where should this component be created?
Detected component directories:
1. src/components/{ComponentName}/
2. app/components/{ComponentName}/
3. components/{ComponentName}/
4. Other (specify path)
Enter number or path:Create structure:
{component_path}/
├── index.ts # Barrel export
├── {ComponentName}.tsx # Main component
├── {ComponentName}.test.tsx # Tests (if testing detected)
├── {ComponentName}.styles.{ext} # Styles (based on approach)
└── types.ts # TypeScript types (if TS project)2. Generate Component Code
Generate component based on gathered specifications.
**For React/TypeScript example:**
// {ComponentName}.tsx
import { forwardRef } from 'react';
import type { {ComponentName}Props } from './types';
import styles from './{ComponentName}.styles.module.css';
/**
* {ComponentName}
*
* {Purpose description}
*/
export const {ComponentName} = forwardRef<HTML{Element}Element, {ComponentName}Props>(
({ prop1, prop2 = 'default', children, ...props }, ref) => {
return (
<div
ref={ref}
className={styles.root}
{...props}
>
{children}
</div>
);
}
);
{ComponentName}.displayName = '{ComponentName}';3. Generate Types
// types.t
Read more
description: "Guided component creation with proper patterns" argument-hint: "[component-name]"
Create Component
Guided workflow for creating new UI components following established patterns and best practices.
Pre-flight Checks
1. Check if `.ui-design/` directory exists:
- If not: Create `.ui-design/` directory
- Create `.ui-design/components/` subdirectory for component tracking
2. Detect project configuration:
- Scan for framework (React, Vue, Svelte, Angular)
- Scan for styling approach (CSS Modules, Tailwind, styled-components, etc.)
- Check for existing component patterns in `src/components/` or similar
- Load `.ui-design/design-system.json` if exists
3. Load project context:
- Check for `conductor/tech-stack.md`
- Check for existing component conventions
4. If no framework detected:
I couldn't detect a UI framework. What are you using? 1. React 2. Vue 3 3. Svelte 4. Angular 5. Vanilla JavaScript/HTML 6. Other (specify) Enter number:
Component Specification
**CRITICAL RULES:**
- Ask ONE question per turn
- Wait for user response before proceeding
- Build complete specification before generating code
Q1: Component Name (if not provided)
What should this component be called? Guidelines: - Use PascalCase (e.g., UserCard, DataTable) - Be descriptive but concise - Avoid generic names like "Component" or "Widget" Enter component name:
Q2: Component Purpose
What is this component's primary purpose? 1. Display content (cards, lists, text blocks) 2. Collect input (forms, selects, toggles) 3. Navigation (menus, tabs, breadcrumbs) 4. Feedback (alerts, toasts, modals) 5. Layout (containers, grids, sections) 6. Data visualization (charts, graphs, indicators) 7. Other (describe) Enter number or description:
Q3: Component Complexity
What is the component's complexity level? 1. Simple - Single responsibility, minimal props, no internal state 2. Compound - Multiple parts, some internal state, few props 3. Complex - Multiple subcomponents, state management, many props 4. Composite - Orchestrates other components, significant logic Enter number:
Q4: Props/Inputs Specification
What props/inputs should this component accept? For each prop, provide: - Name (camelCase) - Type (string, number, boolean, function, object, array) - Required or optional - Default value (if optional) Example format: title: string, required variant: "primary" | "secondary", optional, default: "primary" onClick: function, optional Enter props (one per line, empty line when done):
Q5: State Requirements
Does this component need internal state? 1. Stateless - Pure presentational, all data via props 2. Local state - Simple internal state (open/closed, hover, etc.) 3. Controlled - State managed by parent, component reports changes 4. Uncontrolled - Manages own state, exposes refs for parent access 5. Hybrid - Supports both controlled and uncontrolled modes Enter number:
Q6: Composition Pattern (if complexity > Simple)
How should child content be handled? 1. No children - Self-contained component 2. Simple children - Accepts children prop for content 3. Named slots - Multiple content areas (header, body, footer) 4. Compound components - Exports subcomponents (e.g., Card.Header, Card.Body) 5. Render props - Accepts render function for flexibility Enter number:
Q7: Accessibility Requirements
What accessibility features are needed? 1. Basic - Semantic HTML, aria-labels where needed 2. Keyboard navigation - Full keyboard support, focus management 3. Screen reader optimized - Live regions, announcements 4. Full WCAG AA - All applicable success criteria Enter number:
Q8: Styling Approach
How should this component be styled?
Detected: {detected_approach}
1. Use detected approach ({detected_approach})
2. CSS Modules
3. Tailwind CSS
4. Styled Components / Emotion
5. Plain CSS/SCSS
6. Other (specify)
Enter number:State Management
Create `.ui-design/components/{component_name}.json`:
{
"name": "{ComponentName}",
"created_at": "ISO_TIMESTAMP",
"purpose": "{purpose}",
"complexity": "{level}",
"props": [
{
"name": "{prop_name}",
"type": "{type}",
"required": true,
"default": null,
"description": "{description}"
}
],
"state_pattern": "{pattern}",
"composition": "{pattern}",
"accessibility_level": "{level}",
"styling": "{approach}",
"files_created": [],
"status": "in_progress"
}Component Generation
1. Create Directory Structure
Based on detected patterns or ask user:
Where should this component be created?
Detected component directories:
1. src/components/{ComponentName}/
2. app/components/{ComponentName}/
3. components/{ComponentName}/
4. Other (specify path)
Enter number or path:Create structure:
{component_path}/
├── index.ts # Barrel export
├── {ComponentName}.tsx # Main component
├── {ComponentName}.test.tsx # Tests (if testing detected)
├── {ComponentName}.styles.{ext} # Styles (based on approach)
└── types.ts # TypeScript types (if TS project)2. Generate Component Code
Generate component based on gathered specifications.
**For React/TypeScript example:**
// {ComponentName}.tsx
import { forwardRef } from 'react';
import type { {ComponentName}Props } from './types';
import styles from './{ComponentName}.styles.module.css';
/**
* {ComponentName}
*
* {Purpose description}
*/
export const {ComponentName} = forwardRef<HTML{Element}Element, {ComponentName}Props>(
({ prop1, prop2 = 'default', children, ...props }, ref) => {
return (
<div
ref={ref}
className={styles.root}
{...props}
>
{children}
</div>
);
}
);
{ComponentName}.displayName = '{ComponentName}';3. Generate Types
// types.t
Production-ready agentic workflow building blocks: 94 plugins, 203 agents, 175 skills, 109 commands — built for Claude Code and consumed natively by OpenAI Codex CLI, Cursor, OpenCode, Gemini CLI, and GitHub Copilot from a single Markdown source.
Repo: wshobson/agents
Other commands on wshobson-agents.
- /accessibility-audit
You are an accessibility expert specializing in WCAG compliance, inclusive design, and assistive technology compatibility. Conduct comprehensive audits, identify barriers, provide remediation guidance, and ensure digital products are accessible to all users.
Open command - /improve-agent
Systematic improvement of existing agents through performance analysis, prompt engineering, and continuous iteration.
Open command - /multi-agent-optimize
The Multi-Agent Optimization Tool is an advanced AI-driven framework designed to holistically improve system performance through intelligent, coordinated agent-based optimization. Leveraging cutting-edge AI orchestration techniques, this tool provides a comprehensive approach to
Open command - /team-debug
Debug issues using competing hypotheses with parallel investigation by multiple agents
Open command - /team-delegate
Task delegation dashboard for managing team workload, assignments, and rebalancing
Open command - /team-feature
Develop features in parallel with multiple agents using file ownership boundaries and dependency management
Open command

