Menü
发现并调用智能体技能。在开始会话或需要发现哪个技能适用于当前任务时使用。这是一个元技能，管理所有其他技能如何被发现和调用。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
指导稳定的 RPC、存储协议和接口设计。在设计节点间 RPC、存储协议语义、模块边界或任何公共接口时使用。在定义 gRPC service、对象存储或文件系统语义、节点间的类型契约，或确立组件边界时使用。
自动化 CI/CD 流水线设置。在设置或修改构建和部署流水线时使用。当需要自动化质量门禁、在 CI 中配置测试运行器，或建立部署策略时使用。当需要处理 CI 上不稳定（flaky）的测试时使用。
进行多维度代码审查。在合并任何变更之前使用。在审查由你自己、另一个智能体或人类编写的代码时使用。当需要在代码进入主分支之前评估其跨多个维度的质量时使用。当需要评估变更的正确性、可读性、架构与性能，或审查 PR/diff 时使用。
为清晰性而简化代码。在重构代码以提高可读性而不改变行为时使用。当代码可以正常工作但比应有的更难阅读、维护或扩展时使用。在审查已积累不必要复杂性的代码时使用。当组件过度设计、过于炫技而难以维护时使用。当需要清理越来越难读懂的代码时使用。
验证系统的一致性与持久性承诺。在设计或修改复制协议、写路径、崩溃恢复逻辑时使用。当需要证明已确认的写入不丢失、副本间不发散、崩溃后能恢复到一致状态，或评审 fsync/校验和/事务语义时使用。
优化智能体上下文设置。在开始新会话、智能体输出质量下降、在不同任务之间切换，或需要为项目配置规则文件和上下文时使用。
| name | using-agent-skills |
| description | 发现并调用智能体技能。在开始会话或需要发现哪个技能适用于当前任务时使用。这是一个元技能，管理所有其他技能如何被发现和调用。 |
智能体技能是按开发阶段组织的一组工程工作流技能。每个技能编码了资深工程师遵循的特定流程。此元技能帮助你发现并为当前任务应用正确的技能。
当任务到来时，识别开发阶段并应用相应的技能：
任务到来
│
├── 还不知道你想要什么？ ──────→ interview-me
├── 有粗略概念，需要变体？ → idea-refine
├── 新项目/功能/变更？ ──→ spec-driven-development
├── 有规格，需要分解任务？ ──→ planning-and-task-breakdown
├── 实现代码？ ────────────→ incremental-implementation
│ ├── RPC/存储协议/接口设计？ ──→ api-and-interface-design
│ ├── 需要更好的上下文？ ─────→ context-engineering
│ ├── 需要文档验证的代码？ ──→ source-driven-development
│ └── 高风险 / 不熟悉的代码？ ──→ doubt-driven-development
├── 编写/运行测试？ ────────→ test-driven-development
├── 有东西坏了？ ──────────────→ debugging-and-error-recovery
├── 验证容错/故障路径？ ───────→ failure-injection-testing
├── 验证一致性/持久性承诺？ ───→ consistency-and-durability-verification
├── 审查代码？ ───────────────→ code-review-and-quality
│ ├── 太复杂？ ─────────────→ code-simplification
│ └── 性能问题？ ────→ performance-optimization
├── 提交/分支？ ─────────→ git-workflow-and-versioning
├── CI/CD 流水线工作？ ──────────→ ci-cd-and-automation
├── 弃用/迁移？ ────────→ deprecation-and-migration
├── 写文档/ADR？ ───────────→ documentation-and-adrs
├── 添加日志/指标/告警？ ───→ observability-and-instrumentation
├── 部署/发布？ ─────────→ shipping-and-launch
└── 串联本轮产出物？ ──────────→ stage（用户显式调用）
这些行为始终适用，跨所有技能。它们是不可谈判的。
在实现任何非平凡的事情之前，显式陈述你的假设：
我正在做的假设：
1. [关于需求的假设]
2. [关于架构的假设]
3. [关于范围的假设]
→ 现在就纠正我，否则我将按这些进行。
不要静默地填补模棱两可的需求。最常见的失败模式是做出错误假设并在未经检查的情况下执行它们。尽早揭示不确定性——这比返工更便宜。
当你遇到不一致、冲突需求或不清晰的规格时：
坏： 静默地选择一个解释并希望它是正确的。 好： "我在规格中看到 X，但在现有代码中看到 Y。哪一个优先？"
你不是应声虫。当一个方法有明显问题时：
谄媚是一种失败模式。"当然可以！"然后实现一个坏主意对任何人都没有帮助。诚实的技术分歧比虚假的一致更有价值。
你的自然倾向是过度复杂化。主动抵制它。
在完成任何实现之前，问：
如果你构建了 1000 行而 100 行就足够，你失败了。优先选择无聊、显然的解决方案。聪明是昂贵的。
只触碰你被要求触碰的内容。
不要做：
你的工作是外科手术般精确，而非未经请求的翻新。
每个技能都包含一个验证步骤。在验证通过之前，任务不算完成。"看起来是对的"永远不够——必须有证据（通过的测试、构建输出、运行时数据）。
每个技能的验证是本地的检查。适用于每个变更的项目范围标准，无论哪个技能处于活跃状态，是完成定义：测试通过、无回归、行为在运行时验证、文档已更新。参见 references/definition-of-done.md。它补充每个任务的验收条件，而非替代它们。
这些是看似生产力但实际上制造问题的微妙错误：
在开始工作之前检查是否有适用的技能。 技能编码了防止常见错误的流程。
技能是工作流，而非建议。 按顺序遵循步骤。不要跳过验证步骤。
多个技能可能适用。 一个功能实现可能按顺序涉及 idea-refine → spec-driven-development → planning-and-task-breakdown → incremental-implementation → test-driven-development → code-review-and-quality → code-simplification → shipping-and-launch。
有疑问时，从规格开始。 如果任务是非平凡的且没有规格，从 spec-driven-development 开始。
对于一个完整的功能，典型的技能序列是：
1. interview-me → 提取用户真正想要什么
2. idea-refine → 精炼模糊的想法
3. spec-driven-development → 定义我们正在构建什么
4. planning-and-task-breakdown → 分解为可验证的块
5. context-engineering → 加载正确的上下文
6. source-driven-development → 对照官方文档验证
7. incremental-implementation → 逐切片构建
8. observability-and-instrumentation → 随构建一起进行仪表化（与 7-9 并行运行，而非之后）
9. doubt-driven-development → 对进行中的非平凡决策进行交叉审查
10. test-driven-development → 证明每个切片能工作
11. failure-injection-testing → 用受控故障注入验证容错承诺
12. consistency-and-durability-verification → 验证一致性与持久性承诺
13. code-review-and-quality → 合并前审查
14. code-simplification → 在保持行为的同时减少不必要的复杂度
15. git-workflow-and-versioning → 干净的提交历史
16. documentation-and-adrs → 记录决策
17. deprecation-and-migration → 淘汰旧系统并在需要时安全地迁移用户
18. shipping-and-launch → 安全部署
不是每个任务都需要每个技能。一个缺陷修复可能只需要：debugging-and-error-recovery → test-driven-development → code-review-and-quality。
| 阶段 | 技能 | 一句话摘要 |
|---|---|---|
| 定义 | interview-me | 在任何计划、规格或代码存在之前揭示用户真正想要什么 |
| 定义 | idea-refine | 通过结构化的发散和收敛思维精炼想法 |
| 定义 | spec-driven-development | 代码之前的验收条件和需求 |
| 规划 | planning-and-task-breakdown | 分解为小型、可验证的任务 |
| 构建 | incremental-implementation | 薄垂直切片，扩展前测试每个 |
| 构建 | source-driven-development | 实现前对照官方文档验证 |
| 构建 | doubt-driven-development | 对每个非平凡决策的对抗性全新上下文审查 |
| 构建 | context-engineering | 在正确的时间提供正确的上下文 |
| 构建 | api-and-interface-design | 具有清晰契约的稳定 RPC、存储协议与接口 |
| 验证 | test-driven-development | 先写失败的测试，然后使其通过 |
| 验证 | debugging-and-error-recovery | 复现 → 定位 → 修复 → 防护 |
| 验证 | failure-injection-testing | 受控故障注入，用证据验证容错承诺 |
| 验证 | consistency-and-durability-verification | 精确承诺 + 写路径审计 + kill point + 副本对账 |
| 审查 | code-review-and-quality | 带有质量门禁的五轴审查 |
| 审查 | code-simplification | 在减少不必要复杂度的同时保持行为 |
| 审查 | performance-optimization | 先测量，只优化重要的 |
| 交付 | git-workflow-and-versioning | 原子提交、干净历史 |
| 交付 | ci-cd-and-automation | 每次变更的自动化质量门禁 |
| 交付 | deprecation-and-migration | 移除旧系统并安全迁移用户 |
| 交付 | documentation-and-adrs | 记录为什么，而不仅仅是什么 |
| 交付 | observability-and-instrumentation | 结构化日志、RED 指标、追踪、基于症状的告警 |
| 交付 | shipping-and-launch | 发布前检查清单、监控、回滚计划 |
| 串联 | stage | 串联本轮所有产出物（MISSION → 应然 → 实然 → ADR → 验证），用户显式调用 |