page-driven-development

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".

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "page-driven-development" with this command: npx skills add fuxingloh/skills/fuxingloh-skills-page-driven-development

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 useState calls 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 useState in page root
  • Shared components truly share context, not just appearance

When Writing New Code

  1. Start in the page directory
  2. Extract components only when the page file grows unwieldy
  3. Keep extracted components in the same directory
  4. Only promote to global when genuinely reused with same context

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Coding

frontend-design

Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.

Repository SourceNeeds Review
170.1K96Kanthropics
Coding

remotion-best-practices

Use this skills whenever you are dealing with Remotion code to obtain the domain-specific knowledge.

Repository SourceNeeds Review
153.9K2.2Kremotion-dev
Coding

azure-ai

Service Use When MCP Tools CLI

Repository SourceNeeds Review
139.4K157microsoft
Coding

azure-deploy

AUTHORITATIVE GUIDANCE — MANDATORY COMPLIANCE

Repository SourceNeeds Review
138.9K157microsoft