theme-transformer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Theme Transformer

主题转换器

Transform existing interfaces into a futuristic cyberpunk/neon design system while preserving usability and product clarity.

在保留可用性和产品清晰度的前提下，将现有界面转换为未来感赛博朋克/霓虹设计系统。

Default Style Profile

默认风格配置

Use Neon Command Center as default visual baseline:

Futuristic + space + cyberpunk + digital-dark
Dark-first surfaces
Electric blue/cyan accents
Controlled glow (signal, not decoration)

Read these references when running this skill:

```
references/theme-tokens.md
```
(core tokens + mapping rules)
```
references/neon-command-center.md
```
(full style language)

If the target repo already has local branding docs (for example

docs/branding.md

brand.md

design-system.md

), read them first and prioritize user/project brand constraints.

以Neon Command Center为默认视觉基准：

未来感 + 太空风 + 赛博朋克 + 数字暗黑
深色优先的界面底色
电光蓝/青色强调色
克制的发光效果（作为功能标识，而非装饰）

执行此技能时请参考以下文档：

```
references/theme-tokens.md
```
（核心标识 + 映射规则）
```
references/neon-command-center.md
```
（完整风格规范）

如果目标仓库已有本地品牌文档（例如

docs/branding.md

、

brand.md

、

design-system.md

），请优先读取并遵循用户/项目的品牌约束。

Mandatory Safety Rule: branch first

强制安全规则：先创建分支

Before changing any file, sync with remote and check the current branch. Only create a new branch if on

main

master

— otherwise continue on the existing branch (the user likely set it up already or is resuming work):

bash

current_branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$current_branch"

if [ "$current_branch" = "main" ] || [ "$current_branch" = "master" ]; then
  slug="$(echo "${THEME_SLUG:-theme-transform}" | tr '[:upper:] ' '[:lower:]-' | tr -cd 'a-z0-9-')"
  ts="$(date +%Y%m%d-%H%M%S)"
  git checkout -b "design/${slug}-${ts}"
fi

If pull/rebase conflicts happen, stop and resolve with user before edits.

修改任何文件前，请同步远程仓库并检查当前分支。仅当处于

main

或

master

分支时才创建新分支——否则继续在现有分支上操作（用户可能已设置好分支或正在恢复工作）：

bash

current_branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$current_branch"

if [ "$current_branch" = "main" ] || [ "$current_branch" = "master" ]; then
  slug="$(echo "${THEME_SLUG:-theme-transform}" | tr '[:upper:] ' '[:lower:]-' | tr -cd 'a-z0-9-')"
  ts="$(date +%Y%m%d-%H%M%S)"
  git checkout -b "design/${slug}-${ts}"
fi

如果拉取/变基时发生冲突，请停止操作并与用户解决冲突后再进行编辑。

Mandatory 4-step workflow (approval-gated)

强制四步工作流（需审批）

Step 1) Analyze current style

步骤1）分析当前风格

Produce a concise style audit first.

Audit checklist:

Color system + contrast
Typography scale + readability
Spacing/radius/shadow consistency
Component states (buttons, inputs, nav, cards, tables, charts)
Motion behavior
Visual hierarchy / density

Output format:

Current strengths
Current inconsistencies
Migration risks

Do not implement changes before audit is shared.

首先生成简洁的风格审计报告。

审计清单：

色彩系统 + 对比度
排版层级 + 可读性
间距/圆角/阴影一致性
组件状态（按钮、输入框、导航、卡片、表格、图表）
动效表现
视觉层级 / 信息密度

输出格式：

当前优势
当前不一致点
迁移风险

在分享审计报告前请勿实施任何修改。

Step 2) Propose full design transformation

步骤2）提出完整设计转换方案

Propose the transformed design for all major elements.

Must include:

Theme direction statement
Token updates (color/type/radius/shadow/motion)
Component-by-component transformation map
Before/after intent for key screens

Iterate until user is happy:

Ask for feedback
Adjust proposal
Repeat until explicit approval

No implementation before approval.

针对所有主要元素提出转换后的设计方案。

必须包含：

主题方向说明
标识更新（颜色/排版/圆角/阴影/动效）
组件逐类转换映射表
关键页面的前后设计意图对比

反复迭代直至用户满意：

征求反馈
调整方案
重复直至获得明确批准

未获得批准前请勿实施。

Step 3) Propose implementation plan (step-by-step)

步骤3）提出分步实施计划

Create a gradual execution plan with verifiable checkpoints.

Each task must include:

Goal
Files/components impacted
Expected visual result
Verification method (screenshot/storybook/page checks/contrast checks)
Rollback note

