/frontend
Reviews React/Vue component architecture, state, and hooks. Use when junior builds components, forms, modals, uses useState, useEffect, adds state, or asks "is this good React".
$ npx -y skills add DanielPodolsky/ownyourcode --skill frontend --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/frontend
Context preview
The summary Claude sees to decide when to auto-load this skill.
Reviews React/Vue component architecture, state, and hooks. Use when junior builds components, forms, modals, uses useState, useEffect, adds state, or asks "is this good React".
SKILL.md
frontend.SKILL.mdname: frontend-fundamentals
description: Reviews React/Vue component architecture, state, and hooks. Use when junior builds components, forms, modals, uses useState, useEffect, adds state, or asks "is this good React".
Frontend Fundamentals Review
> "A component should do ONE thing well. If you're describing it with 'and', split it."
When to Apply
Activate this skill when reviewing:
- React/Vue/Svelte components
- UI rendering logic
- State management code
- CSS/styling decisions
- Client-side routing
---
Review Checklist
Component Architecture
- [ ] **Single Responsibility**: Does each component do ONE job?
- [ ] **Size Check**: Is the component under 200 lines?
- [ ] **Props Count**: Are there fewer than 7 props?
- [ ] **Naming**: Can you describe the component without saying "and"?
State Management
- [ ] **Colocation**: Is state as close as possible to where it's used?
- [ ] **Lifting**: Is state shared properly between siblings via parent?
- [ ] **Context vs Props**: Is prop drilling avoided (max 3 levels)?
- [ ] **Server State**: Is server data managed separately (React Query/SWR)?
Performance
- [ ] **Memoization**: Are expensive computations wrapped in useMemo?
- [ ] **Callbacks**: Are event handlers wrapped in useCallback where needed?
- [ ] **Re-renders**: Will this cause unnecessary re-renders?
- [ ] **Lazy Loading**: Are heavy components code-split?
Accessibility
- [ ] **Semantic HTML**: Are proper elements used (button vs div)?
- [ ] **ARIA**: Are interactive elements accessible?
- [ ] **Keyboard**: Can users navigate without a mouse?
---
Common Mistakes (Anti-Patterns)
1. God Components
❌ UserDashboard.tsx (1000 lines)
- fetches data, manages state, renders UI, handles routing
✅ Split into:
- UserDashboardPage.tsx (container)
- UserStats.tsx (presentation)
- UserActivity.tsx (presentation)
- useUserData.ts (hook)
2. Logic in Render
❌ return <div>{users.filter(u => u.active).map(u => ...)}</div>
✅ const activeUsers = useMemo(() => users.filter(u => u.active), [users]);
return <div>{activeUsers.map(u => ...)}</div>3. Prop Drilling
❌ <App user={user}>
<Layout user={user}>
<Main user={user}>
<Widget user={user} />
✅ const user = useUser(); // in Widget.tsx4. Boolean Prop Soup
❌ <Button primary secondary large small disabled loading />
✅ <Button variant="primary" size="large" state="loading" />
---
Socratic Questions
Ask the junior these questions instead of giving answers:
1. **Architecture**: "What is the ONE job of this component?" 2. **Splitting**: "If I asked you to use just the header part elsewhere, could you?" 3. **State**: "Who needs this data? Should it live here or higher up?" 4. **Performance**: "What happens when the parent re-renders?" 5. **Complexity**: "Could a new developer understand this in 5 minutes?"
---
Standards Reference
See detailed patterns in:
- `/standards/frontend/component-architecture.md`
---
Red Flags to Call Out
| Flag | Question to Ask | |------|-----------------| | File > 200 lines | "Can we split this into smaller pieces?" | | > 5 useState calls | "Should some of this state be lifted or combined?" | | useEffect with [] deps but uses external values | "Are we missing dependencies?" | | Direct DOM manipulation | "Is there a React way to do this?" | | Inline styles everywhere | "Should we use a consistent styling approach?" |
Read more
name: frontend-fundamentals description: Reviews React/Vue component architecture, state, and hooks. Use when junior builds components, forms, modals, uses useState, useEffect, adds state, or asks "is this good React".
Frontend Fundamentals Review
> "A component should do ONE thing well. If you're describing it with 'and', split it."
When to Apply
Activate this skill when reviewing:
- React/Vue/Svelte components
- UI rendering logic
- State management code
- CSS/styling decisions
- Client-side routing
---
Review Checklist
Component Architecture
- [ ] **Single Responsibility**: Does each component do ONE job?
- [ ] **Size Check**: Is the component under 200 lines?
- [ ] **Props Count**: Are there fewer than 7 props?
- [ ] **Naming**: Can you describe the component without saying "and"?
State Management
- [ ] **Colocation**: Is state as close as possible to where it's used?
- [ ] **Lifting**: Is state shared properly between siblings via parent?
- [ ] **Context vs Props**: Is prop drilling avoided (max 3 levels)?
- [ ] **Server State**: Is server data managed separately (React Query/SWR)?
Performance
- [ ] **Memoization**: Are expensive computations wrapped in useMemo?
- [ ] **Callbacks**: Are event handlers wrapped in useCallback where needed?
- [ ] **Re-renders**: Will this cause unnecessary re-renders?
- [ ] **Lazy Loading**: Are heavy components code-split?
Accessibility
- [ ] **Semantic HTML**: Are proper elements used (button vs div)?
- [ ] **ARIA**: Are interactive elements accessible?
- [ ] **Keyboard**: Can users navigate without a mouse?
---
Common Mistakes (Anti-Patterns)
1. God Components
❌ UserDashboard.tsx (1000 lines) - fetches data, manages state, renders UI, handles routing ✅ Split into: - UserDashboardPage.tsx (container) - UserStats.tsx (presentation) - UserActivity.tsx (presentation) - useUserData.ts (hook)
2. Logic in Render
❌ return <div>{users.filter(u => u.active).map(u => ...)}</div>
✅ const activeUsers = useMemo(() => users.filter(u => u.active), [users]);
return <div>{activeUsers.map(u => ...)}</div>3. Prop Drilling
❌ <App user={user}>
<Layout user={user}>
<Main user={user}>
<Widget user={user} />
✅ const user = useUser(); // in Widget.tsx4. Boolean Prop Soup
❌ <Button primary secondary large small disabled loading /> ✅ <Button variant="primary" size="large" state="loading" />
---
Socratic Questions
Ask the junior these questions instead of giving answers:
1. **Architecture**: "What is the ONE job of this component?" 2. **Splitting**: "If I asked you to use just the header part elsewhere, could you?" 3. **State**: "Who needs this data? Should it live here or higher up?" 4. **Performance**: "What happens when the parent re-renders?" 5. **Complexity**: "Could a new developer understand this in 5 minutes?"
---
Standards Reference
See detailed patterns in:
- `/standards/frontend/component-architecture.md`
---
Red Flags to Call Out
| Flag | Question to Ask | |------|-----------------| | File > 200 lines | "Can we split this into smaller pieces?" | | > 5 useState calls | "Should some of this state be lifted or combined?" | | useEffect with [] deps but uses external values | "Are we missing dependencies?" | | Direct DOM manipulation | "Is there a React way to do this?" | | Inline styles everywhere | "Should we use a consistent styling approach?" |
Claude Code workflow for AI-mentored development. Work efficiently with Spec-Driven Development and the 6 Gates. Built to fight cognitive offloading — for developers using AI to grow and maintain ownership.
Repo: DanielPodolsky/ownyourcode
Other skills on ownyourcode.
- /resume-bullets
Transforms completed work into powerful resume bullet points with action verbs, technical context, and quantified impact. Use when completing tasks, updating portfolio, or preparing job applications.
Open skill - /star-stories
Transforms completed work into STAR interview stories (Situation, Task, Action, Result). Use when completing tasks, preparing for behavioral interviews, or documenting achievements.
Open skill - /accessibility
Reviews accessibility including WCAG, ARIA, keyboard navigation. Use when junior builds forms, buttons, modals, interactive elements, or asks "is this accessible", "a11y", "screen reader".
Open skill - /backend
Reviews API design, REST conventions, and backend architecture. Use when junior builds API endpoints, Express routes, middleware, controllers, or asks "is this RESTful", "check my endpoint".
Open skill - /database
Reviews schema design, SQL queries, ORM patterns. Use when junior creates schema, writes queries, adds migrations, works with Prisma/MongoDB/PostgreSQL, or asks "is this SQL safe", "N+1", "index".
Open skill - /debugging
Guides systematic debugging through Protocol D (READ, ISOLATE, DOCS, HYPOTHESIZE, VERIFY). Use when junior says "stuck", "not working", "broken", "bug", "error", "crashed", "failing", "can't figure out", or expresses frustration. Do NOT use for general questions.
Open skill

