API Documentation

Goal

用已检索的当前文档回答或实现，而不是凭训练记忆猜 API。完成时应满足：

• 已确认库、语言、版本和实际问题；
• 关键签名、参数、返回值或错误行为有检索证据；
• 实现与当前项目约束一致，并完成可行的最小验证；
• 文档缺失、版本冲突或时效性不确定时明确说明。

Source routing

选择能直接回答问题的最窄权威来源：

1. OpenAI 产品、API、SDK 或 Codex：退出本 skill，使用官方 openai-docs skill / Developer Docs connector；官方能力不可用时才把 chub 作为明确标注的 fallback。
2. 其他供应商若有官方或专用文档 connector：优先使用，并读取支持当前主张的具体页面。
3. 没有专用来源时使用 chub 的社区整理文档；时效性、未发布版本或精确 schema 很重要时，再用供应商官方文档核验。
4. 项目内部 API、README、AGENTS.md 或源码契约：直接读取仓库，不经 chub。
5. 主要问题是“选哪个库/框架”时交给 tech-preferences；选定后再用本 skill 查正确用法。

社区文档可能滞后。不要把“未检索到”写成“API 不存在”，也不要混用不同版本的示例。

Workflow

1. 从请求和项目 manifest/lockfile 提取库名、语言、版本、运行环境及待确认事实。缺失信息只有在会改变答案时才询问。
2. 使用 2-6 个有区分度的关键词搜索。已知具体页面时直接读取；结果为空、过窄或版本不符时，最多尝试一两个有意义的替代查询或官方来源。
3. 使用 chub 前先检查 chub --help 和相关子命令 help，从本机版本发现精确语法。若命令不可用，改用可用的官方来源并说明无法读取本地 annotation。
4. 读取支持结论的具体内容，区分文档事实、项目现场和推断。实现类请求把文档用法适配到当前代码，不机械复制示例。
5. 运行与改动最相关的检查，例如导入/类型检查、目标测试或最小 API 客户端 smoke；无法运行时说明缺口。
6. 已获得 annotation 写入授权时，先从本机 help 确认相关能力，再只写可复用的供应商/版本注意点。

Authorization and boundaries

• 查阅文档和本地 annotation 是只读；用户要求“标注、记录、保存”才授权写 annotation。
• 实现请求授权范围内本地代码修改与非破坏性验证；纯查阅或解释请求不自动修改项目。
• 实现请求可按项目现有机制修改范围内项目依赖；未经明确要求不做全局 CLI/SDK 安装，不发送真实生产请求，也不把文档示例中的占位凭据当成可用配置。
• annotation 不得包含 secret、客户数据或仅属于当前项目的临时状态。
• 官方文档与当前 SDK/运行结果冲突时，同时报告两者，不用其中一个静默覆盖另一个。

Output and stop rules

先给基于文档的结论或实现，再列关键来源、版本、验证和仍缺失的证据。核心问题已有足够支持时停止；不要为补充非必要背景反复检索。