@czi-sds/mcp 0.4.0 → 0.5.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -0,0 +1,101 @@
|
|
|
1
|
+
# Figma to Code Translation Rules
|
|
2
|
+
|
|
3
|
+
These rules guide Claude Code when translating Figma designs to code using the CZI Science Design System (SDS).
|
|
4
|
+
|
|
5
|
+
## Design Token Priority
|
|
6
|
+
|
|
7
|
+
### Spacing Values
|
|
8
|
+
|
|
9
|
+
- **ALWAYS use SDS spacing tokens** instead of hardcoded pixel values
|
|
10
|
+
- Map Figma spacing to SDS Tailwind classes: `p-sds-{size}`, `m-sds-{size}`, `gap-sds-{size}`
|
|
11
|
+
- SDS spacing scale: `xs`, `s`, `m`, `l`, `xl`
|
|
12
|
+
- Examples: `mb-sds-xs`, `px-sds-l`, `gap-sds-xl`
|
|
13
|
+
|
|
14
|
+
### Color Values
|
|
15
|
+
|
|
16
|
+
- **Prefer SDS color tokens** over hardcoded hex values from Figma
|
|
17
|
+
- Use SDS semantic color classes: `text-light-sds-color-semantic-base-text-primary`
|
|
18
|
+
- Include dark mode variants: `dark:text-dark-sds-color-semantic-base-text-primary`
|
|
19
|
+
- Only use Figma hex values when no appropriate SDS token exists
|
|
20
|
+
|
|
21
|
+
### Typography
|
|
22
|
+
|
|
23
|
+
- **Map Figma text styles to SDS typography classes**
|
|
24
|
+
- Format: `prose-sds-{type}-{size}-{weight}-{variant}`
|
|
25
|
+
- Examples: `prose-sds-header-xl-600-wide`, `prose-sds-body-s-400-wide`
|
|
26
|
+
- Use SDS font families: `font-sds-body`, `font-sds-header`, `font-sds-code`
|
|
27
|
+
- Use SDS font weights: `font-sds-regular`, `font-sds-semibold`
|
|
28
|
+
|
|
29
|
+
## Component Mapping Rules
|
|
30
|
+
|
|
31
|
+
### SDS Component Priority
|
|
32
|
+
|
|
33
|
+
- **Always prefer SDS components** over custom implementations
|
|
34
|
+
- Import from `@czi-sds/components`: `import { Button, Icon, Link } from "@czi-sds/components"`
|
|
35
|
+
- Use SDS-specific props: `sdsStyle`, `sdsType`, `sdsSize`, `sdsIcon`
|
|
36
|
+
|
|
37
|
+
### Common Figma → SDS Mappings
|
|
38
|
+
|
|
39
|
+
- **Figma Buttons** → `<Button sdsStyle="square|rounded|minimal" sdsType="primary|secondary">`
|
|
40
|
+
- **Figma Icons** → `<Icon sdsIcon="IconName" sdsSize="xs|s|m|l|xl">`
|
|
41
|
+
- **Figma Input Fields** → `<InputText>`, `<InputSlider>`, `<Autocomplete>`
|
|
42
|
+
- **Figma Cards/Containers** → Use SDS spacing classes with `<div>` elements
|
|
43
|
+
|
|
44
|
+
### Layout Translation
|
|
45
|
+
|
|
46
|
+
- **Figma Auto Layout** → Tailwind Flexbox: `flex`, `flex-col`, `items-center`, `justify-between`
|
|
47
|
+
- **Figma Grid** → Tailwind Grid: `grid`, `grid-cols-{n}`, `gap-sds-{size}`
|
|
48
|
+
- **Figma Constraints** → Tailwind responsive utilities: `w-full`, `max-w-{size}`, `mx-auto`
|
|
49
|
+
|
|
50
|
+
## Implementation Guidelines
|
|
51
|
+
|
|
52
|
+
### Code Structure
|
|
53
|
+
|
|
54
|
+
- Follow fractal file structure with colocated components
|
|
55
|
+
- Use TypeScript interfaces for props
|
|
56
|
+
- Implement responsive design with SDS breakpoints: `sm`, `md`, `lg`
|
|
57
|
+
|
|
58
|
+
### Accessibility
|
|
59
|
+
|
|
60
|
+
- Include ARIA labels and semantic HTML
|
|
61
|
+
- Use SDS color tokens that meet contrast requirements
|
|
62
|
+
- Follow SDS accessibility patterns for interactive elements
|
|
63
|
+
|
|
64
|
+
### Best Practices
|
|
65
|
+
|
|
66
|
+
- Extract repeated spacing patterns into reusable components
|
|
67
|
+
- Use SDS design tokens consistently across related components
|
|
68
|
+
- Document any deviations from SDS patterns with comments explaining why
|
|
69
|
+
- Test components in both light and dark modes
|
|
70
|
+
|
|
71
|
+
## Examples
|
|
72
|
+
|
|
73
|
+
### Good - Using SDS Values
|
|
74
|
+
|
|
75
|
+
```tsx
|
|
76
|
+
import { Button, Icon } from "@czi-sds/components";
|
|
77
|
+
|
|
78
|
+
<div className="flex items-center gap-sds-m p-sds-l">
|
|
79
|
+
<Button sdsStyle="square" sdsType="primary" className="font-sds-semibold">
|
|
80
|
+
Save Changes
|
|
81
|
+
</Button>
|
|
82
|
+
<Icon sdsIcon="Save" sdsSize="s" />
|
|
83
|
+
</div>;
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
### Avoid - Hardcoded Values
|
|
87
|
+
|
|
88
|
+
```tsx
|
|
89
|
+
// Don't do this
|
|
90
|
+
<div className="flex items-center gap-4 p-6">
|
|
91
|
+
<button className="bg-blue-500 px-4 py-2 font-bold">Save Changes</button>
|
|
92
|
+
<svg className="w-4 h-4">...</svg>
|
|
93
|
+
</div>
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
## Design System Integration
|
|
97
|
+
|
|
98
|
+
- Always check Zeroheight documentation for component usage guidelines
|
|
99
|
+
- Verify SDS component APIs before implementing
|
|
100
|
+
- Use SDS Storybook for component examples and prop references
|
|
101
|
+
- When in doubt, prefer SDS patterns over custom solutions
|
|
@@ -0,0 +1,189 @@
|
|
|
1
|
+
# SDS Component Usage Rules
|
|
2
|
+
|
|
3
|
+
These rules guide Claude Code when working with the CZI Science Design System (SDS) components.
|
|
4
|
+
|
|
5
|
+
## Component Library Enforcement
|
|
6
|
+
|
|
7
|
+
### Import Patterns
|
|
8
|
+
|
|
9
|
+
- **Always prefer SDS components** over custom implementations or third-party alternatives
|
|
10
|
+
- Use named imports: `import { Button, Icon, Link } from "@czi-sds/components"`
|
|
11
|
+
- Avoid importing individual component files directly
|
|
12
|
+
|
|
13
|
+
### SDS-Specific Props
|
|
14
|
+
|
|
15
|
+
- **Use SDS-specific prop patterns** for consistent styling:
|
|
16
|
+
- `sdsStyle`: Controls visual style variants (`"square"`, `"rounded"`, `"minimal"`)
|
|
17
|
+
- `sdsType`: Controls semantic variants (`"primary"`, `"secondary"`, `"tertiary"`)
|
|
18
|
+
- `sdsSize`: Controls component sizing (`"xs"`, `"s"`, `"m"`, `"l"`, `"xl"`)
|
|
19
|
+
- `sdsIcon`: Specifies icon names for Icon components
|
|
20
|
+
|
|
21
|
+
### Component Composition Patterns
|
|
22
|
+
|
|
23
|
+
- **Follow SDS recommended composition patterns**:
|
|
24
|
+
- Use `Button` with `Icon` for button-icon combinations
|
|
25
|
+
- Use `InputText` with proper validation states
|
|
26
|
+
- Use `Tooltip` with appropriate trigger components
|
|
27
|
+
|
|
28
|
+
## Design Token Usage
|
|
29
|
+
|
|
30
|
+
### Spacing and Layout
|
|
31
|
+
|
|
32
|
+
- **Use SDS spacing tokens** via Tailwind classes:
|
|
33
|
+
- Padding: `p-sds-xs`, `px-sds-m`, `py-sds-l`
|
|
34
|
+
- Margin: `m-sds-xs`, `mx-sds-m`, `my-sds-l`
|
|
35
|
+
- Gap: `gap-sds-xs`, `gap-x-sds-m`, `gap-y-sds-l`
|
|
36
|
+
- Available spacing values: `xxs`, `xs`, `s`, `m`, `l`, `xl`, `xxl`
|
|
37
|
+
|
|
38
|
+
### Typography
|
|
39
|
+
|
|
40
|
+
- **Use SDS typography classes** for consistent text styling:
|
|
41
|
+
- Format: `prose-sds-{type}-{size}-{weight}-{variant}`
|
|
42
|
+
- Examples: `prose-sds-header-xl-600-wide`, `prose-sds-body-s-400-wide`
|
|
43
|
+
- **Use SDS font families**: `font-sds-body`, `font-sds-header`, `font-sds-code`
|
|
44
|
+
- **Use SDS font weights**: `font-sds-regular`, `font-sds-semibold`
|
|
45
|
+
|
|
46
|
+
### Colors
|
|
47
|
+
|
|
48
|
+
- **Use SDS semantic color tokens** for theme consistency:
|
|
49
|
+
- Text: `text-light-sds-color-semantic-base-text-primary`
|
|
50
|
+
- Backgrounds: `bg-light-sds-color-semantic-base-background-primary`
|
|
51
|
+
- **Always include dark mode variants**: `dark:text-dark-sds-color-semantic-base-text-primary`
|
|
52
|
+
|
|
53
|
+
## Component-Specific Guidelines
|
|
54
|
+
|
|
55
|
+
### Buttons
|
|
56
|
+
|
|
57
|
+
```tsx
|
|
58
|
+
// Preferred patterns
|
|
59
|
+
<Button sdsStyle="square" sdsType="primary" onClick={handleClick}>
|
|
60
|
+
Primary Action
|
|
61
|
+
</Button>
|
|
62
|
+
|
|
63
|
+
<Button sdsStyle="minimal" sdsType="secondary" startIcon={<Icon sdsIcon="Add" sdsSize="xs" />}>
|
|
64
|
+
Secondary Action
|
|
65
|
+
</Button>
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
### Icons
|
|
69
|
+
|
|
70
|
+
```tsx
|
|
71
|
+
// Use SDS icon names
|
|
72
|
+
<Icon sdsIcon="CheckCircle" sdsSize="s" />
|
|
73
|
+
<Icon sdsIcon="ExternalLink" sdsSize="xs" />
|
|
74
|
+
|
|
75
|
+
// With interactive elements
|
|
76
|
+
<Button startIcon={<Icon sdsIcon="Download" sdsSize="xs" />}>
|
|
77
|
+
Download
|
|
78
|
+
</Button>
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
### Form Components
|
|
82
|
+
|
|
83
|
+
```tsx
|
|
84
|
+
// Use SDS form components
|
|
85
|
+
<InputText
|
|
86
|
+
label="Email Address"
|
|
87
|
+
placeholder="Enter your email"
|
|
88
|
+
intent="default"
|
|
89
|
+
/>
|
|
90
|
+
|
|
91
|
+
<Autocomplete
|
|
92
|
+
label="Select Option"
|
|
93
|
+
options={options}
|
|
94
|
+
multiple={false}
|
|
95
|
+
/>
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
## Accessibility Requirements
|
|
99
|
+
|
|
100
|
+
### ARIA and Semantic HTML
|
|
101
|
+
|
|
102
|
+
- **Use SDS components' built-in accessibility features**
|
|
103
|
+
- Add custom ARIA attributes only when SDS components don't provide them
|
|
104
|
+
- Use semantic HTML elements with SDS styling rather than generic divs when possible
|
|
105
|
+
|
|
106
|
+
### Color Contrast
|
|
107
|
+
|
|
108
|
+
- **SDS color tokens meet WCAG requirements** - use them instead of custom colors
|
|
109
|
+
- Test components in both light and dark modes
|
|
110
|
+
- Ensure sufficient contrast for interactive states
|
|
111
|
+
|
|
112
|
+
## Code Quality Patterns
|
|
113
|
+
|
|
114
|
+
### TypeScript Integration
|
|
115
|
+
|
|
116
|
+
- **Use SDS component TypeScript interfaces** for prop typing
|
|
117
|
+
- Import types when needed: `import { ButtonProps, IconName } from "@czi-sds/components"`
|
|
118
|
+
- Extend SDS interfaces for custom component props
|
|
119
|
+
|
|
120
|
+
### Responsive Design
|
|
121
|
+
|
|
122
|
+
- **Use SDS breakpoint system** with Tailwind responsive prefixes:
|
|
123
|
+
- `xs:`, `sm:`, `md:`, `lg:`, `xl:`
|
|
124
|
+
- Follow mobile-first responsive design patterns
|
|
125
|
+
- Use SDS spacing tokens at all breakpoints
|
|
126
|
+
|
|
127
|
+
### Testing Considerations
|
|
128
|
+
|
|
129
|
+
- **SDS components are pre-tested** - focus tests on your business logic
|
|
130
|
+
- Test accessibility using SDS components' built-in features
|
|
131
|
+
- Use SDS Storybook for component API reference during development
|
|
132
|
+
|
|
133
|
+
## Anti-Patterns to Avoid
|
|
134
|
+
|
|
135
|
+
### Don't Override SDS Styles
|
|
136
|
+
|
|
137
|
+
```tsx
|
|
138
|
+
// ❌ Avoid overriding SDS component styles
|
|
139
|
+
<Button className="!bg-red-500 !p-4">Bad</Button>
|
|
140
|
+
|
|
141
|
+
// ✅ Use SDS props and tokens instead
|
|
142
|
+
<Button sdsType="primary" className="p-sds-m">Good</Button>
|
|
143
|
+
```
|
|
144
|
+
|
|
145
|
+
### Don't Mix Design Systems
|
|
146
|
+
|
|
147
|
+
```tsx
|
|
148
|
+
// ❌ Don't mix SDS with other component libraries
|
|
149
|
+
<MuiButton>Mixed</MuiButton>
|
|
150
|
+
<Button>SDS Button</Button>
|
|
151
|
+
|
|
152
|
+
// ✅ Use SDS consistently
|
|
153
|
+
<Button sdsType="primary">Primary</Button>
|
|
154
|
+
<Button sdsType="secondary">Secondary</Button>
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
### Don't Hardcode Design Tokens
|
|
158
|
+
|
|
159
|
+
```tsx
|
|
160
|
+
// ❌ Avoid hardcoded spacing/colors
|
|
161
|
+
<div className="p-4 text-blue-600">Bad</div>
|
|
162
|
+
|
|
163
|
+
// ✅ Use SDS tokens
|
|
164
|
+
<div className="p-sds-m text-light-sds-color-semantic-accent-text-primary">Good</div>
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
## Integration with Other Systems
|
|
168
|
+
|
|
169
|
+
### With Tailwind CSS
|
|
170
|
+
|
|
171
|
+
- SDS provides Tailwind configuration - use it as the foundation
|
|
172
|
+
- SDS classes take precedence over generic Tailwind classes
|
|
173
|
+
- Use SDS breakpoints for responsive design
|
|
174
|
+
|
|
175
|
+
### With React Frameworks
|
|
176
|
+
|
|
177
|
+
- SDS components work with Next.js, React Router, etc.
|
|
178
|
+
- Use SDS Link component for navigation when possible
|
|
179
|
+
- Maintain SDS patterns in framework-specific code
|
|
180
|
+
|
|
181
|
+
## Best Practices Summary
|
|
182
|
+
|
|
183
|
+
1. **Component First**: Always check if SDS has a component before building custom
|
|
184
|
+
2. **Tokens Always**: Use SDS design tokens (spacing, colors, typography) consistently
|
|
185
|
+
3. **Props Over Classes**: Use SDS-specific props rather than overriding with classes
|
|
186
|
+
4. **Accessibility Built-in**: Leverage SDS components' accessibility features
|
|
187
|
+
5. **Dark Mode Ready**: Always include dark mode color variants
|
|
188
|
+
6. **TypeScript Friendly**: Use SDS TypeScript interfaces and types
|
|
189
|
+
7. **Test Integration**: Focus tests on business logic, rely on SDS component testing
|
|
@@ -0,0 +1,180 @@
|
|
|
1
|
+
# Zeroheight Documentation Adherence Rules
|
|
2
|
+
|
|
3
|
+
These rules guide Claude Code when using Zeroheight documentation to ensure accurate implementation of the CZI Science Design System (SDS).
|
|
4
|
+
|
|
5
|
+
## Documentation as Source of Truth
|
|
6
|
+
|
|
7
|
+
### Component Usage Guidelines
|
|
8
|
+
|
|
9
|
+
- **Always reference Zeroheight documentation** for component usage guidelines
|
|
10
|
+
- Follow documented usage patterns and restrictions
|
|
11
|
+
- Respect component do's and don'ts specified in documentation
|
|
12
|
+
- Use documented prop combinations and avoid deprecated patterns
|
|
13
|
+
|
|
14
|
+
### API Documentation Priority
|
|
15
|
+
|
|
16
|
+
- **Zeroheight component documentation overrides assumptions**
|
|
17
|
+
- Check documented prop options before implementing
|
|
18
|
+
- Follow documented accessibility requirements
|
|
19
|
+
- Use documented examples as implementation templates
|
|
20
|
+
|
|
21
|
+
## Component Implementation Rules
|
|
22
|
+
|
|
23
|
+
### Props and Configuration
|
|
24
|
+
|
|
25
|
+
- **Use only documented prop values** and combinations
|
|
26
|
+
- Follow documented prop hierarchies (e.g., `sdsStyle` + `sdsType` combinations)
|
|
27
|
+
- Respect documented prop requirements (required vs optional)
|
|
28
|
+
- Check Zeroheight for component-specific prop validation rules
|
|
29
|
+
|
|
30
|
+
### Usage Patterns
|
|
31
|
+
|
|
32
|
+
- **Follow documented composition patterns**:
|
|
33
|
+
- How components should be combined (e.g., Button + Icon)
|
|
34
|
+
- Proper nesting relationships (e.g., AccordionHeader in Accordion)
|
|
35
|
+
- Layout recommendations for component groups
|
|
36
|
+
|
|
37
|
+
### Accessibility Requirements
|
|
38
|
+
|
|
39
|
+
- **Implement documented accessibility patterns**
|
|
40
|
+
- Use documented ARIA patterns and labels
|
|
41
|
+
- Follow documented keyboard navigation requirements
|
|
42
|
+
- Implement documented focus management patterns
|
|
43
|
+
|
|
44
|
+
## Content and Copy Guidelines
|
|
45
|
+
|
|
46
|
+
### Terminology
|
|
47
|
+
|
|
48
|
+
- **Use SDS-approved terminology** from Zeroheight glossary
|
|
49
|
+
- Follow documented naming conventions for UI elements
|
|
50
|
+
- Use consistent language patterns across components
|
|
51
|
+
- Respect documented content guidelines (e.g., button text patterns)
|
|
52
|
+
|
|
53
|
+
### Microcopy Standards
|
|
54
|
+
|
|
55
|
+
- **Follow documented content standards** for:
|
|
56
|
+
- Error messages and validation text
|
|
57
|
+
- Placeholder text patterns
|
|
58
|
+
- Help text and tooltips
|
|
59
|
+
- Loading and empty states
|
|
60
|
+
|
|
61
|
+
## Visual Implementation
|
|
62
|
+
|
|
63
|
+
### Design Specifications
|
|
64
|
+
|
|
65
|
+
- **Extract exact specifications** from Zeroheight:
|
|
66
|
+
- Spacing measurements and relationships
|
|
67
|
+
- Typography specifications
|
|
68
|
+
- Color usage in different contexts
|
|
69
|
+
- Component states and variations
|
|
70
|
+
|
|
71
|
+
### Responsive Behavior
|
|
72
|
+
|
|
73
|
+
- **Implement documented responsive patterns**
|
|
74
|
+
- Follow documented breakpoint behavior
|
|
75
|
+
- Use documented mobile adaptations
|
|
76
|
+
- Implement documented touch interaction patterns
|
|
77
|
+
|
|
78
|
+
## Integration Guidelines
|
|
79
|
+
|
|
80
|
+
### Framework Integration
|
|
81
|
+
|
|
82
|
+
- **Follow documented framework-specific guidance**
|
|
83
|
+
- Use documented integration patterns for React/Next.js
|
|
84
|
+
- Implement documented data binding patterns
|
|
85
|
+
- Follow documented performance recommendations
|
|
86
|
+
|
|
87
|
+
### State Management
|
|
88
|
+
|
|
89
|
+
- **Implement documented state patterns**:
|
|
90
|
+
- Form state management recommendations
|
|
91
|
+
- Loading and error state handling
|
|
92
|
+
- User interaction state patterns
|
|
93
|
+
- Data validation approaches
|
|
94
|
+
|
|
95
|
+
## Quality Assurance
|
|
96
|
+
|
|
97
|
+
### Implementation Validation
|
|
98
|
+
|
|
99
|
+
- **Cross-reference implementation with Zeroheight examples**
|
|
100
|
+
- Verify component behavior matches documented examples
|
|
101
|
+
- Test edge cases mentioned in documentation
|
|
102
|
+
- Validate accessibility implementation against documented requirements
|
|
103
|
+
|
|
104
|
+
### Documentation Gaps
|
|
105
|
+
|
|
106
|
+
- **When documentation is unclear or missing**:
|
|
107
|
+
- Use SDS Storybook as secondary reference
|
|
108
|
+
- Follow established SDS patterns from similar components
|
|
109
|
+
- Document any assumptions made for future clarification
|
|
110
|
+
- Prefer conservative/minimal implementations
|
|
111
|
+
|
|
112
|
+
## Best Practices
|
|
113
|
+
|
|
114
|
+
### Documentation Workflow
|
|
115
|
+
|
|
116
|
+
1. **Always check Zeroheight first** before implementing any SDS component
|
|
117
|
+
2. **Read the full component documentation** including usage guidelines
|
|
118
|
+
3. **Review examples and code snippets** provided in documentation
|
|
119
|
+
4. **Check for any usage restrictions** or warnings
|
|
120
|
+
5. **Validate implementation** against documented examples
|
|
121
|
+
|
|
122
|
+
### Staying Current
|
|
123
|
+
|
|
124
|
+
- **Documentation updates**: Assume Zeroheight content is most current
|
|
125
|
+
- **Version compatibility**: Check documented version compatibility
|
|
126
|
+
- **Deprecation notices**: Follow documented migration paths for deprecated patterns
|
|
127
|
+
- **New features**: Use documented new features rather than workarounds
|
|
128
|
+
|
|
129
|
+
### Implementation Priority Order
|
|
130
|
+
|
|
131
|
+
1. **Zeroheight documentation** (primary source of truth)
|
|
132
|
+
2. **SDS Storybook** (implementation examples and edge cases)
|
|
133
|
+
3. **TypeScript interfaces** (technical prop definitions)
|
|
134
|
+
4. **Existing codebase patterns** (established usage in project)
|
|
135
|
+
|
|
136
|
+
## Common Documentation Patterns
|
|
137
|
+
|
|
138
|
+
### Component Pages Structure
|
|
139
|
+
|
|
140
|
+
- **Overview**: Component purpose and when to use
|
|
141
|
+
- **Usage Guidelines**: Do's and don'ts with examples
|
|
142
|
+
- **Props/API**: Detailed prop documentation
|
|
143
|
+
- **Examples**: Code snippets and live examples
|
|
144
|
+
- **Accessibility**: ARIA patterns and keyboard navigation
|
|
145
|
+
- **Related Components**: Integration recommendations
|
|
146
|
+
|
|
147
|
+
### Information Hierarchy
|
|
148
|
+
|
|
149
|
+
- **Design Guidelines** → Visual specifications and usage
|
|
150
|
+
- **Development Guidelines** → Implementation requirements
|
|
151
|
+
- **Accessibility Guidelines** → WCAG compliance patterns
|
|
152
|
+
- **Content Guidelines** → Copy and terminology standards
|
|
153
|
+
|
|
154
|
+
## Troubleshooting with Documentation
|
|
155
|
+
|
|
156
|
+
### When Implementation Doesn't Match Design
|
|
157
|
+
|
|
158
|
+
1. **Check Zeroheight for variant documentation**
|
|
159
|
+
2. **Look for conditional usage patterns**
|
|
160
|
+
3. **Verify responsive behavior specifications**
|
|
161
|
+
4. **Check for theme-specific implementations**
|
|
162
|
+
|
|
163
|
+
### When Behavior Seems Unexpected
|
|
164
|
+
|
|
165
|
+
1. **Review documented component lifecycle**
|
|
166
|
+
2. **Check for documented state management patterns**
|
|
167
|
+
3. **Verify prop combination compatibility**
|
|
168
|
+
4. **Look for documented browser-specific considerations**
|
|
169
|
+
|
|
170
|
+
## Documentation-Driven Development
|
|
171
|
+
|
|
172
|
+
### Implementation Process
|
|
173
|
+
|
|
174
|
+
1. **Read documentation thoroughly** before writing code
|
|
175
|
+
2. **Plan implementation** based on documented patterns
|
|
176
|
+
3. **Code with documentation open** for reference
|
|
177
|
+
4. **Test against documented examples**
|
|
178
|
+
5. **Document any deviations** with rationale
|
|
179
|
+
|
|
180
|
+
This ensures all SDS implementations are consistent with the official design system documentation and reduces implementation errors.
|
package/dist/stdio.js
CHANGED
|
@@ -2,8 +2,8 @@
|
|
|
2
2
|
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
|
|
3
3
|
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
|
|
4
4
|
import { z } from 'zod';
|
|
5
|
-
import fs from 'fs';
|
|
6
|
-
import path from 'path';
|
|
5
|
+
import fs, { readFileSync, existsSync } from 'fs';
|
|
6
|
+
import path, { dirname as dirname$1, join } from 'path';
|
|
7
7
|
import { fileURLToPath } from 'url';
|
|
8
8
|
|
|
9
9
|
var server = new McpServer({
|
|
@@ -11,7 +11,10 @@ var server = new McpServer({
|
|
|
11
11
|
version: "0.1.0",
|
|
12
12
|
capabilities: {
|
|
13
13
|
prompts: {},
|
|
14
|
-
resources: {
|
|
14
|
+
resources: {
|
|
15
|
+
subscribe: true,
|
|
16
|
+
listChanged: true
|
|
17
|
+
},
|
|
15
18
|
tools: {}
|
|
16
19
|
}
|
|
17
20
|
});
|
|
@@ -759,10 +762,113 @@ var initializeTools = async (server2, config) => {
|
|
|
759
762
|
})
|
|
760
763
|
);
|
|
761
764
|
};
|
|
765
|
+
var FILENAME = fileURLToPath(import.meta.url);
|
|
766
|
+
var DIRNAME = dirname$1(FILENAME);
|
|
767
|
+
var MIME_TYPE_MARKDOWN = "text/markdown";
|
|
768
|
+
var UNKNOWN_ERROR = "Unknown error";
|
|
769
|
+
function findResourceFile(fileName) {
|
|
770
|
+
const possiblePaths = [
|
|
771
|
+
join(DIRNAME, "../../data/resources", fileName),
|
|
772
|
+
// From src/resources in dev
|
|
773
|
+
join(DIRNAME, "../data/resources", fileName),
|
|
774
|
+
// From dist/resources in prod
|
|
775
|
+
join(process.cwd(), "data/resources", fileName)
|
|
776
|
+
// From current working directory
|
|
777
|
+
];
|
|
778
|
+
for (const p of possiblePaths) {
|
|
779
|
+
if (existsSync(p)) {
|
|
780
|
+
return p;
|
|
781
|
+
}
|
|
782
|
+
}
|
|
783
|
+
throw new Error(
|
|
784
|
+
`Resource file '${fileName}' not found in any expected location`
|
|
785
|
+
);
|
|
786
|
+
}
|
|
787
|
+
function initializeResources(server2) {
|
|
788
|
+
server2.resource(
|
|
789
|
+
"Figma to Code Translation Rules",
|
|
790
|
+
"sds://rules/figma",
|
|
791
|
+
{
|
|
792
|
+
mimeType: MIME_TYPE_MARKDOWN,
|
|
793
|
+
description: "Rules for translating Figma designs to SDS code"
|
|
794
|
+
},
|
|
795
|
+
async () => {
|
|
796
|
+
try {
|
|
797
|
+
const filePath = findResourceFile("figma-rules.md");
|
|
798
|
+
const content = readFileSync(filePath, "utf-8");
|
|
799
|
+
return {
|
|
800
|
+
contents: [
|
|
801
|
+
{
|
|
802
|
+
uri: "sds://rules/figma",
|
|
803
|
+
mimeType: MIME_TYPE_MARKDOWN,
|
|
804
|
+
text: content
|
|
805
|
+
}
|
|
806
|
+
]
|
|
807
|
+
};
|
|
808
|
+
} catch (err) {
|
|
809
|
+
const message = err instanceof Error ? err.message : UNKNOWN_ERROR;
|
|
810
|
+
throw new Error("Failed to read Figma rules: " + message);
|
|
811
|
+
}
|
|
812
|
+
}
|
|
813
|
+
);
|
|
814
|
+
server2.resource(
|
|
815
|
+
"SDS Component Usage Rules",
|
|
816
|
+
"sds://rules/components",
|
|
817
|
+
{
|
|
818
|
+
mimeType: MIME_TYPE_MARKDOWN,
|
|
819
|
+
description: "Guidelines for using SDS components correctly"
|
|
820
|
+
},
|
|
821
|
+
async () => {
|
|
822
|
+
try {
|
|
823
|
+
const filePath = findResourceFile("sds-component-rules.md");
|
|
824
|
+
const content = readFileSync(filePath, "utf-8");
|
|
825
|
+
return {
|
|
826
|
+
contents: [
|
|
827
|
+
{
|
|
828
|
+
uri: "sds://rules/components",
|
|
829
|
+
mimeType: MIME_TYPE_MARKDOWN,
|
|
830
|
+
text: content
|
|
831
|
+
}
|
|
832
|
+
]
|
|
833
|
+
};
|
|
834
|
+
} catch (err) {
|
|
835
|
+
const message = err instanceof Error ? err.message : UNKNOWN_ERROR;
|
|
836
|
+
throw new Error("Failed to read component rules: " + message);
|
|
837
|
+
}
|
|
838
|
+
}
|
|
839
|
+
);
|
|
840
|
+
server2.resource(
|
|
841
|
+
"Zeroheight Documentation Rules",
|
|
842
|
+
"sds://rules/zeroheight",
|
|
843
|
+
{
|
|
844
|
+
mimeType: MIME_TYPE_MARKDOWN,
|
|
845
|
+
description: "Rules for following Zeroheight documentation"
|
|
846
|
+
},
|
|
847
|
+
async () => {
|
|
848
|
+
try {
|
|
849
|
+
const filePath = findResourceFile("zeroheight-rules.md");
|
|
850
|
+
const content = readFileSync(filePath, "utf-8");
|
|
851
|
+
return {
|
|
852
|
+
contents: [
|
|
853
|
+
{
|
|
854
|
+
uri: "sds://rules/zeroheight",
|
|
855
|
+
mimeType: MIME_TYPE_MARKDOWN,
|
|
856
|
+
text: content
|
|
857
|
+
}
|
|
858
|
+
]
|
|
859
|
+
};
|
|
860
|
+
} catch (err) {
|
|
861
|
+
const message = err instanceof Error ? err.message : UNKNOWN_ERROR;
|
|
862
|
+
throw new Error("Failed to read Zeroheight rules: " + message);
|
|
863
|
+
}
|
|
864
|
+
}
|
|
865
|
+
);
|
|
866
|
+
}
|
|
762
867
|
|
|
763
868
|
// src/stdio.ts
|
|
764
869
|
async function main() {
|
|
765
870
|
await initializeTools(server, {});
|
|
871
|
+
initializeResources(server);
|
|
766
872
|
const transport = new StdioServerTransport();
|
|
767
873
|
await server.connect(transport);
|
|
768
874
|
}
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@czi-sds/mcp",
|
|
3
3
|
"description": "The official MCP server for SDS",
|
|
4
|
-
"version": "0.
|
|
4
|
+
"version": "0.5.1",
|
|
5
5
|
"main": "dist/stdio.js",
|
|
6
6
|
"files": [
|
|
7
7
|
"dist",
|
|
@@ -62,5 +62,5 @@
|
|
|
62
62
|
"tsx": "^4.20.3",
|
|
63
63
|
"typescript": "^5.9.2"
|
|
64
64
|
},
|
|
65
|
-
"gitHead": "
|
|
65
|
+
"gitHead": "13b6693e88455be99976c49d48f566f1548ee8b4"
|
|
66
66
|
}
|