← ClaudeAtlas

component-precedentlisted

Decide reuse-vs-create for a component with evidence — build a ranked precedent set from the index, detect the mid-migration case, and cite by rank. Load before creating any component, and when auditing whether a created one should have existed.
soumit-kaz/lazysitter · ★ 1 · Code & Development · score 69
Install: claude install-skill soumit-kaz/lazysitter
# Component precedent and the reuse decision ## The failure this prevents Citing *a* sibling is laundering. Six confirm-dialogs in a repo means six citable precedents, and citing the fourth is a correct, verifiable citation that still ships the seventh duplicate. A reuse rule that accepts any citation prevents nothing. The fix is a **ranked** set: find every equivalent, rank them mechanically, and require a stated reason for choosing anything other than rank 1. ## Build the set ```bash lazysitter fe-index precedent "<category>" --kind component ``` Categories are functional, not structural: `confirm dialog`, `data table`, `empty state`, `form field`, `toast`, `drawer`, `date picker`, `avatar`. Run one per category the feature needs. **Never stop at the first hit.** Widen with the shape-based queries when the name-based one is thin — the duplicates that matter are often named nothing alike: ```bash lazysitter fe-index query --props onConfirm,onCancel # by prop contract lazysitter fe-index dup --kind component # by structural similarity ``` The clustering weights prop-contract overlap highest and name similarity lowest, deliberately. `ConfirmDialog` and `AreYouSureModal` share five of six props and land in one cluster; no name search would ever connect them. ## The ranking rules (mechanical, not editorial) 1. **Dominance first** — call-site count. What the codebase actually uses is what new code should imitate. 2. **Recency second** — newest-blame