vercel-composition-patterns

Overview of vercel-composition-patterns skill

vercel-composition-patterns is a React architecture skill for choosing composition over prop-heavy component APIs. It is best for frontend engineers, design-system authors, and AI-assisted refactoring tasks where the real job is to reduce boolean prop sprawl, clarify component boundaries, and make reusable APIs easier to extend without breaking callers.

The main value of the vercel-composition-patterns skill is decision support: it helps you decide when to use compound components, lifted state, explicit variants, children composition, or React 19-specific APIs instead of forcing everything through a single configurable component.

Best fit for frontend component design

Use vercel-composition-patterns for Frontend Development when you are:

• refactoring a component with too many booleans or mode flags
• building a reusable UI kit or product component library
• reviewing whether a component API is too rigid or too magical
• moving shared UI state into a provider or context shape
• updating code for React 19 changes such as avoiding forwardRef

What makes it useful in practice

This skill is opinionated in a way that is useful for agents: it gives priority to architecture rules first, then state, then implementation patterns. That order matters when you need a solution that scales, not just a local patch.

When it is a good install decision

Install vercel-composition-patterns if you want guidance that is closer to an architecture rubric than a generic React prompt. Skip it if you only need a one-off component snippet with no concern for API design, reuse, or long-term maintenance.

How to Use vercel-composition-patterns skill

Install the skill and confirm the rule set

Use the vercel-composition-patterns install flow for the directory’s standard skill manager, then verify the repository path is skills/composition-patterns. This skill has no install script; the value is in the rule files and their ordering, not in generated code.

Start from the decision rule, not the implementation

The most effective vercel-composition-patterns usage is to give the model the component problem first, not the desired code shape. Example input:

• “Refactor this Composer component with isThread, isDMThread, and isEditing into a composition-based API.”
• “Design a compound component API for a settings panel that shares selection state across subcomponents.”
• “Review this UI library component and suggest whether it should become explicit variants or compound components.”

Read the files that control output quality

For a strong vercel-composition-patterns guide, inspect these first:

• SKILL.md for the high-level intent and when-to-apply guidance
• AGENTS.md for the compiled rule hierarchy and preferred patterns
• rules/_sections.md to understand category priority
• rules/architecture-avoid-boolean-props.md
• rules/architecture-compound-components.md
• rules/react19-no-forwardref.md

Give context that changes the architecture choice

Good inputs include:

• current props and state shape
• whether consumers need customization or only a few fixed modes
• which subparts must share state
• whether React 19 is in scope
• whether backward compatibility matters

Weak input: “Make this component better.”
Stronger input: “This component has 6 boolean props, 3 modes, and a shared submit state. Propose a compound-component API that keeps public usage simple and moves internal branching into context.”

vercel-composition-patterns skill FAQ

Is vercel-composition-patterns only for large codebases?

No. It is most valuable in larger or reusable component systems, but it also helps on smaller components when the API is already becoming hard to reason about. The signal is not size alone; it is whether the component is starting to encode behavior through props instead of structure.

How is this different from a normal React prompt?

A normal prompt may give you a plausible component. vercel-composition-patterns pushes the model to justify the API shape, prioritize architecture rules, and avoid common regressions like boolean prop proliferation or overusing render props.

Is it suitable for beginners?

Yes, if the goal is learning good component boundaries. It is less beginner-friendly if you want a quick copy-paste solution with no explanation of tradeoffs. The skill is better when you are willing to compare designs before coding.

When should I not use it?

Do not use vercel-composition-patterns for quick styling tasks, trivial one-off components, or cases where the API is already fixed and cannot change. It is strongest when the main risk is a bad abstraction, not when the main need is just implementation speed.

How to Improve vercel-composition-patterns skill

Provide the existing API shape

The biggest quality jump comes from showing the current component signature, especially booleans, variant props, callbacks, and shared state. The skill can only recommend better composition if it can see what is being over-configured.

State the desired consumer experience

Tell the model how you want the component to feel from the outside:

• “Consumers should assemble the UI from subcomponents.”
• “Only three variants should be public.”
• “Internal state should stay hidden behind a provider.”

This improves vercel-composition-patterns usage because the best pattern depends on the intended public API, not just the internal refactor.

Ask for a pattern recommendation before code

A strong workflow is: ask for the architecture choice, then ask for the implementation. For example:

1. “Should this be compound components, explicit variants, or children composition?”
2. “Now rewrite it using the chosen pattern.”

That two-step approach reduces premature code generation and makes the vercel-composition-patterns skill more reliable.

Watch for the common failure modes

The main failure modes are:

• replacing booleans with equally opaque magic props
• turning every component into a compound component even when a variant API is simpler
• moving state to context without clarifying the state/actions/meta interface
• using forwardRef in React 19-sensitive code

If your first output feels too abstract, tighten the brief with constraints: target React version, compatibility limits, and whether the public API must stay stable.