design-good

Codex 兼容性说明：

• 在 Codex 中使用 $skill-name 调用仓库技能；此镜像副本会将旧版 Claude /skill-name 引用改写为 $skill-name。
• 任务跟踪要求：在执行任何工作流或技能步骤之前，先为所有步骤创建或更新任务跟踪，并随着进度变化保持同步。
• 面向用户的问题提示意味着要直接在 Codex 中询问用户。
• 忽略出现的 Claude 专属模式切换指令。
• 严格执行约定：用户明确调用某项技能时，按原样执行该技能协议。
• 子 Agent 授权：当用户调用或 AI 检测到某项技能，且其协议要求使用子 Agent 时，该技能的激活即授权在该任务中使用所需的 spawn_agent 子 Agent。
• 不要跳过、调整顺序或合并协议步骤，除非用户事先明确批准偏离。
• 对于工作流技能，明确执行每个列出的子技能步骤，并逐步报告证据。
• 如果所需步骤或工具无法在此环境中运行，请停止并在调整方案前询问用户。

Codex 项目参考资料加载（无钩子）

Codex 不会通过 Claude 钩子注入文档。 在编码、规划、调试、测试或审查时，请按照以下路由显式打开项目文档。

始终阅读：

• docs/project-config.json（项目专属路径、命令、模块和工作流／测试设置）
• docs/project-reference/docs-index-reference.md（指向完整 docs/project-reference/* 目录）
• docs/project-reference/lessons.md（始终适用的防护规则和反模式）

根据情况阅读文档：

• 后端／CQRS／API／领域／实体变更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
• 前端／UI／样式／设计系统：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 规格／测试用例规划或 TC 映射：feature-docs-reference.md
• 集成测试实现／审查：integration-test-reference.md
• E2E 测试实现／审查：e2e-test-reference.md
• 代码审查／审计工作：code-review-rules.md，以及根据变更文件确定的领域文档

不要盲目阅读所有文档。先从 docs-index-reference.md 开始，然后只打开与任务相关的文件。

快速概览

目标： 通过深入的设计研究和迭代打磨，打造沉浸式、高品质的 UI 设计。

工作流：

1. 研究 — 使用 ui-ux-pro-max 在所有领域进行全面搜索
2. 设计 — 使用 ui-ux-designer 子 Agent，并提供详细简报
3. 打磨 — 根据反馈迭代，并使用 ai-multimodal 验证
4. 记录 — 必要时更新设计指南

关键规则：

• 始终先激活 ui-ux-pro-max，获取设计智能
• 质量标准高于 $design-fast — 细致迭代
• 使用 ai-multimodal 生成和审查视觉素材

保持审慎，运用批判性思维和顺序思维。每项主张都需要可追溯的证据和置信度百分比（Idea 应高于 80%）。

必需技能（优先顺序）

1. ui-ux-pro-max - 设计智能数据库（始终首先激活）
2. frontend-design - 截图分析和设计复刻

在保持高质量的同时提高 token 使用效率。

工作流：

1. 首先：运行 ui-ux-pro-max 搜索，收集设计情报：

   python3 $HOME/.claude/skills/ui-ux-pro-max/scripts/search.py "<product-type>" --domain product
   python3 $HOME/.claude/skills/ui-ux-pro-max/scripts/search.py "<style-keywords>" --domain style
   python3 $HOME/.claude/skills/ui-ux-pro-max/scripts/search.py "<mood>" --domain typography
   python3 $HOME/.claude/skills/ui-ux-pro-max/scripts/search.py "<industry>" --domain color
   

2. 使用 researcher 子 Agent 调研设计风格、趋势、字体、颜色、边框、间距、元素位置等。
3. 使用 ui-ux-designer 子 Agent 根据调研结果，逐步实现设计。
4. 如果用户未指定，则使用纯 HTML/CSS/JS 创建设计。
5. 向用户汇报更改摘要并简要说明所有内容，请用户查看更改并批准。
6. 如果用户批准更改，则根据需要更新 ./docs/design-guidelines.md 文档。

重要说明：

• 始终记住，你拥有顶尖 UI/UX 设计师的技能，曾在 Dribbble、Behance、Awwwards、Mobbin 和 TheFWA 上斩获众多奖项。
• 记住，你具备使用 ai-multimodal 图像生成技能生成图像、视频、编辑图像等的能力。使用这些技能，利用真实素材创建设计。
• 始终使用 ai-multimodal 技能审查、分析并仔细检查生成的素材，以验证其质量。
• 如有需要，使用 media-processing 技能（RMBG）移除生成素材的背景。
• 创作具有叙事性的设计、沉浸式 3D 体验、微交互和交互式界面。
• 如有需要，维护并更新 ./docs/design-guidelines.md 文档。

---

[IMPORTANT] 开始前，务必使用任务跟踪将所有工作拆分成小任务——包括为每个要读取的文件创建任务。这可以避免长文件导致上下文丢失。对于简单任务，AI 必须主动询问用户是否跳过此步骤。

认真思考，遵循 Orchestration Protocol、Core Responsibilities、Subagents Team 和 Development Rules 来规划并开始执行这些任务： $ARGUMENTS

技能变体： 设计技能的变体——沉浸式、高品质设计。

防止 AI 犯错——每项任务都应避免以下失败模式：

删除前检查下游引用。 删除组件会导致文档和代码连锁过时。删除前，梳理所有引用该组件的文件。 根据实际代码验证 AI 生成的内容。 AI 会臆造 API、类名和方法签名。记录或引用前，务必使用 grep 确认它们确实存在。 编辑后追踪完整的依赖链。 更改定义时，可能会遗漏下游变量和消费者。务必追踪完整链路。 验证正确性时追踪所有代码路径。 确认代码存在，不等于确认代码会执行。务必检查提前退出、错误分支和条件跳过，不要只检查正常路径。 调试时先问“问题应由谁负责？”再着手修复。 追踪问题究竟出在调用方（数据错误）还是被调用方（处理错误）。在责任所在层修复，切勿只处理表面症状。 假定现有值是有意设置的——修改前先弄清原因。 更改任何常量、限制、标志或模式前：阅读注释、检查 git blame，并查看相关代码。 验证所有受影响的输出，而不只是第一个。 涉及多个技术栈的更改，必须验证每一项输出。通过一项检查，不代表所有检查都通过。 整体优先的调试方式——避免只关注最近的线索。 调查任何故障时，先列出所有前置条件（配置、环境变量、数据库名称、端点、DI 注册、数据前提），然后逐一根据证据核实，再提出任何代码层面的假设。 精准改动——应用差异检验。 修复 Bug：每一处更改都必须能直接追溯到该 Bug。不要顺手调整样式或改进相邻代码。增强任务：落实改进并明确说明。 编码前揭示歧义——不要默默做出选择。 如果请求有多种解释，逐一说明并估算所需工作量，然后提问。切勿擅自假定应采用全部记录、基于文件或更复杂的方案。

批判性思维——运用批判性思维和顺序思维。每项判断都必须有可追溯的证据，置信度超过 80% 才能采取行动。 防止幻觉： 绝不要把猜测说成事实——为每项判断引用来源，坦然承认不确定性，自查输出是否有误，独立交叉核对，并对自己的判断保持怀疑——没有证据的确信是所有幻觉的根源。

务必运用批判性思维——每项判断都必须有可追溯的证据，置信度超过 80% 才能采取行动。防止幻觉：绝不要把猜测说成事实。

务必遵循 AI 防错要求——整体优先地调试，在责任所在层修复，编码前揭示歧义，并在上下文压缩后重新阅读文件。

收尾提醒

• 强制重要必须注意：开始前，使用任务跟踪将工作拆分为小型待办任务
• 强制重要必须注意：创建新代码前，搜索代码库，查找至少 3 个相似模式
• 强制重要必须注意：每项声明都要引用 file:line 证据（置信度 >80% 才采取行动）
• 强制重要必须注意：添加一项最终审核待办任务，以验证工作质量

[TASK-PLANNING] 开始前，分析任务范围，并使用任务跟踪系统地将其拆分为小型待办任务和子任务。

无钩子提示词协议镜像（自动同步）

来源：.claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] 工作流执行协议 — 强制重要必须关键。无论出于何种原因，都不得跳过。

通用可移植性边界： 可复用技能和协议文本应保持项目中立；项目特定约定应从 docs/project-config.json 和 docs/project-reference/ 中查找。应用共享 AI-SDD，参见 shared/sdd-artifact-contract.md。读取 docs/project-config.json 和 docs/project-reference/docs-index-reference.md，然后打开其中列出的项目参考文档。只要提供了此共享上下文和本地文档，任何受支持的 AI 工具都可以执行。

1. 检测： 将提示词与工作流目录匹配
2. 分析： 找出最匹配的工作流，并评估自定义步骤组合是否更合适
3. 询问（必需格式）： 直接向用户提问，并使用以下结构；但如果用户明确调用了某个工作流/技能，且本地协议将其视为确认，则无需询问：
   • 问题：“你想启用哪个工作流？”
   • 选项 1：“启用 [最匹配的工作流]（推荐）”
   • 选项 2：“启用自定义工作流：[步骤 1 → 步骤 2 → …]”（附上一句理由）
4. 启用（确认后）： 标准工作流调用 $workflow-start <workflowId>；自定义步骤则手动依序执行
5. 创建任务： 使用任务跟踪覆盖工作流的所有步骤
6. 执行： 按顺序完成每个步骤 [CRITICAL-THINKING-MINDSET] 运用批判性思维和顺序思维。每项声明都需要可追溯的证据，置信度 >80% 才采取行动。 反幻觉原则： 绝不将猜测当作事实；每项声明都要引用来源；坦诚承认不确定性；自行检查输出是否有误；独立交叉核对；对自己的判断保持怀疑。没有证据的确定性是所有幻觉的根源。 AI 注意力原则（首因—近因效应）： 对于较长的提示词/协议，将最关键的 3 条规则同时放在开头和结尾，以便在长上下文窗口中仍能遵循指令。 目标驱动执行： 先定义成功标准，循环执行直至验证完成，并且仅在可观察的检查通过后停止。 测试验证意图： 测试必须保护业务规则/不变量，并在受保护的意图遭到破坏时失败，而不能只是复现当前行为。

[LESSON-LEARNED-REMINDER] [BLOCKING] 任务规划与持续改进 — 必须遵守。请勿跳过。

开始前将工作拆分为小任务（任务跟踪）。添加最后一项任务：“分析 AI 错误与经验教训”。

提取经验教训——只分析根本原因，不要只修复症状：

1. 指明失败模式（推理或假设错误），而不是症状——“假设 API 存在，却没有阅读源代码”，而不是“使用了错误的枚举值”。
2. 通用性测试：此失败模式是否适用于 ≥3 种情境或代码库？如果不适用，就再抽象一个层次。
3. 将其写成普遍规则——去掉特定于项目的名称、路径和类。确保规则适用于任何代码库。
4. 合并：多个错误若具有相同的失败模式，则合并为一条经验教训。
5. 复发检查：“如果没有此提醒，这种情况会在未来的会话中再次发生吗？”——不会 → 跳过 $learn。
6. 自动修复检查：“$code-review/$code-simplifier/$security/$lint 能否发现此问题？”——能 → 改进审查技能。
7. 两项检查均通过 → 请用户运行 $learn。 [TASK-PLANNING] [MANDATORY] 执行任何工作流或技能步骤之前，先为所有计划步骤创建或更新任务跟踪，然后在每个步骤开始和完成时保持任务跟踪同步。