/frontend-test
Generate frontend component tests (React Testing Library, Vue Test Utils, snapshot) for existing components. Auto-invoke when user says "test this component", "write component test", or "add component test".
$ npx -y skills add alekspetrov/navigator --skill frontend-test --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-test
Context preview
The summary Claude sees to decide when to auto-load this skill.
Generate frontend component tests (React Testing Library, Vue Test Utils, snapshot) for existing components. Auto-invoke when user says "test this component", "write component test", or "add component test".
SKILL.md
frontend-test.SKILL.mdname: frontend-test
description: Generate frontend component tests (React Testing Library, Vue Test Utils, snapshot) for existing components. Auto-invoke when user says "test this component", "write component test", or "add component test".
allowed-tools: Read, Write, Edit, Grep, Glob, Bash
version: 2.0.0
Frontend Component Test Generator
Generate component tests for **existing components** — typically components written without tests, or where additional coverage is needed beyond what `frontend-component` already produced.
> **When to use this vs. `frontend-component`**: `frontend-component` generates tests as part of creating a new component. Use `frontend-test` when the component already exists and you need to add or expand its tests.
When to Invoke
Auto-invoke when user says:
- "Test this component"
- "Write component test"
- "Add component test"
- "Test component [name]"
- "Component tests for [name]"
Execution Steps
Step 0: Check Existing Patterns (Phase 0)
PLUGIN_DIR="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude/plugins/cache/navigator-marketplace/navigator}"
[ -d "$PLUGIN_DIR" ] || 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
python3 "$PLUGIN_DIR/skills/nav-graph/functions/graph_manager.py" \
--action query --concept testing \
--graph-path .agent/knowledge/graph.json 2>/dev/null | head -40Look for patterns about test utilities used (RTL vs Enzyme), snapshot policy, accessibility-test conventions.
Step 1: Locate Component Under Test
Ask if not specified:
Which component should I test?
- File path (e.g., src/components/UserProfile.tsx)
- Component name (e.g., UserProfile)
Read the component in full so generated tests cover actual behavior (props handled, events emitted, conditional rendering, etc.).
Step 2: Detect Test Framework + Library
# React Testing Library
grep -q '"@testing-library/react"' package.json 2>/dev/null && echo "RTL detected"
# Vue Test Utils
grep -q '"@vue/test-utils"' package.json 2>/dev/null && echo "Vue Test Utils detected"
# Test runner
grep -q '"vitest"' package.json 2>/dev/null && echo "Vitest"
grep -q '"jest"' package.json 2>/dev/null && echo "Jest"
Check for `setupTests.ts` / `vitest.setup.ts` to understand global utilities and matchers.
Step 3: Generate Test File
**File location**: colocate with the component (`UserProfile.test.tsx` next to `UserProfile.tsx`) unless the project convention is otherwise.
**Structure (RTL + Vitest/Jest)**:
import { describe, it, expect, vi } from 'vitest'; // or '@jest/globals'
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { {COMPONENT_NAME} } from './{COMPONENT_NAME}';
describe('{COMPONENT_NAME}', () => {
describe('rendering', () => {
it('renders with required props', () => {
render(<{COMPONENT_NAME} {...{REQUIRED_PROPS}} />);
expect(screen.getByRole('{ROLE}')).toBeInTheDocument();
});
it('renders conditional content when prop is set', () => {
render(<{COMPONENT_NAME} {...{REQUIRED_PROPS}} {OPTIONAL_PROP} />);
expect(screen.getByText('{EXPECTED_TEXT}')).toBeInTheDocument();
});
});
describe('interactions', () => {
it('calls onClick handler when clicked', async () => {
const user = userEvent.setup();
const onClick = vi.fn();
render(<{COMPONENT_NAME} {...{REQUIRED_PROPS}} onClick={onClick} />);
await user.click(screen.getByRole('button'));
expect(onClick).toHaveBeenCalledOnce();
});
});
describe('accessibility', () => {
it('has accessible name', () => {
render(<{COMPONENT_NAME} {...{REQUIRED_PROPS}} />);
expect(screen.getByRole('{ROLE}')).toHaveAccessibleName();
});
});
});**Snapshot tests**: only generate if the project's existing tests use them (check peer test files first). They're easy to over-rely on; prefer assertion-based tests for behavior, snapshots only for stable visual structure.
Step 4: Verify
{TEST_COMMAND} {COMPONENT_NAME}If tests fail because they assume incorrect behavior, fix the tests. Only fix the component if it's actually buggy — surface that to the user.
Step 5: Emit Execution Summary (Graph Ingestion)
{
"execution_summary": {
"skill": "frontend-test",
"task": "tests for {COMPONENT_NAME}",
"files_created": ["{test file path}"],
"files_modified": [],
"tests_added": ["{test file path}"],
"stack_detected": "{e.g. react+rtl+vitest}",
"patterns_followed": [
{"summary": "{e.g. queries via getByRole, not getByTestId}", "concepts": ["frontend", "testing"], "confidence": 0.85}
],
"decisions_made": [
{"summary": "{e.g. asserted accessible name instead of snapshot to avoid brittleness}", "concepts": ["testing"], "confidence": 0.8}
],
"pitfalls_avoided": [
{"summary": "{e.g. used userEvent.setup() not fireEvent — RTL recommendation}", "concepts": ["testing"], "confidence": 0.85}
],
"assumptions_made": ["{e.g. project uses Vitest globals from setup file}"]
}
}Ingest:
PLUGIN_DIR="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude/plugins/cache/navigator-marketplace/navigator}"
[ -d "$PLUGIN_DIR" ] || PLUGIN_DIR="$HOME/.claude/plugins/marketplaces/navigator-marketplace"
echo '<execution_summary JSON>' | python3 "$PLUGIN_DIR/skills/nav-graph/functions/execution_to_graph.py" -Success Criteria
- [ ] Test file colocated with component (or per project convention)
- [ ] Rendering, interactions, and at least one accessibility check covered
- [ ] Queries use `getByRole` / `getByLabelText` over `getByTestId` where possible
- [ ] All generated tests pass on first run
- [ ] Execution summary emitted
When NOT to Use This Skill
- You're cre
Read more
name: frontend-test description: Generate frontend component tests (React Testing Library, Vue Test Utils, snapshot) for existing components. Auto-invoke when user says "test this component", "write component test", or "add component test". allowed-tools: Read, Write, Edit, Grep, Glob, Bash version: 2.0.0
Frontend Component Test Generator
Generate component tests for **existing components** — typically components written without tests, or where additional coverage is needed beyond what `frontend-component` already produced.
> **When to use this vs. `frontend-component`**: `frontend-component` generates tests as part of creating a new component. Use `frontend-test` when the component already exists and you need to add or expand its tests.
When to Invoke
Auto-invoke when user says:
- "Test this component"
- "Write component test"
- "Add component test"
- "Test component [name]"
- "Component tests for [name]"
Execution Steps
Step 0: Check Existing Patterns (Phase 0)
PLUGIN_DIR="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude/plugins/cache/navigator-marketplace/navigator}"
[ -d "$PLUGIN_DIR" ] || 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
python3 "$PLUGIN_DIR/skills/nav-graph/functions/graph_manager.py" \
--action query --concept testing \
--graph-path .agent/knowledge/graph.json 2>/dev/null | head -40Look for patterns about test utilities used (RTL vs Enzyme), snapshot policy, accessibility-test conventions.
Step 1: Locate Component Under Test
Ask if not specified:
Which component should I test? - File path (e.g., src/components/UserProfile.tsx) - Component name (e.g., UserProfile)
Read the component in full so generated tests cover actual behavior (props handled, events emitted, conditional rendering, etc.).
Step 2: Detect Test Framework + Library
# React Testing Library grep -q '"@testing-library/react"' package.json 2>/dev/null && echo "RTL detected" # Vue Test Utils grep -q '"@vue/test-utils"' package.json 2>/dev/null && echo "Vue Test Utils detected" # Test runner grep -q '"vitest"' package.json 2>/dev/null && echo "Vitest" grep -q '"jest"' package.json 2>/dev/null && echo "Jest"
Check for `setupTests.ts` / `vitest.setup.ts` to understand global utilities and matchers.
Step 3: Generate Test File
**File location**: colocate with the component (`UserProfile.test.tsx` next to `UserProfile.tsx`) unless the project convention is otherwise.
**Structure (RTL + Vitest/Jest)**:
import { describe, it, expect, vi } from 'vitest'; // or '@jest/globals'
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { {COMPONENT_NAME} } from './{COMPONENT_NAME}';
describe('{COMPONENT_NAME}', () => {
describe('rendering', () => {
it('renders with required props', () => {
render(<{COMPONENT_NAME} {...{REQUIRED_PROPS}} />);
expect(screen.getByRole('{ROLE}')).toBeInTheDocument();
});
it('renders conditional content when prop is set', () => {
render(<{COMPONENT_NAME} {...{REQUIRED_PROPS}} {OPTIONAL_PROP} />);
expect(screen.getByText('{EXPECTED_TEXT}')).toBeInTheDocument();
});
});
describe('interactions', () => {
it('calls onClick handler when clicked', async () => {
const user = userEvent.setup();
const onClick = vi.fn();
render(<{COMPONENT_NAME} {...{REQUIRED_PROPS}} onClick={onClick} />);
await user.click(screen.getByRole('button'));
expect(onClick).toHaveBeenCalledOnce();
});
});
describe('accessibility', () => {
it('has accessible name', () => {
render(<{COMPONENT_NAME} {...{REQUIRED_PROPS}} />);
expect(screen.getByRole('{ROLE}')).toHaveAccessibleName();
});
});
});**Snapshot tests**: only generate if the project's existing tests use them (check peer test files first). They're easy to over-rely on; prefer assertion-based tests for behavior, snapshots only for stable visual structure.
Step 4: Verify
{TEST_COMMAND} {COMPONENT_NAME}If tests fail because they assume incorrect behavior, fix the tests. Only fix the component if it's actually buggy — surface that to the user.
Step 5: Emit Execution Summary (Graph Ingestion)
{
"execution_summary": {
"skill": "frontend-test",
"task": "tests for {COMPONENT_NAME}",
"files_created": ["{test file path}"],
"files_modified": [],
"tests_added": ["{test file path}"],
"stack_detected": "{e.g. react+rtl+vitest}",
"patterns_followed": [
{"summary": "{e.g. queries via getByRole, not getByTestId}", "concepts": ["frontend", "testing"], "confidence": 0.85}
],
"decisions_made": [
{"summary": "{e.g. asserted accessible name instead of snapshot to avoid brittleness}", "concepts": ["testing"], "confidence": 0.8}
],
"pitfalls_avoided": [
{"summary": "{e.g. used userEvent.setup() not fireEvent — RTL recommendation}", "concepts": ["testing"], "confidence": 0.85}
],
"assumptions_made": ["{e.g. project uses Vitest globals from setup file}"]
}
}Ingest:
PLUGIN_DIR="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude/plugins/cache/navigator-marketplace/navigator}"
[ -d "$PLUGIN_DIR" ] || PLUGIN_DIR="$HOME/.claude/plugins/marketplaces/navigator-marketplace"
echo '<execution_summary JSON>' | python3 "$PLUGIN_DIR/skills/nav-graph/functions/execution_to_graph.py" -Success Criteria
- [ ] Test file colocated with component (or per project convention)
- [ ] Rendering, interactions, and at least one accessibility check covered
- [ ] Queries use `getByRole` / `getByLabelText` over `getByTestId` where possible
- [ ] All generated tests pass on first run
- [ ] Execution summary emitted
When NOT to Use This Skill
- You're cre
Finish What You Start Sessions that last. AI that learns. Features that ship.
Repo: alekspetrov/navigator
Other skills on navigator.
- /backend-endpoint
Create REST/GraphQL API endpoint with validation, error handling, and tests. Auto-invoke when user says "add endpoint", "create API", "new route", or "add route".
Open skill - /backend-test
Generate backend tests (unit, integration, mocks) for existing code. Auto-invoke when user says "write test for", "add test", "test this", or "create test".
Open skill - /database-migration
Create database migration with schema changes and rollback. Auto-invoke when user says "create migration", "add table", "modify schema", or "change database".
Open skill - /frontend-component
Create React/Vue component with TypeScript, tests, and styles. Auto-invoke when user says "create component", "add component", "new component", or "build component".
Open skill - /nav-brief
Render a one-screen intent brief (Goal/Scope/Approach/Limits/Verify/Won't-do) before implementing ambiguous task-shaped prompts, triggered by the nav_brief.py UserPromptSubmit hook. Confirms scope with max 2 open questions before touching files; detects brief drift mid-task.
Open skill - /nav-compact
Clear conversation context while preserving knowledge via context marker. Use when user says "clear context", "start fresh", "done with this task", or when approaching token limits.
Open skill