Plan quality rules:

Sequence: tokens -> foundations -> shared components -> pages
Small, reviewable increments
Include accessibility checks each phase

Iterate the plan with user until approved.

No execution before plan approval.

创建带有可验证检查点的渐进式执行计划。

每个任务必须包含：

目标
受影响的文件/组件
预期视觉效果
验证方法（截图/Storybook/页面检查/对比度检查）
回滚说明

计划质量规则：

顺序：标识 -> 基础样式 -> 共享组件 -> 页面
拆分小模块，便于评审
每个阶段都包含可访问性检查

与用户迭代计划直至获得批准。

未获得计划批准前请勿执行。

Step 4) Execute approved plan

步骤4）执行已批准的计划

Run incremental execution loop:

Implement one task.
Run checks/build.
Provide verification instructions and/or screenshots.
Ask for feedback and adjust if requested.

Continue until user confirms satisfaction.

运行增量执行循环：

完成一项任务。
运行检查/构建。
提供验证说明和/或截图。
征求反馈并按需调整。

持续执行直至用户确认满意。

Prerequisites

前置条件

Git with write access to the repository (branching is mandatory before any file changes)
Reference files present:
```
references/theme-tokens.md
```
and
```
references/neon-command-center.md
```
in the repo; the skill reads these before generating any token proposals
Build tooling available: the project must be buildable locally (e.g.,
```
npm run build
```
or equivalent) so the execution phase can verify changes compile without errors
Optional: an existing design system or branding doc (
```
docs/branding.md
```
,
```
brand.md
```
,
```
design-system.md
```
) — if present, the skill reads it first to honor brand constraints

Git权限：拥有仓库的写入权限（修改任何文件前必须创建分支）
参考文件存在：仓库中包含
```
references/theme-tokens.md
```
和
```
references/neon-command-center.md
```
；技能在生成任何标识方案前会读取这些文件
构建工具可用：项目可在本地构建（例如
```
npm run build
```
或等效命令），以便执行阶段验证修改可正常编译
可选：现有设计系统或品牌文档（
```
docs/branding.md
```
、
```
brand.md
```
、
```
design-system.md
```
）——如果存在，技能会优先读取以遵循品牌约束

Expected Output

预期输出

After completing all four workflow steps on a React/Tailwind project, you should see:

A new git branch named
```
design/theme-transform-<timestamp>
```
with all changes committed
Updated design tokens file (e.g.,
```
tailwind.config.js
```
,
```
tokens.css
```
, or equivalent) with the full Neon Command Center color, typography, radius, shadow, and motion values
Updated shared component files (buttons, inputs, nav, cards, tables, charts) with the new visual treatment applied
Updated target pages/screens applying the theme end-to-end
A verification summary listing every changed file, the before/after intent, and instructions for visual QA (contrast ratios, focus states, responsive checks)

在React/Tailwind项目上完成所有四个工作流步骤后，你将看到：

一个名为
```
design/theme-transform-<timestamp>
```
的新Git分支，包含所有已提交的修改
更新后的设计标识文件（例如
```
tailwind.config.js
```
、
```
tokens.css
```
或等效文件），包含完整的Neon Command Center颜色、排版、圆角、阴影和动效参数
更新后的共享组件文件（按钮、输入框、导航、卡片、表格、图表），已应用新视觉样式
更新后的目标页面/屏幕，端到端应用了新主题
一份验证摘要，列出所有修改的文件、前后设计意图对比以及视觉QA说明（对比度、焦点状态、响应式检查）

Edge Cases

边缘场景

No design token system exists: Introduce a minimal tokens file (CSS custom properties or JS theme object) and migrate existing hardcoded values into it before applying the new theme.
User provides a custom accent color: Derive
```
primary-400
```
hover and glow alpha variants automatically; do not override
```
bg/surface/text
```
dark structure unless explicitly requested.
Project uses a CSS-in-JS runtime theme: Apply tokens through the runtime's theme API rather than static files; verify hot-reload picks up changes during execution.
Accessibility conflict: If a proposed neon color combination fails WCAG AA contrast, replace with a higher-contrast variant and note the substitution in the verification summary.
Existing local branding docs found: Treat them as hard constraints — do not override brand colors or typography unless the user explicitly asks.
Large codebase with hundreds of components: Scope Step 4 execution to the highest-traffic pages first; create a follow-up task list for remaining components rather than attempting everything in one pass.

