ub2-api-health-checker

API Health Checker 是一款专注于 API 端点健康状态监测的文档型技能，通过结构化的测试流程帮助开发者和运维人员系统化地验证接口可用性、响应合规性及性能表现。

核心用法
该技能提供完整的 API 测试工作流：用户只需指定目标端点 URL，即可执行 GET、POST、PUT、DELETE 等 HTTP 方法的请求测试。系统支持自定义请求头（包括 API 密钥、Bearer Token、Basic Auth 等认证方式）、设置超时阈值（默认 10 秒），并可针对响应状态码、响应时间及数据结构进行验证。测试完成后自动生成包含状态摘要、单端点详情、性能指标（平均/最小/最大/P95 响应时间）及优化建议的综合健康报告。

显著优点
作为纯文档型资产，该技能具备极高的安全性与透明度，无代码执行风险。其标准化流程大幅简化了 API 测试的复杂度，无需编写测试脚本即可完成多维度验证。性能测量功能可精准识别慢速端点，帮助团队及早发现潜在瓶颈。同时，支持多种认证机制使其适用于绝大多数现代 API 架构，生成的结构化报告便于团队共享与存档。

潜在局限
由于是纯提示词模板，实际请求执行依赖底层模型能力，极端复杂的自定义验证逻辑可能受限。此外，该技能本身不提供历史数据存储功能，无法自动追踪长期趋势变化。对于需要高频监控（如秒级探测）的生产环境，人工触发方式效率较低，更适合定期巡检或发布前验证场景。

适合人群
主要面向后端开发者、DevOps 工程师、API 产品经理及 QA 测试人员。适用于微服务架构下的接口验收、第三方服务集成前的连通性测试、以及 CI/CD 流程中的人工复核环节。对于需要快速验证 API 状态但不愿配置专业监控工具（如 Postman、Prometheus）的小型团队尤为实用。

使用风险
尽管 skill 本身无安全隐患，但使用时需注意：向不可信端点发送请求可能暴露源 IP 或触发目标安全机制；在对话中明文传输 API 密钥存在凭证泄露风险；批量测试可能对目标服务造成意外流量压力；此外，作为 T3 来源（个人开发者）的社区作品，长期维护与更新频率存在不确定性，关键业务场景建议结合官方监控工具使用。

核心用法

API Health Checker 提供系统化的 API 测试工作流：

• 端点测试：发送 GET/POST/PUT/DELETE 请求到指定 API
• 响应验证：检查状态码、响应时间、响应体结构是否符合预期
• 认证支持：处理 API 密钥、Bearer Token、Basic Auth 等认证头
• 性能测量：记录响应时间并标记慢端点
• 健康报告：生成综合报告，含状态摘要、单端点详情、性能指标（平均/min/max/p95）及优化建议

显著优点

• 工作流程完整：覆盖从请求发送、验证到报告输出的全链路
• 多认证方式兼容：支持主流 API 认证机制
• 性能量化：提供统计学指标（p95 等），便于容量规划
• 纯文档型实现：T-MD 分类，无可执行代码，透明度高

潜在缺点与局限性

• 功能声明与实际实现存在落差：Skill 文档详细描述了 HTTP 测试功能，但经安全审计确认为「纯 Markdown」文档（T-MD），无可执行代码，实际测试能力依赖 Claw 基础能力而非本 Skill 自身代码
• 网络依赖性强：所有功能需对外发起 HTTP 请求，受网络质量、目标 API 可用性影响
• 无原生重试/熔断机制：文档未提及失败重试、退避策略或熔断保护
• 安全风险转移：认证密钥需用户通过 Headers 传入，存在误操作泄露风险

适合人群

• 开发者、DevOps 工程师、API 产品经理
• 需要快速验证 API 可用性和性能指标的运维场景
• 轻量级监控需求，无需复杂探针部署的环境

常规风险

• 凭据泄露：Token/API Key 可能因配置不当留存于对话历史
• 误操作生产环境：可能向生产端点发送测试流量或脏数据
• 隐私合规：测试外部 API 时可能无意中泄露内部网络结构或敏感参数
• 示例域名混淆：文档中 api.example.com 虽为示例，但用户可能因疏忽未替换为实际目标