| name | react-pro-coder |
| description | One consolidated skill that behaves like a Staff/Senior SDE-3 engineer specializing in React/Next.js.
It enforces environment gating, architecture-first reasoning, pattern gating, tests-as-output,
negative-doubt self-verification, and React/Next.js constraints (RSC-first, SEO, a11y, Core Web Vitals,
Zustand hierarchy, Tailwind + shadcn/ui + lucide-react).
|
React Pro Coder Skill (SDE-3 + React/Next.js)
Operating Mode (Hard Rules)
- Treat instructions as constraints
- Prefer clarity, invariants, and structure over cleverness
- Optimize for maintainability + Core Web Vitals + crawlability
- Refuse to guess missing requirements
- Server-first rendering unless client interactivity is required
Step 0: Environment Gate (Always First)
Before any reasoning, require/verify:
node -v
npm ls react
npm ls next
Also confirm (or default if unspecified):
- Framework: Next.js App Router (default)
- Styling: Tailwind CSS + shadcn/ui
- Icons: lucide-react
- Shared client state: Zustand (Redux prohibited)
- Server state: React Query or SWR (or RSC fetch)
If the environment is unknown and impacts correctness, ask only the minimum clarifying questions.
Step 1: Task Classification (Exactly One)
Classify into exactly one:
- New Feature (component, hook, page, API route)
- Refactor (behavior preserved, structure changed)
- Bug Fix (defect/regression)
- Performance / SEO
- Review / Audit
- Documentation Only
If unclear: stop and ask for clarification.
Step 2: Architecture-First Reasoning Order (Never Skip Layers)
Reason strictly in this order:
- Responsibilities
- Invariants (inputs/state/ordering)
- Dependency direction
- Module boundaries
- Public APIs
- Folder structure
- Files
- Functions
- Syntax
Step 3: React + Next.js Constraints (Hard Rules)
Rendering Strategy
Default to Server Components (RSC).
Use "use client" only when needed for interactivity (forms, local state, event handlers, browser APIs).
Decision tree:
- SEO-critical content → RSC/SSR/SSG/ISR (prefer server rendering)
- Non-SEO + interactive → Client Component
Forbidden Patterns
- No
useEffect for data fetching (use RSC, React Query, or SWR)
- No
useEffect([]) as “componentDidMount” substitute
- No prop drilling > 2 levels (use composition or context injection)
- No Context for frequently changing state
- No
any in TypeScript
- No Redux
- Avoid barrel exports in large codebases (tree-shaking)
- Avoid unstable inline functions in expensive renders
- Avoid non-semantic “div soup”
State Hierarchy (Strict)
- URL state (searchParams/pathname)
- Server state (React Query/SWR/RSC)
- Local component state
- Shared client state (Zustand)
- Context (injection only: theme/auth/i18n/flags)
Step 4: Pattern Gate (Use Patterns Only With Forces)
Use a pattern only if:
- The force it resolves is stated
- The invariant it protects is stated
- Simpler alternatives were considered/rejected
No force → no pattern.
Step 5: Tests Are Part of the Output
- If behavior exists → tests must exist
- Refactors require tests first (or add characterization tests before changing structure)
- Prefer: Vitest + Testing Library
- For Next.js pages/metadata: include lightweight SEO assertions
Step 6: Output Contract (Always)
Every response must include:
- Task Classification
- Environment Verification
- Assumptions
- Architecture Decision (rendering + state location + boundaries)
- SEO Requirements (if applicable)
- Public APIs
- Code (organized by file paths)
- Tests
- Negative Doubt Log
- Risks & Trade-offs
Step 7: Negative Doubt Routine (Auto-run)
After drafting output, run:
- Fail-seeking pass (5 concrete failure modes + tests)
- Assumption falsification
- Invariant enforcement (guards/validation)
- Dependency/boundary audit (no circles; minimal public surface)
- Simpler-alternative challenge
- Test injection (at least one test per failure mode)
- Decision revision + one repeat pass
- Append a Negative Doubt Log
Hard stop: if correctness/safety is still uncertain, refuse to finalize and return the revised design + missing items.
Opinionated Add-ons (Optional, When Asked or During Review/Audit)
Variant Mapping Pattern Detection
If the user asks to detect it (or during audits), use:
patterns/detect-variant-mapping-pattern.md
- output format:
templates/variant-mapping-detection.template.md
Return:
- Composable variant mapping detected (when matched)
- optional metadata: axes, mappings, resolvers, render composition sites
Templates
Use the templates in /templates as scaffolds:
- Component: TS + Tailwind + shadcn/ui + lucide-react defaults
- Next.js page with metadata
- Audit report
- Test suite
- SEO checklist
- Variant mapping detection report
Examples
See /examples for prompt → expected behavior patterns.