plan-redesign

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

plan-redesign — produce plan.md (5 phases + the 5 logic-freeze instructions)

plan-redesign — 生成 plan.md（5 个阶段 + 5 条逻辑冻结指令）

Turn the audit (and the optional Q&A) into a concrete, phase-by-phase redesign plan for the existing project — a pure-presentation upgrade that never touches logic. The output is

plan.md

, which

/implement-plan

then executes.

将审计结果（以及可选的 Q&A）转化为针对现有项目的具体分阶段重设计计划——这是一次纯粹提升呈现层、绝不触碰逻辑的升级。输出为

plan.md

，随后由

/implement-plan

执行。

The flow

流程

1. Load the inputs. Read

ui-ux-audit.md

(required — if it's missing, stop and ask the user to run

/audit-ui-ux

first). Read

qna-plan.md

if present.

If
```
qna-plan.md
```
is present: adopt its archetype, design work, in-scope features, and chosen GitHub skill.
If it's absent: run best-result mode — pick the archetype from the audit (dashboard → Modern Bento, product tool → Linear, marketing/SaaS → Stripe, etc.) plus the agent's own knowledge, and record the assumption in the plan's header. Done when: the audit is loaded and the archetype is chosen (from the Q&A or by best-result mode, with the choice recorded).

2. Bind to the sources strictly. The plan draws only from the 27 curated sources in

SOURCES.md

(this folder). For every planned transformation, name the source(s) it comes from. A need outside the 27 is marked outside the matrix and sourced from the audit + the agent's own knowledge. Done when: every phase in the draft cites at least one source from

SOURCES.md

(or is flagged as outside it).

