Menu
将每个实现决策扎根于官方文档。当需要权威、有来源引用的代码且不包含过时模式时使用。当使用任何正确性很重要的框架或库构建时使用。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
指导稳定的 RPC、存储协议和接口设计。在设计节点间 RPC、存储协议语义、模块边界或任何公共接口时使用。在定义 gRPC service、对象存储或文件系统语义、节点间的类型契约，或确立组件边界时使用。
自动化 CI/CD 流水线设置。在设置或修改构建和部署流水线时使用。当需要自动化质量门禁、在 CI 中配置测试运行器，或建立部署策略时使用。当需要处理 CI 上不稳定（flaky）的测试时使用。
进行多维度代码审查。在合并任何变更之前使用。在审查由你自己、另一个智能体或人类编写的代码时使用。当需要在代码进入主分支之前评估其跨多个维度的质量时使用。当需要评估变更的正确性、可读性、架构与性能，或审查 PR/diff 时使用。
为清晰性而简化代码。在重构代码以提高可读性而不改变行为时使用。当代码可以正常工作但比应有的更难阅读、维护或扩展时使用。在审查已积累不必要复杂性的代码时使用。当组件过度设计、过于炫技而难以维护时使用。当需要清理越来越难读懂的代码时使用。
验证系统的一致性与持久性承诺。在设计或修改复制协议、写路径、崩溃恢复逻辑时使用。当需要证明已确认的写入不丢失、副本间不发散、崩溃后能恢复到一致状态，或评审 fsync/校验和/事务语义时使用。
优化智能体上下文设置。在开始新会话、智能体输出质量下降、在不同任务之间切换，或需要为项目配置规则文件和上下文时使用。
| name | source-driven-development |
| description | 将每个实现决策扎根于官方文档。当需要权威、有来源引用的代码且不包含过时模式时使用。当使用任何正确性很重要的框架或库构建时使用。 |
每个框架特定的代码决策必须由官方文档支持。不要凭记忆实现——验证、引用，并让用户看到你的来源。训练数据会过时，API 会被弃用，最佳实践会演变。此技能确保用户得到他们可以信任的代码，因为每个模式都追溯到他们可以检查的权威来源。
何时不使用：
检测 ──→ 获取 ──→ 实现 ──→ 引用
│ │ │ │
▼ ▼ ▼ ▼
什么 获取 遵循 展示你
技术栈？ 相关文档 文档化的模式 的来源
阅读项目的依赖项文件以识别确切版本：
go.mod → Go（标准库、gRPC-Go、自研 Raft 库版本）
Cargo.toml → Rust（tokio、rocksdb、raft-rs）
CMakeLists.txt → C/C++（内核模块、存储引擎）
requirements.txt / pyproject.toml → Python（自动化与测试脚本）
明确陈述你发现的内容：
检测到的技术栈：
- Go 1.22（来自 go.mod）
- RocksDB 9.x（来自 CMake 依赖）
- protobuf 27.x / gRPC 1.6x
→ 获取相关模式的官方文档。
如果版本缺失或不明确，询问用户。不要猜测——版本决定了哪些模式是正确的。
获取你正在实现的功能的具体文档页面。不是首页，不是完整文档——是相关的页面。
来源层级（按权威顺序）：
| 优先级 | 来源 | 示例 |
|---|---|---|
| 1 | 官方文档 | grpc.io/docs、rocksdb.org、pkg.go.dev、docs.rs |
| 2 | 官方博客 / Changelog | go.dev/blog、github.com/facebook/rocksdb/releases |
| 3 | 协议与标准参考 | RFC（rfc-editor.org）、Raft 论文、Linux man-pages |
| 4 | 内核/工具链兼容性 | kernel.org 文档、Go/Rust 版本 release notes |
不是权威来源——永远不要引用为主要来源：
精确获取你要的内容：
坏：获取 gRPC 首页
好：获取 grpc.io/docs/languages/go/basics/
坏：搜索"rocksdb write stall 排查"
好：获取 github.com/facebook/rocksdb/wiki/Write-Stalls
获取后，提取关键模式并注意任何弃用警告或迁移指南。
当官方来源相互冲突时（例如迁移指南与 API 参考矛盾），向用户提出差异并验证哪种模式对检测到的版本实际有效。
编写与文档展示相匹配的代码：
当文档与现有项目代码冲突时：
检测到冲突：
现有代码库对 WAL 写入使用互斥锁逐条串行化，
但 RocksDB wiki 推荐通过 WriteBatch 做 group commit 批量落盘。
（来源：github.com/facebook/rocksdb/wiki/WriteBatch）
选项：
A) 使用文档推荐模式（WriteBatch 批量提交）——与当前文档一致
B) 匹配现有代码（互斥锁逐条写入）——与代码库一致
→ 你更喜欢哪种方案？
提出冲突。不要静默地选择一个。
每个框架特定的模式都获得一个引用。用户必须能够验证每个决策。
在代码注释中：
// gRPC 服务端通过 keepalive 参数检测半开连接，替代自研心跳
// 来源：https://pkg.go.dev/google.golang.org/grpc/keepalive#ServerParameters
svr := grpc.NewServer(grpc.KeepaliveParams(keepalive.ServerParameters{
Time: 10 * time.Second,
Timeout: 3 * time.Second,
}))
在对话中：
我对副本同步长连接的保活使用了 gRPC 官方 keepalive 参数，
而非自研心跳协议。
来源：https://grpc.io/docs/guides/keepalive/
"gRPC sends HTTP/2 pings on the transport to detect if the
connection is down"
引用规则：
/keepalive#ServerParameters 优于 /keepalive）——锚点在文档重组中比顶级页面更持久未验证：我找不到此模式的官方文档。这是基于训练数据，
可能已过时。在生产中使用前请验证。
关于你无法验证的内容的诚实比虚假的信心更有价值。
| 合理化借口 | 现实 |
|---|---|
| "我对这个 API 有信心" | 信心不是证据。训练数据包含看似正确但在当前版本下会出错的过时模式。验证。 |
| "获取文档浪费 Token" | 幻觉生成一个 API 浪费更多。用户调试一个小时，然后发现函数签名变了。一次获取可以防止数小时的返工。 |
| "文档不会包含我需要的东西" | 如果文档没有覆盖它，那是有价值的信息——该模式可能不是官方推荐的。 |
| "我提一下它可能过时就行" | 免责声明没有帮助。要么验证并引用，要么清楚地标记为未验证。模棱两可是最糟糕的选择。 |
| "这是个简单的任务，不需要检查" | 带有错误模式的简单任务会变成模板。用户在发现现代方法存在之前，将你已过时的锁模式复制到十几个模块中。 |
go.mod / Cargo.toml 等依赖项文件使用源码驱动开发实现后：