component-api-designlisted

# Component API design `prop-analyzer` measures an existing API. This skill decides a new one. The governing fact: **once twenty files call it, changing it is a migration**, so this is the highest-leverage design decision in a frontend feature. ## First, check what the repo already does ```bash lazysitter fe-index precedent "<category>" --kind component lazysitter fe-index props <SiblingComponent> ``` A compound component in a prop-bag codebase is inconsistent even when it is better. Match the repo's axis unless you have a reason to change it — and a reason to change one component's axis is usually a reason to change the convention, which is a bigger conversation. ## Configuration vs composition **Configuration** — the component takes props describing what to render: ```jsx <Card title="X" subtitle="Y" headerIcon={<Icon/>} headerAction={<Button/>} footer={<Links/>} /> ``` Scales to the cases you predicted. When a prop family grows a fourth member (`headerIcon`, `headerBadge`, `headerAction`, `headerMenu`), it is telling you it has outgrown the axis. **Composition** — the component provides structure, the caller provides content: ```jsx <Card> <Card.Header><Icon/><Card.Title>X</Card.Title><Button/></Card.Header> <Card.Body>…</Card.Body> </Card> ``` Scales to the cases you did not predict, at the cost of more API surface to learn and weaker constraints on what callers can put where. **Choose configuration** for a small, closed set of variations where you want to *pre