菜单
Catalog of guidelines for writing UI code in the Warp client. Read whenever doing any UI work in this repo, up front before writing the change, so the relevant guidelines shape the implementation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Fetch and display GitHub PR review comments for the current branch.
**MANDATORY prerequisite** — you MUST invoke this skill BEFORE every `use_figma` tool call. NEVER call `use_figma` directly without loading this skill first. Skipping it causes common, hard-to-debug failures. Trigger whenever the user wants to perform a write action or a unique read action that requires JavaScript execution in the Figma file context — e.g. create/edit/delete nodes, set up variables or tokens, build components and variants, modify auto-layout or fills, bind variables to properties, or inspect file structure programmatically.
Guides testing Warp UI features and changes using the computer use tool. Use this skill only when the computer_use tool is available to the agent. Covers launching Warp and verifying UI behavior.
Repo-specific review guidance for warp. Only the categories declared overridable by the core review-pr skill may be specialized here.
Control and inspect the currently running local Warp application with the warpctrl CLI. Use this skill whenever the user asks the agent to manipulate Warp's own windows, tabs, panes, sessions, input buffer, themes, or UI surfaces; open a file in Warp; inspect local Warp state; or explain how to invoke Warp Control manually.
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
| name | warp-ui-guidelines |
| description | Catalog of guidelines for writing UI code in the Warp client. Read whenever doing any UI work in this repo, up front before writing the change, so the relevant guidelines shape the implementation. |
This skill is a growing catalog of guidelines for working on Warp's UI code. Each guideline captures a lesson that would otherwise be re-learned through review — typically because an agent or contributor reinvented a component, drifted from the design system, or bypassed a shared abstraction.
How to use this skill:
New guidelines get added here over time. If you discover a recurring UI mistake that would have been caught by a written rule, add it.
Button colors come from a shared set of ActionButtonTheme impls in app/src/view_components/action_button.rs (and the parallel Theme impls in crates/ui_components/src/button/themes.rs) — PrimaryTheme, SecondaryTheme, NakedTheme, DangerPrimaryTheme, etc. These encode the design system and keep button colors consistent across the app.
When styling a button, use one of the existing themes unchanged. The shared themes are well-established and vetted; if one looks "wrong" for your use case, the most likely explanation is that you're reaching for the wrong theme, not that the theme is buggy.
Do not modify a shared theme on your own initiative. Changing PrimaryTheme, SecondaryTheme, etc. affects every button in the app, and a tweak that fixes your screen can silently regress others. Only edit a shared theme when the user has explicitly confirmed that the design-system component itself needs to change.
Red flags that you're about to make buttons inconsistent:
impl ActionButtonTheme for FooPrimaryTheme that delegates to PrimaryTheme and only tweaks one method (usually text_color). Almost always the right move is to use PrimaryTheme directly and accept the result.ColorU::new(...) instead of using appearance.theme() accessors (accent, font_color(bg), foreground, etc.).should_opt_out_of_contrast_adjustment to true to force a specific label color.FooPrimaryTheme, BarSubmitTheme) rather than a design-system role.If an existing theme genuinely doesn't fit and you think the shared theme should change, surface that to the user before editing it, rather than either editing it unilaterally or papering over it with a one-off.