3. Write
plan.md
. Compose it from the template below, populating each phase with: the target components (from the audit's priority refactor candidates), the specific transformations, the sources drawn from, and a definition of done. Done when:

plan.md

exists with exactly 5 phases, the 5 logic-freeze instructions, a recorded archetype, and per-phase sources + definitions of done.

1. 加载输入。 读取

ui-ux-audit.md

（必需——如果缺失，则停止并要求用户先运行

/audit-ui-ux

）。如果存在

qna-plan.md

，则读取。

如果存在
```
qna-plan.md
```
：采用其中确定的 archetype、设计工作、范围内特性和所选 GitHub skill。
如果不存在：运行 best-result mode——从审计结果中选定 archetype（dashboard → Modern Bento、product tool → Linear、marketing/SaaS → Stripe 等），并结合 Agent 自身知识，同时在计划头部记录该假设。 完成标准： 已加载审计结果，并已选定 archetype（来自 Q&A 或通过 best-result mode 选定，且已记录选择结果）。

2. 严格绑定来源。 计划只能采用

SOURCES.md

（此文件夹）中的 27 个精选来源。对于每项计划中的改造，注明其来源。如果某项需求超出这 27 个来源的范围，则将其标记为 outside the matrix，并以审计结果和 Agent 自身知识为依据。 完成标准： 草案中的每个阶段都至少引用

SOURCES.md

中的一个来源（或明确标记为超出范围）。

3. 编写
plan.md
。根据下方的模板进行编写，为每个阶段填入：目标组件（来自审计结果中的优先重构候选项）、具体改造、所采用的来源，以及完成定义。 完成标准：

plan.md

已存在，且恰好包含 5 个阶段、5 条逻辑冻结指令、已记录的 archetype，以及各阶段的来源和完成定义。

plan.md template

plan.md 模板

plan.md

always contains these three blocks, in this order.

plan.md

始终按顺序包含以下三个区块。

Block A — header

区块 A — 头部

Project · date · chosen archetype (and why) · the subset of the 27 sources the plan uses · which mode (Q&A-driven or best-result) produced it.

项目 · 日期 · 所选 archetype（及原因）· 计划采用的 27 个来源的子集 · 生成该计划的模式（Q&A 驱动或 best-result）。

Block B — the 5 logic-freeze instructions

区块 B — 5 条逻辑冻结指令

Write these verbatim; they are the logic-freeze contract that

/implement-plan

holds itself to for every edit.

Preserve every state and hook. Every
```
useState
```
,
```
useReducer
```
,
```
useRef
```
,
```
useMemo
```
,
```
useCallback
```
,
```
useContext
```
, and third-party hook (
```
useQuery
```
,
```
useForm
```
,
```
useRouter
```
,
```
useSearchParams
```
) keeps its exact name, dependency array, and internal logic. Change only how the output is presented.
Preserve every handler and event. Every
```
onClick
```
,
```
onSubmit
```
,
```
onChange
```
,
```
onKeyDown
```
,
```
onBlur
```
, and custom callback stays attached to its element with an unchanged signature and payload. Change only that element's appearance.
Preserve every API and mutation. Server actions, API-route requests, React Query mutations, and SWR revalidations keep identical arguments and effects.
Stay inside the visual layer. Every change comes from JSX restructure, Tailwind utility swaps, added decorative sub-elements, and accessible/motion wrappers around existing elements — never from data flow, validation, or side effects.
Merge classes safely. Any concatenated or prop-passed class string goes through
```
cn()
```
(clsx + tailwind-merge) so styles never collide.

逐字写入以下内容；它们是

/implement-plan

在每次编辑时都必须遵守的逻辑冻结契约。

保留每个 state 和 hook。 每个
```
useState
```
、
```
useReducer
```
、
```
useRef
```
、
```
useMemo
```
、
```
useCallback
```
、
```
useContext
```
和第三方 hook（
```
useQuery
```
、
```
useForm
```
、
```
useRouter
```
、
```
useSearchParams
```
）均须保持其名称、依赖数组和内部逻辑完全一致。只更改输出呈现方式。
保留每个 handler 和 event。 每个
```
onClick
```
、
```
onSubmit
```
、
```
onChange
```
、
```
onKeyDown
```
、
```
onBlur
```
和自定义 callback 都须继续挂载在对应元素上，且签名和 payload 保持不变。只更改该元素的外观。
保留每个 API 和 mutation。 Server Actions、API-route 请求、React Query mutations 和 SWR revalidations 均须保持参数和效果完全一致。
保持在视觉层内。 每项改动均须来自 JSX 重构、Tailwind 工具类替换、添加装饰性子元素，以及围绕现有元素添加无障碍或动效 wrapper——绝不能来自数据流、校验或副作用。
安全合并 class。 任何拼接得到或通过 prop 传入的 class 字符串都须经过
```
cn()
```
（clsx + tailwind-merge）处理，确保样式不会发生冲突。

Block C — the 5 phases

区块 C — 5 个阶段

Each phase has: goal, target components (from the audit), the transformations to apply (the detail lives in

implement-plan/TRANSFORM.md

), the sources drawn from (

SOURCES.md

), and a definition of done.

Foundation & design tokens — semantic color tokens, the type scale, the 8pt spacing scale, dark-mode ramps, the
```
cn()
```
helper, and base global styles.
Atomic components — the audit's primitives: buttons, inputs, badges, cards, modals, switches, tooltips.
Layout & domain components — nav, sidebar, app shell, footers, and feature/domain components; introduce bento-grid architecture where it fits.
Motion, micro-interactions & feedback — state transitions, active-press haptics, accessible focus rings, loading skeletons/shimmer, toasts, and spring/tab animations.
Responsive parity, accessibility & verification — mobile ergonomics (44px targets, tables → cards, modals → bottom sheets), accessibility (focus, aria, contrast), zero-CLS, and the final zero-regression check.

每个阶段包括：目标、目标组件（来自审计结果）、要应用的改造（具体细节见

implement-plan/TRANSFORM.md

）、采用的来源（

SOURCES.md

），以及完成定义。

基础与设计 token — 语义化颜色 token、字号阶梯、8pt 间距阶梯、暗色模式色阶、
```
cn()
```
helper，以及基础全局样式。
原子组件 — 审计结果中的基础组件：按钮、输入框、徽章、卡片、模态框、开关和 tooltip。
布局与领域组件 — 导航、侧边栏、应用外壳、页脚，以及功能或领域组件；在适合的位置引入 bento-grid 架构。
动效、微交互与反馈 — 状态过渡、按压时的触觉反馈、无障碍焦点环、加载骨架屏或 shimmer、Toast 通知，以及弹簧或标签页动画。
响应式一致性、无障碍与验证 — 移动端人体工学（44px 点击目标、表格 → 卡片、模态框 → bottom sheet）、无障碍（焦点、aria、对比度）、zero-CLS，以及最终的 zero-regression 检查。