component-extraction-judgment
Installation
SKILL.md
Component extraction judgment
Use before refactoring generated or organically grown frontend UI into shared components — the goal is not "deduplicate everything" but choosing the reuse boundary that preserves product semantics, design fidelity, accessibility contracts, and testability.
Evidence tiers
| Tier | Claim allowed | Evidence required |
|---|---|---|
| T1 | Safe extraction candidate | Two or more concrete source locations, same user-facing semantics, same accessibility role/name/state contract, same design variant axis, and a targeted regression test path. Optional framework-specific duplicate scanners may support the finding, but the final decision still needs code evidence. |
| T2 | Plausible extraction candidate | Similar structure and props are visible, but one contract dimension still needs confirmation (design token, responsive state, copy/i18n, loading/empty state, focus behavior, or data shape). |
| T3 | Smell only | Duplication is suspected from names, screenshots, or token overlap, but source locations or contracts are not confirmed. Do not edit yet. |
| T4 | Blocked / not judged | Missing source, missing design authority, generated bundle only, no safe test path, or the change would require product/API decisions. |
Only T1 is implemented as a refactor. T2/T3 become a cleanup plan or TODO with the explicit missing evidence; T4 is reported as blocked with the specific missing input, not edited.