القائمة
将每个实现决策扎根于官方文档。当需要权威、有来源引用的代码且不包含过时模式时使用。当使用任何正确性很重要的框架或库构建时使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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 等依赖项文件使用源码驱动开发实现后：