/frontend-component

name: frontend-component
description: Create React/Vue component with TypeScript, tests, and styles. Auto-invoke when user says "create component", "add component", "new component", or "build component".
allowed-tools: Read, Write, Edit, Grep, Glob, Bash
version: 2.0.0

Frontend Component Generator

Generate production-ready React/Vue components with TypeScript, tests, and styles following modern best practices.

When to Invoke

Auto-invoke when user mentions:

• "Create a component"
• "Add a component"
• "New component"
• "Build a component"
• "Generate component for [feature]"

What This Does

1. Generates component file with TypeScript and props interface 2. Creates test file with React Testing Library 3. Generates CSS module for styling 4. Creates barrel export (index.ts) 5. Validates naming conventions 6. Follows project patterns

Execution Steps

Step 0: Check Existing Patterns (Phase 0)

Before gathering requirements, query the knowledge graph for what we already know about frontend/component work in this project. This mirrors `navigator-research`'s Phase 0 and prevents re-deriving patterns we've already decided on.

PLUGIN_DIR="${CLAUDE_PLUGIN_ROOT:-$(cat "${NAVIGATOR_CONFIG_HOME:-${XDG_CONFIG_HOME:-$HOME/.config}/navigator}/plugin-root" 2>/dev/null)}"
[ -d "$PLUGIN_DIR/skills" ] || PLUGIN_DIR="$HOME/.claude/plugins/marketplaces/navigator-marketplace"
python3 "$PLUGIN_DIR/skills/nav-graph/functions/graph_manager.py" \
  --action query --concept frontend \
  --graph-path .agent/knowledge/graph.json 2>/dev/null | head -40

If memories surface (look for `PATTERN`, `PITFALL`, `DECISION` entries), read the full memory files for any directly relevant ones:

ls .agent/knowledge/memories/{patterns,pitfalls,decisions}/ 2>/dev/null

**What to do with what you find**:

• **Patterns**: apply them (don't re-derive — e.g. "we use CSS Modules, not styled-components")
• **Pitfalls**: avoid them (record in `pitfalls_avoided` in Step 8)
• **Decisions**: respect them (e.g. "we chose React.memo for list items")

If the graph returns nothing useful, proceed without it. Skip this step only if the knowledge graph is disabled in `.agent/.nav-config.json`.

Step 1: Gather Component Requirements

**First, detect the framework**: read `package.json`. If `"next"` is in `dependencies`, this is a Next.js App Router project — use the Next.js variants in Step 3 and **default styling to Tailwind** (no CSS module file). See `.agent/philosophy/NEXTJS-PATTERNS.md` for the patterns these templates encode.

**Ask user for component details**:

Component name: [PascalCase name, e.g., UserProfile]
Component type:
  Generic React:
    - simple            (basic functional component)
    - with-hooks        (useState, useEffect, etc.)
    - container         (data fetching component)
  Next.js App Router:
    - nextjs-page       (app/<route>/page.tsx — Server Component, async)
    - nextjs-layout     (app/<route>/layout.tsx — Server Component, metadata + viewport)
    - nextjs-server     (Server Component with fetch, async)
    - nextjs-client     ('use client' component with state/effects)

Styling approach:
  - tailwind            (default for nextjs-* types)
  - css-modules         (default for generic React types)
  - styled-components

Props needed: [Optional: describe expected props]

**Picking the right Next.js variant**:

• User says "create a Schedule page" → `nextjs-page`
• User says "wrap the app" / "root layout" → `nextjs-layout`
• User says "needs `useState`" / "click handler" / "interactive" → `nextjs-client`
• User says "fetches data" / "list of X" → `nextjs-server`

**Validate component name**:

• Use predefined function: `functions/name_validator.py`
• Ensure PascalCase format
• No reserved words
• Descriptive and specific

Step 1.5: Confirm Component Design (ToM Checkpoint) [EXECUTE]

**IMPORTANT**: This step MUST be executed for complex components.

**Before generating files, confirm interpretation with user**.

**Display verification**:

I understood you want:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Component: {NAME}
Type: {TYPE} (inferred because: {REASON})
Location: src/components/{NAME}/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Detected patterns from your codebase:
- Styling: {CSS_APPROACH} (found {EVIDENCE})
- Testing: {TEST_LIBRARY} (found in package.json)
- Similar component: {EXISTING_COMPONENT} at {PATH}

Props I'll generate:
{PROPS_PREVIEW}

Proceed with generation? [Y/n]

**Skip verification if** (HIGH-STAKES ONLY mode):

• Simple presentational component (no hooks, no data fetching)
• User explicitly said "quick", "just do it", or "skip confirmation"
• Component name and type are unambiguous
• No complex props structure

**Always verify if**:

• Container component with data fetching
• Complex props interface (5+ props)
• Hooks component with side effects
• Component name similar to existing component
• User is new to codebase (no profile history)

Step 2: Generate Props Interface

**Based on component type and requirements**:

Use predefined function: `functions/props_interface_generator.py`

# Generates TypeScript interface based on component requirements
python3 functions/props_interface_generator.py \
  --name "UserProfile" \
  --props "userId:string,onUpdate:function,isActive:boolean"

**Output**:

interface UserProfileProps {
  userId: string;
  onUpdate?: () => void;
  isActive?: boolean;
  children?: React.ReactNode;
  className?: string;
}

Step 3: Generate Component File

**Use appropriate template based on type**:

**Simple component**:

Use template: templates/component-simple-template.tsx

**Component with hooks** / **Container component**:

Start from templates/component-simple-template.tsx and add the hook
declarations (useState/useEffect) or data-fetching logic inline — there is
no separate with-hooks/container template file; the simple template is the b