القائمة
通用创建提案技能。根据需求是否有设计稿或 UI 描述、是否有接口、是页面还是功能组件等可选条件，决定设计稿分析、接口与数据层、以及实现后的 UI 还原验收等步骤。适用于各类需求提案，不限于纯 UI 页面。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
检查 .agents 下 rules、skills、README 与模板基线依赖的一致性，避免规则漂移、悬空引用和 React 能力越界。修改或新增 .agents 内容时使用本技能。
指导在前端项目中按团队规范创建和维护接口请求层，涵盖统一请求客户端、业务 API 文件、类型组织、错误处理、mock 过渡与 React 使用边界。当前端需要新增或重构接口时使用本技能。
指导在前端项目中按团队规范创建和维护 React 组件，涵盖通用组件与页面级组件的边界、目录结构、样式隔离、类型设计与导出策略。当前端需要新增、拆分或沉淀组件时使用本技能。
指导在前端项目中按团队规范创建和维护路由（React Router Data Router），涵盖路由单源、页面目录、路由模块注册、懒加载、标题与守卫等约束。当前端需要新增或重构页面路由时使用本技能。
指导在前端项目中按团队规范使用 Zustand 创建和维护全局状态 store，包括目录结构、命名与持久化策略。当前端需要新增或重构状态管理时使用本技能。
指导在前端项目中正确使用 Ant Design 与自定义主题 CSS 变量，避免硬编码颜色并保证暗色/浅色主题切换一致性。当前端编写或修改样式时使用本技能。
| name | create-proposal |
| description | 通用创建提案技能。根据需求是否有设计稿或 UI 描述、是否有接口、是页面还是功能组件等可选条件，决定设计稿分析、接口与数据层、以及实现后的 UI 还原验收等步骤。适用于各类需求提案，不限于纯 UI 页面。 |
当需要为一个需求创建 OpenSpec 提案（proposal、tasks、spec）时使用本技能。需求可能是：
本技能根据「是否有设计稿/UI 描述」「是否有接口」「交付形态（页面/组件/其它）」等条件，决定执行哪些步骤、产出哪些任务。
在写 proposal / tasks / spec 之前，先确认下列条件，以便后续步骤按需执行。
| 条件 | 选项 | 影响 |
|---|---|---|
| 是否有设计稿或 UI 要求描述 | 有 / 无 | 有 → 可选用 design-analysis 产出 UI 分析清单；实现后可有 UI 还原验收步骤 |
| 是否有接口（已提供或约定） | 有 / 无 / 未就绪 | 有 → 正常对接；无 → 可不做数据层；未就绪 → mock，见项目 Mock 数据策略 |
| 交付形态 | 新页面 / 功能组件 / 能力模块 / 其它 | 决定目录结构（routes vs components）、tasks 模板 |
| 是否仅样式/还原类 | 是 / 否 | 是 → 重点在 design-analysis + 验收 |
当需求包含界面且有设计稿（.pen、figma链接、设计图、标注）或有明确 UI 描述时：
.agents/skills/design-analysis/SKILL.mddocs/样式还原/<名称>-UI分析清单.md这样后续开发可以依据分析清单精确实现，实现后的验收也以此清单为基准。不限定「必须先分析再写提案」：可以边写提案边分析，或先分析再写提案，只要在开发前有一份分析清单即可。
在 tasks 中可写明：页面/组件开发须依据 docs/样式还原/<名称>-UI分析清单.md 实现布局与样式。
若交付形态是页面或功能组件，根据 .agents/rules/04-组件规范.md 判断组件放置位置：
src/components/<name>/src/views/<page>/components/<name>/ 或对应功能目录下涉及页面时，常见约定：
.module.scsssrc/types/<feature>/，含 model.ts、api.ts.agents/rules/08-通用约束.md）若需求涉及接口（已提供或未就绪）：
.agents/rules/03-项目结构.md 等规范，在 tasks 中安排 types/、http/ 等。src/types/<feature>/ 下定义 model.ts、api.ts，在 src/http/<feature>.ts 下提供 mock；tasks 中标注「mock，后续替换」。若不涉及接口，可省略或仅写「无后端依赖」。
根据需求类型书写，建议包含：
若有设计稿或 UI：可写「图标/图片使用占位元素」「开发依据 docs/样式还原/xxx-UI分析清单.md」等。
按交付形态与条件勾选任务，例如：
index.module.scss、与布局一致的结构；若有分析清单则写「依据 xxx-UI分析清单 实现」。index.tsx、index.module.scss、占位与规范。src/types/<feature>/、src/http/<feature>.ts 或 mock。.agents/skills/ui-verification/SKILL.md 进行 UI 还原验收，产出问题清单并反思分析不足」。定义需求规格：场景、验收标准、可选的状态与边界。若有 UI，可引用分析清单中的「验证检查清单」作为验收参考。
当需求包含界面且有设计稿并已产出 UI 分析清单时，在实现完成后需要进行 UI 还原验收时：
.agents/skills/ui-verification/SKILL.md当开发涉及 UI 还原（有设计稿或分析清单）时，可对照以下检查项自检；更完整项见 docs/样式还原/<名称>-UI分析清单.md 中的「验证检查清单」。
布局：区域位置、尺寸、间距是否与分析清单/设计稿一致；对齐方式（如 flex-start vs center）是否正确。
样式：颜色、字体、字号、字重、圆角、边框、阴影、效果（如 backdrop-filter）是否一致。
元素：是否缺少区块、图标、占位图；占位尺寸与比例是否正确。
交互：默认/hover/active 等状态是否还原（若有设计）。
create-route、create-component 等技能中「涉及 UI 还原时」可引用：.agents/skills/create-proposal/SKILL.md 中的「样式还原验证检查清单」及对应页面的 docs/样式还原/<名称>-UI分析清单.md。
.agents/rules/03-项目结构.md - 目录结构、Mock 数据策略.agents/rules/04-组件规范.md - 组件放置决策.agents/rules/05-API规范.md - 接口目录与命名规范.agents/rules/08-通用约束.md - 占位元素等.agents/rules/09-样式规范.md - 设计稿颜色提取.agents/skills/design-analysis/SKILL.md - 设计稿分析（有设计稿时使用，产出 UI 分析清单）.agents/skills/create-component/SKILL.md - 创建组件.agents/skills/create-api/SKILL.md - 创建接口层.agents/skills/ui-verification/SKILL.md - UI 验收（实现后需验收时使用）