Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/mikailustuner/OmniRule --skill css-architecture명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
SOC 직업 분류 기준
| name | css-architecture |
| description | CSS organization, BEM, component patterns |
| triggers | {"extensions":[".css",".scss",".module.css",".sass"],"keywords":["CSS","BEM","SMACSS","cascade","specificity","selector","stylesheet"]} |
| auto_load_when | Editing CSS files or designing CSS structure |
| agent | style-architect |
| tools | ["Read","Write","Bash"] |
Focus: Organization, naming, component isolation
When to use CSS Modules:
├── Component-based framework → yes
├── Scoped styles needed → yes
├── Dynamic theming → consider
└── Global styles needed → separate file
When to use CSS-in-JS:
├── JS-driven theming → yes
├── Critical CSS → separate
├── Zero runtime → zero-runtime solution
└── Plain CSS preferred → use CSS files
When to use utility classes:
├── Rapid prototyping → yes
├── Design system → yes (limited set)
├── Complex components → component classes
└── Many variants → composition
When to create block:
├── Standalone component → yes
├── Reusable piece → yes
├── Layout wrapper → yes
└── Single-use → element only
When to create element:
├── Part of block → yes
├── Meaningful alone → make block
├── Always with parent → element
└── Reusable elsewhere → make block
When to create modifier:
├── Visual variant → yes
├── State change → yes (is- prefix)
├── Behavior variant → yes
└── Same appearance → no modifier
When to use composition:
├── Shared patterns → mixin class
├── Size variants → composition
├── Color variants → composition
└── Complex variants → component extension
When to use inheritance:
├── Slight variation → override
├── Base component → yes
├── Many overrides → composition
└── Rarely shared → single component
When to use custom properties:
├── Theming → yes
├── Responsive values → yes
├── Interactive values → yes
└── Static values → hardcode
When to split files:
├── 1000+ lines → split
├── Multiple people → split
├── Clear domain → split
└── Small project → single file
Folder structure decision:
├── By component → feature teams
├── By type → role separation
├── By page → simple sites
└── Hybrid → most projects
When to use index file:
├── Re-exports needed → yes
├── Multiple entry points → yes
├── Barrel pattern → yes
└── Simple project → direct import
When to add new selector:
├── Override third-party → use higher specificity
├── Component override → block override
├── Global style fix → specific selector
└── Default → keep specificity low
When to use !important:
├── Override inline styles → yes
├── Utility classes → yes (limited)
├── Print styles → yes
└── Never → for normal code
When to refactor:
├── Specificity wars → refactor to composition
├── Important overuse → refactor
├── Deep nesting → flatten
└── Duplication → extract to component
❌ Deep selector chains (.nav ul li a span)
✅ Flat, single-class selectors with BEM/utility approach
❌ Inline styles scattered throughout HTML
✅ Style only via classes — one source of truth
❌ !important everywhere to override specificity wars
✅ Fix specificity at the root — flatten the cascade
❌ One monolithic CSS file for the whole app
✅ Co-located styles per component/feature
❌ Global .button styles affecting every button
✅ Namespace component styles to their scope
| Task | Approach | Why |
|---|---|---|
| Component styles | CSS Modules / scoped | No bleed |
| Global tokens | CSS custom properties | Runtime themeable |
| Utility classes | Tailwind / UnoCSS | Zero dead CSS |
| Dark mode | [data-theme] attribute | No flash |
| Responsive | Mobile-first breakpoints | Progressive enhancement |
| Specificity | Flat selectors (0,1,0) | Predictable override |