메뉴
发现并调用 agent skills。用于开始会话，或需要判断当前任务适用哪个 skill 时。这个 meta-skill 负责治理所有其他 skills 的发现与调用方式。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
指导稳定的 API 和接口设计。设计 API、模块边界或任何公共接口时使用。创建 REST 或 GraphQL endpoint、定义模块之间的类型契约，或建立前后端边界时使用。
在真实浏览器中测试。构建或调试任何在浏览器中运行的内容时使用。当你需要通过 Chrome DevTools MCP 检查 DOM、捕获 console 错误、分析网络请求、分析性能，或用真实运行时数据验证视觉输出时使用。
自动化 CI/CD pipeline 设置。用于设置或修改构建和部署 pipeline 时；用于需要自动化质量门禁、在 CI 中配置 test runners，或建立部署策略时。
执行多维度代码审查。用于合并任何变更之前；用于审查自己、其他 agent 或人类编写的代码；用于在代码进入主分支前从多个维度评估代码质量。
为清晰度简化代码。用于在不改变行为的前提下重构代码以提升清晰度；用于代码能运行但比应有状态更难阅读、维护或扩展时；用于审查已累积不必要复杂度的代码时。
优化 agent 上下文设置。当开始新会话、agent 输出质量下降、在任务之间切换，或需要为项目配置规则文件和上下文时使用。
| name | using-agent-skills |
| description | 发现并调用 agent skills。用于开始会话，或需要判断当前任务适用哪个 skill 时。这个 meta-skill 负责治理所有其他 skills 的发现与调用方式。 |
Agent Skills 是一组按开发阶段组织的工程工作流 skills。每个 skill 都编码了资深工程师会遵循的特定流程。这个 meta-skill 帮助你为当前任务发现并应用正确的 skill。
当任务到来时，识别开发阶段并应用对应的 skill：
Task arrives
│
├── Vague idea/need refinement? ──→ idea-refine
├── New project/feature/change? ──→ spec-driven-development
├── Have a spec, need tasks? ──────→ planning-and-task-breakdown
├── Implementing code? ────────────→ incremental-implementation
│ ├── UI work? ─────────────────→ frontend-ui-engineering
│ ├── API work? ────────────────→ api-and-interface-design
│ ├── Need better context? ─────→ context-engineering
│ ├── Need doc-verified code? ───→ source-driven-development
│ └── Stakes high / unfamiliar code? ──→ doubt-driven-development
├── Writing/running tests? ────────→ test-driven-development
│ └── Browser-based? ───────────→ browser-testing-with-devtools
├── Something broke? ──────────────→ debugging-and-error-recovery
├── Reviewing code? ───────────────→ code-review-and-quality
│ ├── Security concerns? ───────→ security-and-hardening
│ └── Performance concerns? ────→ performance-optimization
├── Committing/branching? ─────────→ git-workflow-and-versioning
├── CI/CD pipeline work? ──────────→ ci-cd-and-automation
├── Writing docs/ADRs? ───────────→ documentation-and-adrs
└── Deploying/launching? ─────────→ shipping-and-launch
这些行为始终适用，横跨所有 skills。它们是不可协商的。
在实现任何非平凡内容之前，明确说明你的假设：
ASSUMPTIONS I'M MAKING:
1. [assumption about requirements]
2. [assumption about architecture]
3. [assumption about scope]
→ Correct me now or I'll proceed with these.
不要默默补全含糊的需求。最常见的失败模式是做出错误假设，然后在未经确认的情况下继续推进。尽早暴露不确定性，这比返工便宜得多。
当你遇到不一致、互相冲突的需求，或不清楚的规格时：
坏例： 默默选择一种解释，并希望它是对的。 好例： “我看到 spec 里是 X，但现有代码里是 Y。哪一个优先？”
你不是 yes-machine。当某种做法存在明确问题时：
逢迎是一种失败模式。“Of course!” 之后实现一个坏主意，对任何人都没有帮助。诚实的技术分歧比虚假的认同更有价值。
你的自然倾向是把事情复杂化。要主动抵抗。
在完成任何实现之前，问自己：
如果你写了 1000 行，而 100 行就足够，那就是失败。优先选择无聊、明显的方案。聪明技巧很昂贵。
只触碰被要求触碰的内容。
不要：
你的工作是外科手术式的精确，不是主动翻新。
每个 skill 都包含验证步骤。验证通过之前，任务不算完成。“看起来没问题”永远不够，必须有证据（通过的测试、构建输出、运行时数据）。
这些细微错误看起来像是在提高效率，但会制造问题：
开始工作前检查是否有适用的 skill。 Skills 编码了能避免常见错误的流程。
Skills 是工作流，不是建议。 按顺序遵循步骤。不要跳过验证步骤。
多个 skills 可以同时适用。 一个功能实现可能会按顺序涉及 idea-refine → spec-driven-development → planning-and-task-breakdown → incremental-implementation → test-driven-development → code-review-and-quality → shipping-and-launch。
拿不准时，从 spec 开始。 如果任务不平凡且没有 spec，就从 spec-driven-development 开始。
对于完整功能，典型 skill 顺序是：
1. idea-refine → Refine vague ideas
2. spec-driven-development → Define what we're building
3. planning-and-task-breakdown → Break into verifiable chunks
4. context-engineering → Load the right context
5. source-driven-development → Verify against official docs
6. incremental-implementation → Build slice by slice
7. doubt-driven-development → Cross-examine non-trivial decisions in-flight
8. test-driven-development → Prove each slice works
9. code-review-and-quality → Review before merge
10. git-workflow-and-versioning → Clean commit history
11. documentation-and-adrs → Document decisions
12. shipping-and-launch → Deploy safely
并不是每个任务都需要每个 skill。一个 bug 修复可能只需要：debugging-and-error-recovery → test-driven-development → code-review-and-quality。
| 阶段 | Skill | 一句话摘要 |
|---|---|---|
| 定义 | idea-refine | 通过结构化的发散和收敛思考打磨想法 |
| 定义 | spec-driven-development | 在写代码前明确需求和验收标准 |
| 计划 | planning-and-task-breakdown | 拆解为小而可验证的任务 |
| 构建 | incremental-implementation | 薄的垂直切片，每次扩展前先测试 |
| 构建 | source-driven-development | 实现前先对照官方文档验证 |
| 构建 | doubt-driven-development | 用对抗式 fresh-context 审查每个非平凡决策 |
| 构建 | context-engineering | 在正确时间加载正确上下文 |
| 构建 | frontend-ui-engineering | 具备可访问性的生产级 UI |
| 构建 | api-and-interface-design | 有清晰契约的稳定接口 |
| 验证 | test-driven-development | 先写失败测试，再让它通过 |
| 验证 | browser-testing-with-devtools | 使用 Chrome DevTools MCP 做运行时验证 |
| 验证 | debugging-and-error-recovery | 复现 → 定位 → 修复 → 加保护 |
| 评审 | code-review-and-quality | 基于五个维度和质量门禁进行评审 |
| 评审 | security-and-hardening | OWASP 防护、输入验证、最小权限 |
| 评审 | performance-optimization | 先测量，只优化重要内容 |
| 发布 | git-workflow-and-versioning | 原子提交、干净历史 |
| 发布 | ci-cd-and-automation | 每次变更都运行自动化质量门禁 |
| 发布 | documentation-and-adrs | 记录为什么，而不只是记录做了什么 |
| 发布 | shipping-and-launch | 发布前检查清单、监控、回滚计划 |