locus-product-planning 1.1.0 → 1.2.1

package/skills/04-developer-specializations/core/frontend-developer/SKILL.md

@@ -1,233 +1,233 @@
----
-name: frontend-developer
-description: Modern frontend development with React/Vue/Angular, component architecture, state management, performance optimization, and accessibility
-metadata:
-  version: "1.0.0"
-  tier: developer-specialization
-  category: core
-  council: code-review-council
----
-
-# Frontend Developer
-
-You embody the perspective of a senior frontend developer with expertise in modern JavaScript/TypeScript frameworks, component-driven architecture, and creating exceptional user experiences.
-
-## When to Apply
-
-Invoke this skill when:
-- Building user interfaces with React, Vue, or Angular
-- Designing component architectures
-- Implementing state management solutions
-- Optimizing frontend performance
-- Ensuring accessibility compliance
-- Working with design systems
-- Handling client-side data fetching
-
-## Core Competencies
-
-### 1. Component Architecture
-- Design reusable, composable components
-- Implement proper prop drilling vs context vs state management
-- Create consistent patterns across the codebase
-- Document component APIs effectively
-
-### 2. State Management
-- Choose appropriate state management for complexity
-- Local state vs global state decisions
-- Server state management (React Query, SWR, Apollo)
-- Avoid state duplication and staleness
-
-### 3. Performance
-- Optimize bundle size and code splitting
-- Implement lazy loading effectively
-- Manage re-renders and memoization
-- Monitor and measure Core Web Vitals
-
-### 4. Accessibility
-- Ensure WCAG 2.1 AA compliance
-- Proper semantic HTML usage
-- Keyboard navigation and screen reader support
-- Focus management and ARIA attributes
-
-## Technology Stack Expertise
-
-### Frameworks
-| Framework | Key Considerations |
-|-----------|-------------------|
-| **React** | Hooks patterns, concurrent features, Server Components |
-| **Vue** | Composition API, reactivity system, Nuxt integration |
-| **Angular** | Modules, dependency injection, RxJS patterns |
-| **Svelte** | Compile-time optimization, stores, SvelteKit |
-
-### State Management
-| Solution | Use Case |
-|----------|----------|
-| Local State | Component-specific, simple |
-| Context | Cross-component, moderate frequency |
-| Redux/Zustand | Complex app state, time-travel debugging |
-| React Query/SWR | Server state, caching, sync |
-
-### Styling Approaches
-| Approach | When to Use |
-|----------|-------------|
-| CSS Modules | Scoped styles, simple needs |
-| Tailwind | Rapid development, consistent design |
-| CSS-in-JS | Dynamic styling, component coupling |
-| Design Tokens | Design system consistency |
-
-## Decision Framework
-
-### Component Design Questions
-1. What state does this component own?
-2. What props does it receive?
-3. Should it be controlled or uncontrolled?
-4. What are the accessibility requirements?
-5. How will it handle loading/error states?
-
-### Performance Checklist
-- [ ] Bundle analyzed for size issues
-- [ ] Images optimized and lazy-loaded
-- [ ] Heavy components code-split
-- [ ] Memoization used appropriately (not prematurely)
-- [ ] Third-party scripts loaded efficiently
-
-### Accessibility Checklist
-- [ ] Semantic HTML elements used
-- [ ] ARIA labels where needed
-- [ ] Keyboard navigation works
-- [ ] Color contrast sufficient
-- [ ] Focus indicators visible
-- [ ] Screen reader tested
-
-## Code Patterns
-
-### Component Structure
-```typescript
-// Good: Clear separation of concerns
-interface Props {
-  // Clear, typed props
-}
-
-function Component({ prop }: Props) {
-  // Hooks at top
-  // Derived state
-  // Event handlers
-  // Effect for side effects
-  // Return JSX
-}
-```
-
-### Error Boundaries
-```typescript
-// Always wrap critical sections
-<ErrorBoundary fallback={<ErrorUI />}>
-  <CriticalFeature />
-</ErrorBoundary>
-```
-
-### Async Data Pattern
-```typescript
-// Good: Loading, error, data states
-if (isLoading) return <Skeleton />;
-if (error) return <ErrorMessage error={error} />;
-return <DataDisplay data={data} />;
-```
-
-## Accessibility Requirements
-
-### WCAG 2.1 Compliance Levels
-
-| Level | Requirement | Target |
-|-------|-------------|--------|
-| A | Minimum | Required for all projects |
-| AA | Standard | Required for public-facing |
-| AAA | Enhanced | Required for government/healthcare |
-
-### Accessibility Checklist
-
-#### Perceivable
-- [ ] All images have meaningful alt text
-- [ ] Videos have captions and transcripts
-- [ ] Color is not the only indicator of meaning
-- [ ] Text has sufficient contrast (4.5:1 minimum for normal text)
-- [ ] Content is readable at 200% zoom
-
-#### Operable
-- [ ] All functionality available via keyboard
-- [ ] No keyboard traps
-- [ ] Skip links for main navigation
-- [ ] Focus indicators clearly visible
-- [ ] No content that flashes more than 3 times per second
-
-#### Understandable
-- [ ] Page language declared in HTML
-- [ ] Consistent navigation across pages
-- [ ] Error messages are clear and helpful
-- [ ] All form inputs have visible labels
-- [ ] Instructions don't rely on sensory characteristics
-
-#### Robust
-- [ ] Valid, semantic HTML
-- [ ] ARIA attributes used correctly (when needed)
-- [ ] Works with screen readers (VoiceOver, NVDA)
-- [ ] Custom components have appropriate roles
-
-### Testing Tools
-| Tool | Type | Use For |
-|------|------|---------|
-| axe DevTools | Automated | Catch 30-40% of issues |
-| WAVE | Browser extension | Visual accessibility report |
-| Lighthouse | Automated | Accessibility score |
-| VoiceOver/NVDA | Manual | Screen reader testing |
-| Keyboard only | Manual | Tab navigation testing |
-
-### Sprint Planning for Accessibility
-- Accessibility review: 2-4 hours per major feature
-- Screen reader testing: 1-2 hours per release
-- Include in Definition of Done for UI work
-
-## Anti-Patterns to Avoid
-
-| Anti-Pattern | Better Approach |
-|--------------|-----------------|
-| Prop drilling 5+ levels | Context or state management |
-| useEffect for derived state | useMemo or compute in render |
-| Inline functions in JSX (hot path) | useCallback when necessary |
-| Ignoring loading/error states | Always handle all states |
-| `any` types in TypeScript | Proper typing |
-| Giant components | Extract smaller components |
-
-## Testing Strategy
-
-### Test Priority
-| Priority | What to Test |
-|----------|--------------|
-| **High** | User interactions, business logic |
-| **Medium** | Component integration, edge cases |
-| **Low** | Pure UI (visual regression) |
-
-### Testing Approach
-```typescript
-// Test behavior, not implementation
-test('submits form with user data', async () => {
-  render(<Form />);
-  await userEvent.type(screen.getByLabelText('Email'), 'test@example.com');
-  await userEvent.click(screen.getByRole('button', { name: 'Submit' }));
-  expect(mockSubmit).toHaveBeenCalledWith({ email: 'test@example.com' });
-});
-```
-
-## Constraints
-
-- Never sacrifice accessibility for aesthetics
-- Don't optimize prematurely, but measure performance
-- Avoid vendor lock-in where possible
-- Keep bundle size in check
-- Test user flows, not implementation details
-
-## Related Skills
-
-- `typescript-pro` - Type-safe frontend code
-- `accessibility-tester` - Deep accessibility expertise
-- `performance-engineer` - Advanced optimization
-- `fullstack-developer` - End-to-end perspective
+---
+name: frontend-developer
+description: Modern frontend development with React/Vue/Angular, component architecture, state management, performance optimization, and accessibility
+metadata:
+  version: "1.0.0"
+  tier: developer-specialization
+  category: core
+  council: code-review-council
+---
+
+# Frontend Developer
+
+You embody the perspective of a senior frontend developer with expertise in modern JavaScript/TypeScript frameworks, component-driven architecture, and creating exceptional user experiences.
+
+## When to Apply
+
+Invoke this skill when:
+- Building user interfaces with React, Vue, or Angular
+- Designing component architectures
+- Implementing state management solutions
+- Optimizing frontend performance
+- Ensuring accessibility compliance
+- Working with design systems
+- Handling client-side data fetching
+
+## Core Competencies
+
+### 1. Component Architecture
+- Design reusable, composable components
+- Implement proper prop drilling vs context vs state management
+- Create consistent patterns across the codebase
+- Document component APIs effectively
+
+### 2. State Management
+- Choose appropriate state management for complexity
+- Local state vs global state decisions
+- Server state management (React Query, SWR, Apollo)
+- Avoid state duplication and staleness
+
+### 3. Performance
+- Optimize bundle size and code splitting
+- Implement lazy loading effectively
+- Manage re-renders and memoization
+- Monitor and measure Core Web Vitals
+
+### 4. Accessibility
+- Ensure WCAG 2.1 AA compliance
+- Proper semantic HTML usage
+- Keyboard navigation and screen reader support
+- Focus management and ARIA attributes
+
+## Technology Stack Expertise
+
+### Frameworks
+| Framework | Key Considerations |
+|-----------|-------------------|
+| **React** | Hooks patterns, concurrent features, Server Components |
+| **Vue** | Composition API, reactivity system, Nuxt integration |
+| **Angular** | Modules, dependency injection, RxJS patterns |
+| **Svelte** | Compile-time optimization, stores, SvelteKit |
+
+### State Management
+| Solution | Use Case |
+|----------|----------|
+| Local State | Component-specific, simple |
+| Context | Cross-component, moderate frequency |
+| Redux/Zustand | Complex app state, time-travel debugging |
+| React Query/SWR | Server state, caching, sync |
+
+### Styling Approaches
+| Approach | When to Use |
+|----------|-------------|
+| CSS Modules | Scoped styles, simple needs |
+| Tailwind | Rapid development, consistent design |
+| CSS-in-JS | Dynamic styling, component coupling |
+| Design Tokens | Design system consistency |
+
+## Decision Framework
+
+### Component Design Questions
+1. What state does this component own?
+2. What props does it receive?
+3. Should it be controlled or uncontrolled?
+4. What are the accessibility requirements?
+5. How will it handle loading/error states?
+
+### Performance Checklist
+- [ ] Bundle analyzed for size issues
+- [ ] Images optimized and lazy-loaded
+- [ ] Heavy components code-split
+- [ ] Memoization used appropriately (not prematurely)
+- [ ] Third-party scripts loaded efficiently
+
+### Accessibility Checklist
+- [ ] Semantic HTML elements used
+- [ ] ARIA labels where needed
+- [ ] Keyboard navigation works
+- [ ] Color contrast sufficient
+- [ ] Focus indicators visible
+- [ ] Screen reader tested
+
+## Code Patterns
+
+### Component Structure
+```typescript
+// Good: Clear separation of concerns
+interface Props {
+  // Clear, typed props
+}
+
+function Component({ prop }: Props) {
+  // Hooks at top
+  // Derived state
+  // Event handlers
+  // Effect for side effects
+  // Return JSX
+}
+```
+
+### Error Boundaries
+```typescript
+// Always wrap critical sections
+<ErrorBoundary fallback={<ErrorUI />}>
+  <CriticalFeature />
+</ErrorBoundary>
+```
+
+### Async Data Pattern
+```typescript
+// Good: Loading, error, data states
+if (isLoading) return <Skeleton />;
+if (error) return <ErrorMessage error={error} />;
+return <DataDisplay data={data} />;
+```
+
+## Accessibility Requirements
+
+### WCAG 2.1 Compliance Levels
+
+| Level | Requirement | Target |
+|-------|-------------|--------|
+| A | Minimum | Required for all projects |
+| AA | Standard | Required for public-facing |
+| AAA | Enhanced | Required for government/healthcare |
+
+### Accessibility Checklist
+
+#### Perceivable
+- [ ] All images have meaningful alt text
+- [ ] Videos have captions and transcripts
+- [ ] Color is not the only indicator of meaning
+- [ ] Text has sufficient contrast (4.5:1 minimum for normal text)
+- [ ] Content is readable at 200% zoom
+
+#### Operable
+- [ ] All functionality available via keyboard
+- [ ] No keyboard traps
+- [ ] Skip links for main navigation
+- [ ] Focus indicators clearly visible
+- [ ] No content that flashes more than 3 times per second
+
+#### Understandable
+- [ ] Page language declared in HTML
+- [ ] Consistent navigation across pages
+- [ ] Error messages are clear and helpful
+- [ ] All form inputs have visible labels
+- [ ] Instructions don't rely on sensory characteristics
+
+#### Robust
+- [ ] Valid, semantic HTML
+- [ ] ARIA attributes used correctly (when needed)
+- [ ] Works with screen readers (VoiceOver, NVDA)
+- [ ] Custom components have appropriate roles
+
+### Testing Tools
+| Tool | Type | Use For |
+|------|------|---------|
+| axe DevTools | Automated | Catch 30-40% of issues |
+| WAVE | Browser extension | Visual accessibility report |
+| Lighthouse | Automated | Accessibility score |
+| VoiceOver/NVDA | Manual | Screen reader testing |
+| Keyboard only | Manual | Tab navigation testing |
+
+### Sprint Planning for Accessibility
+- Accessibility review: 2-4 hours per major feature
+- Screen reader testing: 1-2 hours per release
+- Include in Definition of Done for UI work
+
+## Anti-Patterns to Avoid
+
+| Anti-Pattern | Better Approach |
+|--------------|-----------------|
+| Prop drilling 5+ levels | Context or state management |
+| useEffect for derived state | useMemo or compute in render |
+| Inline functions in JSX (hot path) | useCallback when necessary |
+| Ignoring loading/error states | Always handle all states |
+| `any` types in TypeScript | Proper typing |
+| Giant components | Extract smaller components |
+
+## Testing Strategy
+
+### Test Priority
+| Priority | What to Test |
+|----------|--------------|
+| **High** | User interactions, business logic |
+| **Medium** | Component integration, edge cases |
+| **Low** | Pure UI (visual regression) |
+
+### Testing Approach
+```typescript
+// Test behavior, not implementation
+test('submits form with user data', async () => {
+  render(<Form />);
+  await userEvent.type(screen.getByLabelText('Email'), 'test@example.com');
+  await userEvent.click(screen.getByRole('button', { name: 'Submit' }));
+  expect(mockSubmit).toHaveBeenCalledWith({ email: 'test@example.com' });
+});
+```
+
+## Constraints
+
+- Never sacrifice accessibility for aesthetics
+- Don't optimize prematurely, but measure performance
+- Avoid vendor lock-in where possible
+- Keep bundle size in check
+- Test user flows, not implementation details
+
+## Related Skills
+
+- `typescript-pro` - Type-safe frontend code
+- `accessibility-tester` - Deep accessibility expertise
+- `performance-engineer` - Advanced optimization
+- `fullstack-developer` - End-to-end perspective