无设计标识系统：先引入最小化标识文件（CSS自定义属性或JS主题对象），将现有硬编码值迁移到其中后再应用新主题。
用户提供自定义强调色：自动生成
```
primary-400
```
（ hover状态）和发光透明度变体；除非明确要求，否则不要修改
```
bg/surface/text
```
的深色结构。
项目使用CSS-in-JS运行时主题：通过运行时主题API应用标识，而非静态文件；执行期间验证热重载是否能识别修改。
可访问性冲突：如果提议的霓虹配色未通过WCAG AA对比度标准，替换为更高对比度的变体，并在验证摘要中注明替代方案。
发现现有本地品牌文档：将其视为硬性约束——除非用户明确要求，否则不要修改品牌颜色或排版。
包含数百个组件的大型代码库：步骤4的执行范围优先覆盖流量最高的页面；为剩余组件创建后续任务列表，而非一次性尝试全部修改。

Step Completion Reports

步骤完成报告

After completing each major step, output a status report in this format:

◆ [Step Name] ([step N of M] — [context])
··································································
  [Check 1]:          √ pass
  [Check 2]:          √ pass (note if relevant)
  [Check 3]:          × fail — [reason]
  [Check 4]:          √ pass
  [Criteria]:         √ N/M met
  ____________________________
  Result:             PASS | FAIL | PARTIAL

Adapt the check names to match what the step actually validates. Use

√

for pass,

×

for fail, and

—

to add brief context. The "Criteria" line summarizes how many acceptance criteria were met. The "Result" line gives the overall verdict.

Branch & Sync phase checks:

Branch created

Remote synced

Working tree clean

Audit phase checks:

Current styles analyzed

Components cataloged

Color palette extracted

Design phase checks:

Theme proposed

Color scheme defined

User approved

Execution phase checks:

Styles applied

Components updated

Visual consistency verified

完成每个主要步骤后，按以下格式输出状态报告：

◆ [步骤名称] ([第N步/共M步] — [上下文])
··································································
  [检查项1]:          √ 通过
  [检查项2]:          √ 通过（如有相关说明可补充）
  [检查项3]:          × 未通过 — [原因]
  [检查项4]:          √ 通过
  达标情况:         √ 满足N/M项要求
  ____________________________
  结果:             通过 | 未通过 | 部分完成

根据步骤实际验证内容调整检查项名称。用

√

表示通过，

×

表示未通过，

—

后添加简要上下文。"达标情况"行总结满足了多少验收标准。"结果"行给出整体结论。

分支与同步阶段检查项：

分支已创建

、

已同步远程仓库

、

工作区干净

审计阶段检查项：

已分析当前样式

、

已分类组件

、

已提取调色板

设计阶段检查项：

已提出主题方案

、

已定义配色方案

、

已获得用户批准

执行阶段检查项：

已应用样式

、

已更新组件

、

已验证视觉一致性

Color customization (mandatory)

颜色定制（强制要求）

Theme colors must be adjustable based on user input.

Rules:

Keep dark structure by default (
```
bg/surface/text
```
).
Map user accent color(s) to neon action tokens.
Preserve semantic colors unless user requests custom semantics.

If user gives one color:

Use as
```
primary-500
```
Auto-generate
```
primary-400
```
(hover) and glow alpha variants

If user gives two colors:

1st color = primary action
2nd color = secondary accent/data highlights

If user provides full palette:

Respect provided palette; skip defaults

主题颜色必须可根据用户输入调整。

规则：

默认保留深色结构（
```
bg/surface/text
```
）。
将用户提供的强调色映射到霓虹动作标识。
除非用户要求自定义语义，否则保留语义颜色。

如果用户提供一种颜色：

将其设为
```
primary-500
```
自动生成
```
primary-400
```
（hover状态）和发光透明度变体

如果用户提供两种颜色：

第一种颜色 = 主要动作色
第二种颜色 = 次要强调色/数据高亮色

如果用户提供完整调色板：

遵循提供的调色板，跳过默认设置

Deliverables (minimum)

最低交付物

Updated tokens/theme definitions (CSS/Tailwind/theme config)
Updated shared components
Updated target screens/pages
Verification summary (what changed + how to test)
Branch name + commit summary

更新后的标识/主题定义（CSS/Tailwind/主题配置）
更新后的共享组件
更新后的目标页面/屏幕
验证摘要（修改内容 + 测试方法）
分支名称 + 提交摘要

Quality guardrails

质量准则

Avoid unreadable neon-on-neon combinations
Avoid global glow overuse
Keep dense dashboard information scannable
Preserve focus states and keyboard accessibility
Prioritize usability over effects

避免难以阅读的霓虹叠霓虹组合
避免过度使用全局发光效果
保持高密度仪表盘信息的可扫描性
保留焦点状态和键盘可访问性
优先考虑可用性而非特效