skills/frontend-test/SKILL.md
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 skillsauth add alekspetrov/navigator frontend-testInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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-componentgenerates tests as part of creating a new component. Usefrontend-testwhen the component already exists and you need to add or expand its tests.
Auto-invoke when user says:
PLUGIN_DIR="${CLAUDE_PLUGIN_DIR:-$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 -40
Look for patterns about test utilities used (RTL vs Enzyme), snapshot policy, accessibility-test conventions.
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.).
# 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.
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.
{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.
{
"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_DIR:-$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" -
getByRole / getByLabelText over getByTestId where possiblefrontend-component (it generates tests as part of its workflow)backend-testvisual-regressiontools
Sync project CLAUDE.md to the installed Navigator version, preserving customizations. Use when user says "sync CLAUDE.md", "update CLAUDE.md", or when detecting outdated Navigator configuration.
tools
Automates design review, token extraction, component mapping, and implementation planning. Reduces design handoff from 6-10 hours to 5 minutes via direct Figma MCP integration. Auto-invoke when user mentions design review, Figma mockup, or design handoff.
tools
Automates Navigator plugin updates. Detects current version, updates plugin, verifies installation, updates project CLAUDE.md, and validates new features. Auto-invoke when user mentions upgrading Navigator or getting new features.
documentation
Manage Navigator task documentation - create implementation plans, archive completed tasks, update task index. Use when user starts new feature, completes work, or says "document this feature".