Vercel Composition Patterns
Teach your agent compound-component and state-lifting patterns so React UIs scale without boolean prop sprawl and fragile render-prop trees.
Overview
Vercel Composition Patterns is an agent skill for the Build phase that applies React compound-component and state-lifting patterns to avoid boolean prop sprawl during generation and refactors.
Install
npx skills add https://github.com/vercel-labs/claude-skills --skill vercel-composition-patternsWhat is this skill?
- High-priority rules: avoid boolean prop proliferation; prefer compound components
- Medium-priority state patterns: decouple state from UI, generic context interfaces, lift state into providers
- Implementation patterns: explicit component variants and children composition over render props
- Optimized for AI-maintained codebases that must stay legible as feature flags multiply
- Table of contents ties each pattern to maintainability for humans and agents at scale
- Version 1.0.0 (January 2026)
- 3 topical sections: architecture, state, implementation
Adoption & trust: 283 installs on skills.sh; 27.7k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your React components accrue dozens of boolean props and tangled render props, so every agent edit risks breaking unrelated UI states.
Who is it for?
Solo builders whose agents repeatedly extend shared UI—modals, tables, wizards—where long-term readability matters more than quickest one-off patch.
Skip if: Throwaway prototypes with a single screen, or backends with no React surface where composition rules add no value.
When should I use this skill?
Maintaining, generating, or refactoring React codebases using composition when boolean props or render-prop complexity appear.
What do I get? / Deliverables
New and refactored components use compound APIs, provider-lifted state, and explicit variants that agents can extend without widening boolean prop surfaces.
- Component APIs refactored toward compound and provider patterns
- Explicit variant components instead of boolean configuration
Recommended Skills
Journey fit
Composition decisions are made while building UI primitives and feature modules—the canonical home for structural React guidance. Frontend subphase covers component architecture, providers, and variant APIs that agents generate daily in product code.
How it compares
Structural React design patterns skill—pair with performance rulebooks rather than using either alone for production UI.
Common Questions / FAQ
Who is vercel-composition-patterns for?
Indie developers and agent users building React frontends who want scalable component APIs that stay easy for automation to modify.
When should I use vercel-composition-patterns?
During Build frontend work when creating or refactoring components, especially before adding new feature flags, variants, or shared layout primitives.
Is vercel-composition-patterns safe to install?
It is prose guidance without bundled executables; confirm trust via the Security Audits panel on this Prism page and the upstream skills repository.
Workflow Chain
Then invoke: vercel react best practices
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: