
你必须在任何创意工作之前使用:新功能、组件搭建、添加能力或修改行为。先通过对话澄清用户意图、需求与设计,再进入实现。
当你面对 2 个以上彼此独立的任务(无共享状态、无顺序依赖)时使用:为每个独立问题域派发一个 agent 并行推进。
当你已经有一份书面的 implementation plan,需要在独立 session 中按批执行并在批次间做 review checkpoint 时使用。
当实现已完成、测试已通过,需要决定如何集成这次工作时使用:通过结构化选项引导 merge/PR/保留/丢弃,并在选择后完成收尾与清理。
Frontend Master - 大师级前端页面开发。智能分析项目技术栈,生成独特设计美感的 UI,避免'AI审美'。自动持久化设计规范,保持项目一致性。整合 Frontend-Design 设计哲学 + UI-UX Pro Max 设计数据库。触发词: 前端、页面、组件、UI、登录页、落地页、dashboard、表单、卡片、导航栏。
在任务接近完成、实现重大功能或合并前使用:通过 code review 验证实现是否满足需求并尽早发现问题。
当你在当前 session 中执行 implementation plan,且各 task 大多独立时使用:每个 task 派发新的 subagent,并在每个 task 后做两阶段 review(先 spec compliance,再 code quality)。
当你要开始需要与当前 workspace 隔离的 feature 开发,或在执行 implementation plan 之前使用:创建隔离的 git worktree,并包含目录选择与安全校验。
在任何对话开始时使用:建立“如何发现并使用 skills”的规则,要求在任何回应(包括澄清问题)之前先 invoke Skill tool。
在你准备声称“已完成/已修复/已通过”之前使用(尤其在 commit 或提 PR 前):必须运行 verification 命令并核对输出;永远 Evidence before assertions。
初始化新 skill 目录(运行 init_skill.py)、打包 skill(运行 package_skill.py)、或需要了解 skill 结构规范时使用。
遇到任何 bug、测试失败或非预期行为时使用;在提出修复方案之前必须先完成系统化的 root cause 调查。
在编写 skill 内容、验证 skill 是否有效、或需要用 TDD 方法测试 skill 能否被正确遵守时使用。
当你有 spec/requirements 且任务需要多步推进时使用;在动代码之前先写出可执行的 implementation plan。
在收到 code review 反馈时使用(在落地建议之前,尤其当反馈不清晰或技术上可疑时):要求技术严谨与验证,拒绝表演式同意或盲目实现。
在实现任何 feature 或 bugfix 时使用;在写实现代码之前必须先写测试并看到它失败(TDD)。