القائمة
Enforces MUI component and styling conventions. Auto-triggers when writing or editing any TSX/TS files that use MUI components, styling, or theming.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | mui |
| description | Enforces MUI component and styling conventions. Auto-triggers when writing or editing any TSX/TS files that use MUI components, styling, or theming. |
| user-invocable | false |
These rules are about how to build and style a component inside packages/ui. For where UI lives — source of truth, which package and folder — see frontend-ui-architecture.
packages/ui)@mui/material — no custom wrappers unless strictly required. This applies inside packages/ui; how apps consume UI is frontend-ui-architecture's rule.// Good
import { Button, TextField, Stack } from '@mui/material';
// Bad — unnecessary wrapper
import { CustomButton } from '@/components/ui/CustomButton';
Use semantic MUI components instead:
Stack for flex layoutsContainer for page containersPaper for elevated surfacesCard for content cardsGrid for grid layoutsAlways use sx prop or theme — no className on MUI components.
There are exactly TWO places a style can live. There is no third case.
packages/ui/src/universal/minimalism/), via palette + components styleOverrides.sx prop on that component.The litmus test: swapping the theme provider must be the ENTIRE re-skin of an app. Wrap the app in a different provider and every screen must look right with zero extra work. If a screen looks wrong after a provider swap, that is a styling hack in our code — a component hardcoding what the theme owns — and the hack gets fixed (moved into the theme, or reduced to a real one-off sx), never patched around with app-specific styling.
Corollary: never restyle a component to "match" a design system — if many components need the same look, that look belongs in the theme's styleOverrides, once.
Use relative units that scale with user preferences:
| Property | Bad | Good |
|---|---|---|
| fontSize | '14px' | '0.875rem' |
| lineHeight | '20px' | 1.429 (unitless) |
| letterSpacing | '0.5px' | '0.035em' |
| spacing/padding/margin | '16px' | theme.spacing(2) or sx={{ p: 2 }} |
| width/height | '300px' | theme.spacing(37.5) or responsive values |
grey[100], #e0e0e0, 'white' in a component are latent dark-mode bugs — use mode-aware tokens (background.paper, action.hover, text.secondary, …) that the theme resolves per mode.// Bad
<Paper sx={{ bgcolor: '#193c4d' }} />
// Good
<Paper sx={{ bgcolor: 'background.paper' }} />
For complex components:
src/components/features/[feature]/
index.tsx # Container — state, hooks, API calls
[Feature]UI.tsx # Presentational — pure rendering from props
[Feature].stories.tsx # Storybook — tests UI directly
Container (index.tsx): manages state, fetches data, contains handlers, passes everything to UI via props.
UI ([Feature]UI.tsx): pure presentational — no state, no hooks, no API calls. All data via props.
Storybook ([Feature].stories.tsx): tests UI component directly with mocked props. No API mocking needed.
The post-PR CI gate loop — a strict sequential state machine that drives an open PR to settled: merge status → conflicts → unresolved review threads → CI checks, fixing/pushing/waiting/restarting until every gate is green, then reporting ready (never auto-merging). Use whenever the user says "do the loop", "run the loop", "the CI loop", "check the PR", or invokes /ci-loop. On merge it runs `cleanup` for teardown. It does NOT do the pre-PR self-review (that's `parallel-workflow`'s gate) and never touches issue status (that's the tracker's — see `task-tracker`).
Enforces the parallel subtask workflow using tracker issues, git worktrees, and PRs. Auto-triggers when working with git, branches, worktrees, PRs, tracker issues/tasks, codegen, or CI.
The single source of truth for WHICH task tracker we use and HOW to talk to it. Load this whenever you need to create, read, update, relate, or comment on a task/issue/project, or whenever another skill says "the task tracker", "the tracker issue", "the issue's state", or points at `task-tracker`. It owns the tool (Linear, via the `linear` CLI — never the Linear MCP), auth, the SWorld team and `SWO` key, the project-is-an-app model, the Backlog→Todo→In Progress→In Review→Done lifecycle, and the exact issue/relation/document command forms. Reach for it any time a workflow step runs a `linear …` command or names a tracker concept, even when the triggering skill refers to "the issue" only generically.
Known traps in the sworld local dev/build tooling — stale package dists, turbo cache masking bundle changes, Node version pinning, pnpm's dependency cooldown, CodeGraph setup, and bundle-size vs error-tracking tradeoffs. Auto-triggers when a dev server fails to resolve a core/ui subpath, a build "works" but the change isn't visible, adding/upgrading a dependency, or trimming bundle size for perf.
The audit pass on an already-scoped ticket and its sub-issue breakdown, run BEFORE any code. Use it as the first move whenever picking up, starting, resuming, or "analysing" a non-trivial tracker issue — especially a large-feature parent with sub-issues — to catch missing requirements and a breakdown that has drifted out of sync before you build against it. Reach for it the moment you're about to start an issue, when a plan "looks done" but nobody has re-checked it, or when the user says "analyse this issue / take a look at this breakdown / is this plan right". This is the backward/audit direction on a *spec* — distinct from `product-planning`/`grill-me` (forward, idea → breakdown) and `self-review` (analysing *code*). Not needed for a trivial, single-issue bug or a one-line change with no breakdown to audit.
Enforces frontend architecture patterns including server state management, data transformation, and GraphQL conventions. Auto-triggers when working with API calls, data fetching, react-query, GraphQL, or data transformations.