Tailwind Class Extractor

What this skill does

Scans a JSX or TSX codebase for className="..." strings that recur verbatim across many sites and extracts each pattern into a named component. The output is a refactor patch and a small components/ui module.

Inputs

• repo_dir: project root.
• Optional min_occurrences: minimum repeats to extract (default 5).
• Optional min_classes: minimum class count per pattern (default 4).
• Optional out_dir: where to write extracted components (default src/components/ui/).

Steps

1. Find candidate strings: rg -oN 'className="[^"]+"' <repo_dir> --glob '*.{jsx,tsx}'.
2. Normalize each: trim whitespace, sort the classes alphabetically, drop duplicates within a string.
3. Tally normalized strings; keep entries with count >= min_occurrences and class count >= min_classes.
4. For each kept pattern, infer the underlying element: read the original source line and capture the parent JSX tag (<button>, <div>, <a>).
5. Generate a component file per pattern:
   • Name derived from the dominant tag plus the most semantic class (e.g., <button class="bg-blue-500 ..."> -> PrimaryButton.tsx).
   • Forwards ...props and className (using clsx) so callers can override.
6. Write the new component to <out_dir>/<Name>.tsx.
7. Generate a refactor patch: for every original site, replace the <element className="...">...</element> with <NewComponent>...</NewComponent>. Preserve children and event handlers.
8. Run prettier --write and eslint --fix on changed files.
9. Run the test suite to confirm no regressions.

Output

A directory of new components plus a unified diff tailwind-extract.patch (with one hunk per replacement site). A markdown summary listing patterns extracted, counts, and approximate LOC saved.

Verification

Render a Storybook story (or a manual snapshot test) for each new component; visual output must match a representative original site. Run git grep for the extracted class string after applying the patch — count should drop near zero (some literal strings may legitimately differ in non-class contexts). If the test suite reveals broken snapshots, regenerate snapshots only after manual visual review; do not auto-accept.

Edge cases

• Class strings with conditional concatenation (clsx('a', cond && 'b')): skip; do not try to abstract conditional patterns automatically.
• Strings differing only by one or two utility classes: do not extract; the tradeoff in flexibility isn't worth it under min_classes.
• Patterns localized to a single feature folder: extract within that folder rather than globally to avoid cross-cutting coupling.
• Tailwind @apply users: prefer extracting to a CSS file with @apply instead of a component, when the project already follows that pattern.