菜单
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 职业分类
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.
| 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.