api-testing

API 测试（English）

中文版： 请参阅对应的中文技能。

使用场景

• 需要 API 测试计划、API 用例或 API 风险分析。
• 请求涉及 REST、GraphQL、SOAP、gRPC、WebSocket 或混合 API 行为。

工作流

1. 阅读并遵循 Progressive disclosure 下列出的主提示词（覆盖范围、结构、质量标准）。
2. 仅补充会影响结果的项目背景：范围、环境、约束、风险、依赖项、预期交付物。
3. 如果输入不完整，先提供可用的初稿，并明确标注假设和信息缺口。
4. 默认使用 Markdown；仅在用户要求时切换格式。

领域执行要点

1. 仅针对已确认的协议分支处理：REST 方法/状态/模式/幂等性；GraphQL 数据+错误/null/字段权限；gRPC 状态/元数据/截止时间/流终止；WebSocket 握手/消息 ID/顺序/重连；SOAP WSDL/命名空间/Fault。不要要求使用未涉及的协议。
2. 将契约检查与跨请求业务后置条件分开：创建/更新→回读→权限视图→重复操作/下游影响。保留请求 ID、业务键、版本和证据。
3. 状态正确但持久化的余额/状态/关系错误，属于业务失败。对于异步影响，应用项目的一致性时间窗口，切勿臆造延迟。
4. 准备隔离的命名空间/唯一业务键，按依赖关系的逆序清理，并记录残留。缺少授权或存在实际影响约束时，保持阻塞状态。

核心约束

• 按风险/业务影响确定优先级，不要一视同仁。
• 区分已确认的事实与当前假设。
• 不要臆造用户未提供的端点、字段、环境或根因。
• 保持输出可执行：场景具体、优先级明确、后续步骤清晰。

渐进式披露

• 校准领域结果、有效对照或证据缺口时，请阅读 references/domain-decision-example.md，了解经过脱敏的输入、逐项判定标准和可复现的计算。

• 生成输出前，阅读并遵循 prompts/api-testing.md（最低覆盖要求、输出结构、质量标准）。

• 请求 Excel/CSV/JSON/Word 格式时：阅读 output-formats.md 并遵循相应格式。

• 有现成模板适用时：使用 output-templates/ 下的对应文件。

• 查阅深入的框架/故障排查/模式说明时：仅阅读 references/ 下相关文件，不要加载整个目录。

• 进行格式转换或辅助检查时：优先使用现有的 scripts/，不要重复造轮子。

• 评估/回归此技能时：使用 evals/ 和 skill-up。

交付前检查清单

• 遵循了主提示词的输出结构
• 最低覆盖重点：范围内的端点或业务流程、优先级和风险级别、正向场景、负向场景、边界场景、身份验证和权限检查、请求和响应验证、错误处理……（详见主提示词）
• 覆盖了最低检查清单，或说明了未覆盖的内容
• 高风险项已明确标注优先级
• 未臆造用户未提供的细节
• 已标注假设和信息缺口

常见问题

• 范围/背景缺失时，不要假装内容完整。
• 不要将所有事项视为同等重要。
• 不要遗漏假设和信息缺口。
• 不要罗列与当前工具链无关的通用理论。