Review and write React/Next.js code following Page Driven Development principles. Use when organizing components, making file structure decisions, or asked to "review structure", "organize code", "refactor components", or "follow PDD".
Page Driven Development (PDD)
Core Principle
Code should be organized by context, not by technology or false separation of concerns. Components belong near the pages that use them, not in global shared directories.
Guidelines
1. Colocate Components with Pages
Place components in the same directory as the page that uses them:
app/
dashboard/
page.tsx
dashboard-header.tsx # Only used by dashboard
dashboard-stats.tsx # Only used by dashboard
settings/
page.tsx
settings-form.tsx # Only used by settings
NOT in a global components folder:
# Avoid this pattern
components/
DashboardHeader.tsx
DashboardStats.tsx
SettingsForm.tsx
2. Avoid False Separation of Concerns
Do not abstract components globally just because they "could" be reused. A component used in multiple pages with vastly different contexts creates tangled coupling.
Ask yourself:
- Is this component actually used in multiple places right now?
- Do those places share the same context/narrative?
- Will changes to one usage break the other?
If the contexts differ, keep separate implementations.
3. Decompose Pages into Manageable Components
PDD does not mean monolithic pages. Decompose naturally:
- More than 10
useStatecalls in a component is a code smell - Avoid prop-drilling through many layers
- Avoid type assertions that hide complexity
- Create natural hierarchies within the page directory
4. Global Components Are Exceptions
Only create truly global components for:
- Primitives with no business logic (Button, Input, Modal shell)
- Layout wrappers used across all pages
- Design system tokens/utilities
5. Embrace Duplication Over Wrong Abstraction
It's better to have similar code in two places than a fragile abstraction that serves neither well. Duplication is cheaper than the wrong abstraction.
When Reviewing Code
Check for:
- [ ] Components are colocated with their pages
- [ ] No unnecessary global component abstractions
- [ ] Page components are decomposed (not monolithic)
- [ ] No prop-drilling or excessive
useStatein page root - [ ] Shared components truly share context, not just appearance
When Writing New Code
- Start in the page directory
- Extract components only when the page file grows unwieldy
- Keep extracted components in the same directory
- Only promote to global when genuinely reused with same context
You Might Also Like
Related Skills

coding-agent
Run Codex CLI, Claude Code, OpenCode, or Pi Coding Agent via background process for programmatic control.
openclaw
add-uint-support
Add unsigned integer (uint) type support to PyTorch operators by updating AT_DISPATCH macros. Use when adding support for uint16, uint32, uint64 types to operators, kernels, or when user mentions enabling unsigned types, barebones unsigned types, or uint support.
pytorch
at-dispatch-v2
Convert PyTorch AT_DISPATCH macros to AT_DISPATCH_V2 format in ATen C++ code. Use when porting AT_DISPATCH_ALL_TYPES_AND*, AT_DISPATCH_FLOATING_TYPES*, or other dispatch macros to the new v2 API. For ATen kernel files, CUDA kernels, and native operator implementations.
pytorch
skill-writer
Guide users through creating Agent Skills for Claude Code. Use when the user wants to create, write, author, or design a new Skill, or needs help with SKILL.md files, frontmatter, or skill structure.
pytorch
implementing-jsc-classes-cpp
Implements JavaScript classes in C++ using JavaScriptCore. Use when creating new JS classes with C++ bindings, prototypes, or constructors.
oven-sh
implementing-jsc-classes-zig
Creates JavaScript classes using Bun's Zig bindings generator (.classes.ts). Use when implementing new JS APIs in Zig with JSC integration.
oven-sh