design-fast

Codex 兼容性说明：

• 在 Codex 中使用 $skill-name 调用仓库技能；此镜像副本会改写旧版 Claude /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 开始，然后只打开与任务相关的文件。

快速摘要

目标： 使用设计智能数据库和子 Agent 快速创建 UI 设计。

工作流：

1. 调研 — 运行 ui-ux-pro-max 搜索设计智能资料
2. 设计 — 使用 ui-ux-designer 子 Agent 创建设计
3. 审查 — 提交给用户审批

关键规则：

• 始终先激活 ui-ux-pro-max，以获取设计智能资料
• 如果用户未指定框架，默认使用纯 HTML/CSS/JS
• 使用 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. 使用 ui-ux-designer 子 Agent 启动设计流程。
3. 如果用户未指定，则使用纯 HTML/CSS/JS 创建设计。
4. 向用户汇报变更摘要并简要说明所有内容，请用户检查并批准这些变更。
5. 如果用户批准这些变更，则根据需要更新 ./docs/design-guidelines.md 文档。

注意事项：

• 请记住，你可以使用 ai-multimodal 技能生成图像、视频、编辑图像等。请使用这些技能来创建设计和真实素材。
• 始终使用 ai-multimodal 技能审查、分析并仔细检查生成的素材，以验证其质量。
• 如有需要，请维护并更新 ./docs/design-guidelines.md 文档。

---

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

请认真思考如何规划并开始这些任务，遵循编排协议、核心职责、子 Agent 团队和开发规则： $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] 执行任何工作流或技能步骤之前，先为所有计划步骤创建或更新任务跟踪，然后在每个步骤开始和完成时保持任务跟踪同步。