菜单
Owner's cross-app product/UX principles — generous spacing, input-vs-view app affordances, and the Listen app's design north star. Auto-triggers when designing or reviewing layout, spacing, navigation affordances (FAB/drawer/dashboard), or any UI work in apps/listen.
用 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 | design-principles |
| description | Owner's cross-app product/UX principles — generous spacing, input-vs-view app affordances, and the Listen app's design north star. Auto-triggers when designing or reviewing layout, spacing, navigation affordances (FAB/drawer/dashboard), or any UI work in apps/listen. |
| user-invocable | false |
These are product-taste decisions from the owner (vincent), not derived from the code — get them wrong and a technically-correct PR still misses the point.
Across ALL apps (listen, watch, til, game, docs, main), the design language is generous spacing — large paddings/margins, airy layouts, roomy components, deliberately. More spacing reads as more generous to the end user; dense, neat, tightly-packed UI is explicitly disliked.
Decided 2026-07-04:
Why: the distinction is how much the end user inputs; a FAB overweights a rare/admin action in a consumption app.
How to apply: when adding any create/manage affordance to watch or listen, route it to the management-dashboard concept, not a FAB or a drawer item.
MusicWidget + PlayingList). Rule of thumb: any page where you can play audio must be this same screen — only the data (which songs) differs./playlists grid — it breaks the one-screen feel.Applies to any apps/listen UI work. See the architecture skill's "one page = one query" rule before adding a data fetch for a listen feature — most "like page X" needs are already in the current page's query.
See also the mui skill's styling model for how these principles get implemented in code.