
Vercel Composition Patterns
Guide your coding agent through React UI work so new and refactored components use compound composition instead of growing boolean prop matrices.
Overview
Vercel Composition Patterns is an agent skill most often used in Build (also Ship, Operate) that teaches compound components, lifted provider state, and explicit variants so React UIs avoid boolean prop proliferation.
Install
npx skills add https://github.com/vercel-labs/agent-skills --skill vercel-composition-patternsWhat is this skill?
- Compound components and explicit variants to replace boolean prop proliferation
- Lift state into providers and generic context interfaces for testable, agent-friendly APIs
- Prefer children composition over render-prop tangles for scalable internals
Adoption & trust: 204k installs on skills.sh; 27.7k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your React components keep gaining boolean flags and intertwined props, so every new variant breaks agents and humans alike.
Who is it for?
Solo builders shipping React or Next.js products who want agent-assisted refactors and new UI to follow scalable composition rules from day one.
Skip if: Non-React stacks, pure CSS-only tweaks, or teams that only need marketing copy without touching component architecture.
When should I use this skill?
When maintaining, generating, or refactoring React codebases to follow composition patterns and avoid boolean prop proliferation.
What do I get? / Deliverables
You get a consistent composition playbook—compound parts, providers, and explicit variants—that makes generated and hand-written React code easier to extend and refactor.
- Refactored compound component trees with explicit variants
- Provider-wrapped state boundaries decoupled from presentational children
- Review-ready UI modules without new boolean prop surface area
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Composition architecture is decided while you design and implement UI; Build is the canonical shelf even though the same patterns apply during review and long-term refactors. The skill is entirely about React component structure, state lifting, and compound APIs—core frontend engineering, not backend or distribution work.
Where it fits
Scaffold a new dashboard shell using compound Header, Body, and Footer pieces instead of a single component with twelve optional booleans.
Generate a multi-step form where each step is a child component under a shared provider that owns navigation state.
Review a PR from your agent and reject patterns that add isLoading, isError, and isCompact flags when explicit variants or composition would suffice.
Refactor a settings page that grew six mode props into lifted provider state before shipping another integration toggle.
How it compares
Use instead of ad-hoc “add another boolean prop” chat refactors when you want procedural frontend architecture guidance, not a UI kit or MCP integration.
Common Questions / FAQ
Who is vercel-composition-patterns for?
Indie and solo developers using Claude Code, Cursor, or similar agents to build or maintain React and Next.js frontends who care about long-term component APIs.
When should I use vercel-composition-patterns?
During Build when scaffolding or extending UI; during Ship review when auditing agent-generated components for prop sprawl; and during Operate iteration when refactoring legacy screens before adding features.
Is vercel-composition-patterns safe to install?
It is documentation-style procedural knowledge with no runtime hooks; review the Security Audits panel on this Prism page and the skill package source on skills.sh before trusting any third-party install path.
SKILL.md
READMESKILL.md - Vercel Composition Patterns
# React Composition Patterns **Version 1.0.0** Engineering January 2026 > **Note:** > This document is mainly for agents and LLMs to follow when maintaining, > generating, or refactoring React codebases using composition. Humans > may also find it useful, but guidance here is optimized for automation > and consistency by AI-assisted workflows. --- ## Abstract Composition patterns for building flexible, maintainable React components. Avoid boolean prop proliferation by using compound components, lifting state, and composing internals. These patterns make codebases easier for both humans and AI agents to work with as they scale. --- ## Table of Contents 1. [Component Architecture](#1-component-architecture) — **HIGH** - 1.1 [Avoid Boolean Prop Proliferation](#11-avoid-boolean-prop-proliferation) - 1.2 [Use Compound Components](#12-use-compound-components) 2. [State Management](#2-state-management) — **MEDIUM** - 2.1 [Decouple State Management from UI](#21-decouple-state-management-from-ui) - 2.2 [Define Generic Context Interfaces for Dependency Injection](#22-define-generic-context-interfaces-for-dependency-injection) - 2.3 [Lift State into Provider Components](#23-lift-state-into-provider-components) 3. [Implementation Patterns](#3-implementation-patterns) — **MEDIUM** - 3.1 [Create Explicit Component Variants](#31-create-explicit-component-variants) - 3.2 [Prefer Composing Children Over Render Props](#32-prefer-composing-children-over-render-props) 4. [React 19 APIs](#4-react-19-apis) — **MEDIUM** - 4.1 [React 19 API Changes](#41-react-19-api-changes) --- ## 1. Component Architecture **Impact: HIGH** Fundamental patterns for structuring components to avoid prop proliferation and enable flexible composition. ### 1.1 Avoid Boolean Prop Proliferation **Impact: CRITICAL (prevents unmaintainable component variants)** Don't add boolean props like `isThread`, `isEditing`, `isDMThread` to customize component behavior. Each boolean doubles possible states and creates unmaintainable conditional logic. Use composition instead. **Incorrect: boolean props create exponential complexity** ```tsx function Composer({ onSubmit, isThread, channelId, isDMThread, dmId, isEditing, isForwarding, }: Props) { return ( <form> <Header /> <Input /> {isDMThread ? ( <AlsoSendToDMField id={dmId} /> ) : isThread ? ( <AlsoSendToChannelField id={channelId} /> ) : null} {isEditing ? ( <EditActions /> ) : isForwarding ? ( <ForwardActions /> ) : ( <DefaultActions /> )} <Footer onSubmit={onSubmit} /> </form> ) } ``` **Correct: composition eliminates conditionals** ```tsx // Channel composer function ChannelComposer() { return ( <Composer.Frame> <Composer.Header /> <Composer.Input /> <Composer.Footer> <Composer.Attachments /> <Composer.Formatting /> <Composer.Emojis /> <Composer.Submit /> </Composer.Footer> </Composer.Frame> ) } // Thread composer - adds "also send to channel" field function ThreadComposer({ channelId }: { channelId: string }) { return ( <Composer.Frame> <Composer.Header /> <Composer.Input /> <AlsoSendToChannelField id={channelId} /> <Composer.Footer> <Composer.Formatting /> <Composer.Emojis /> <Composer.Submit /> </Composer.Footer> </Composer.Frame> ) } // Edit composer - different footer actions function EditComposer() { return ( <Composer.Frame> <Composer.Input /> <Composer.Footer> <Composer.Formatting /> <Composer.Emojis /> <Composer.CancelEdit /> <Composer.SaveEdit /> </Composer.Footer> </Composer.Frame> ) } ``` Each variant is explicit about what it renders. We can share internals without sharing a single monolithic parent. ### 1.2 Use Compound Components **Impact: