Menu
Analyze SCSS folders and propose a complete refactor plan (architecture, tokens, conventions, migration steps). Read-only: no file edits.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Clean and manage i18n locale files. Validates keys, finds missing/unused translations, syncs locales, removes dead keys, checks parameter consistency, finds hardcoded strings in code, and triggers AI translation via Ollama. Use when working with translations, cleaning locale files, auditing i18n coverage, or finding untranslated hardcoded strings. Triggers on requests to check translations, clean i18n, sync locales, translate, audit i18n, find missing keys, remove unused keys, or find hardcoded strings.
Analyze repository architecture to identify structural slop in TypeScript/JavaScript codebases. Use when reviewing folder structure, finding over-engineering, reducing complexity, or cleaning up project organization. Detects excessive directory depth, single-file folders, barrel files, empty directories, enterprise layer smell, mirrored structures, and scattered types/utils. Triggers on requests to analyze architecture, review project structure, find layering issues, or simplify codebase organization.
Find duplicate business logic (copy/paste blocks + structurally similar functions). Works best on TS/JS projects. Produces a proof-based refactor report.
Compare two git branches and produce a structured change report (no merge strategy). Includes file/commit summaries, key diffs, and risk hotspots.
| name | scss-refactor-planner |
| description | Analyze SCSS folders and propose a complete refactor plan (architecture, tokens, conventions, migration steps). Read-only: no file edits. |
Run:
/scss-refactor-planner <path>
Examples:/scss-refactor-planner src/styles/scss-refactor-planner apps/web/src/styles/scss-refactor-planner . (not recommended if repo is huge)If no argument is provided:
ls -1)If $ARGUMENTS is empty:
ls -1Verify path exists:
test -e "$ARGUMENTS" && echo "OK: $ARGUMENTS" || echo "ERROR: path not found: $ARGUMENTS"If missing:
Define SCOPE = $ARGUMENTS.
node_modules, dist, build, .git, coverage.find "$ARGUMENTS" -type f -name "*.scss" | wc -lfind "$ARGUMENTS" -type f -name "*.scss" | head -n 80Look for:
@use / @forward (modern Sass modules)@import (legacy)Commands:
rg -n "@use\\b|@forward\\b|@import\\b" "$ARGUMENTS" | head -n 200rg -n "@import\\b" "$ARGUMENTS" | head -n 200rg -n "@use\\b|@forward\\b" "$ARGUMENTS" | head -n 200$color, $space, $font, $z-@mixin, %placeholderreset, normalize, base, typography.u-, .is-, .has-Commands:
rg -n "\\$[a-zA-Z0-9_-]+" "$ARGUMENTS" | head -n 200rg -n "@mixin\\b|@include\\b" "$ARGUMENTS" | head -n 200rg -n "^%[a-zA-Z0-9_-]+" "$ARGUMENTS" | head -n 200rg -n "\\.(u-|is-|has-)" "$ARGUMENTS" | head -n 200Find deeply nested selectors (rough signal: many { before }).
rg -n "\\{" "$ARGUMENTS" | head -n 1 (sanity)Heuristic: search for selectors with many spaces + & or long chains:
rg -n "(&\\.|\\s{2,}\\.[a-zA-Z0-9_-]+\\s+\\.[a-zA-Z0-9_-]+\\s+\\.[a-zA-Z0-9_-]+)" "$ARGUMENTS" | head -n 200rg -n "!important" "$ARGUMENTS" | head -n 200rg -n "#[a-zA-Z0-9_-]+" "$ARGUMENTS" | head -n 120rg -n "#[0-9a-fA-F]{3,8}\\b|rgb\\(|rgba\\(|hsl\\(|hsla\\(" "$ARGUMENTS" | head -n 200rg -n "(:|\\s)([0-9]+)(px|rem|em)\\b" "$ARGUMENTS" | head -n 200rg -n "z-index\\s*:\\s*[0-9]+" "$ARGUMENTS" | head -n 120rg -n "^\\.[a-zA-Z0-9_-]+" "$ARGUMENTS" | head -n 200@import vs @use)Pick the best fit for the repo and explain tradeoffs:
Provide a proposed folder tree and naming conventions.
_tokens.scss, _mixins.scss, _functions.scssInclude example token naming rules (no need to rewrite the whole codebase, just show the pattern).
Define:
Must be incremental:
@use/@forward strategy (if needed)Each step should include:
List the highest ROI targets with evidence:
Do NOT implement changes. Only plan, examples, and guidance.