安装方式
手动下载安装
下载 ZIP 后解压到技能目录即可安装。若在桌面客户端 WebView中直接下载出现异常，本站会改为提示页 + 原始链接，请按页内说明操作。
下载 ZIP (shub-openapi-spec-v1.0.0.zip)触发指令
/openapi-spec
跨平台安装指引
该技能声明兼容以下 1 个平台，将 ZIP 解压到对应目录即可被识别。
unzip shub-openapi-spec-v1.0.0.zip -d ~/.claude/skills/
目录不存在时请先
mkdir -p 创建；启用 Skill 后请重启对应 Agent 让配置生效。
使用指南
OpenAPI 规范
围绕 OpenAPI 规范：撰写与校验 OpenAPI 3.x，并生成客户端/服务端脚手架；与「graphql」API 风格区分。 无需在每次任务前把零散英文说明手工拼进上下文，也 减少 与客户端默认行为脱节的试错；具体命令、钩子与 JSON 参数仍以 ZIP 包内 SKILL.md 为权威。下文结构与站内 MCP CLI 类专题稿相同：何时用、前置、流程、速查与故障。
何时使用
- 撰写与校验 OpenAPI 3.x，并生成客户端/服务端脚手架
- 与「graphql」API 风格区分
- 已获取本技能 ZIP，并准备在 Claude Code / OpenClaw 中按 SKILL.md 挂载。
- 希望用中文专题稿快速判断「该不该启用」，再深入英文 SKILL 查参数与边界。
- 需要与团队对齐同一套触发方式、目录约定或回调格式时。
前置条件
- 通用：可运行 Claude Code 或文档要求的客户端；有可读写的项目工作区（或 SKILL.md 指定的沙箱目录）。
- 权威细节：API Key / OAuth、钩子路径、环境变量以 ZIP 内 SKILL.md 为准。
典型流程
- 从 ClawHub / 站内分发获取技能 ZIP，校验版本与校验和（若提供）。
- 阅读 SKILL.md 的安装段落：目录落点、客户端类型（Claude Code / OpenClaw / 脚本）。
- 用文档中的最小示例完成第一次调用（单文件修改、单次查询或单次委派）。
- 确认工作目录、权限边界与输出路径后，再处理多文件或长耗时任务。
- 需要回调 / Webhook / 通知时，按 SKILL.md 配置端点并在测试环境先验通。
与 ZIP / SKILL.md 的关系
站内专题稿与 MCP CLI 类 oss 稿同样：概括何时用、怎么接、怎么排错；命令模板、钩子名、JSON 字段、版本矩阵一律以 ZIP 内 SKILL.md 与 ClawHub 上游为准。
命令示例（摘自包内 SKILL.md）
以下为从上游 SKILL.md（或入库正文）自动抽取的终端/脚本片段；路径、环境变量与参数以当前 ZIP 与官方说明为准。
ClawHub slug：openapi-spec（安装命令以 SKILL.md / claw CLI 为准）。
站内入库时的触发命令（完整语义见 ZIP）：
# 使用本技能时可在对话中引用或执行上述指令；完整参数与示例见下载包内 SKILL.md。
/openapi-spec
最佳实践
- 先 SKILL.md 再猜参数；站内专题稿不替代 schema 与必填字段说明。
- 委派任务时写清验收标准（命令、文件路径、测试命令），减少来回追问。
- 长任务用文档推荐的回调 / 日志落盘代替高频轮询，省 Token 也省机器负载。
- 多技能同时启用时，注意钩子加载顺序与重复工具调用（以 SKILL.md 冲突说明为准）。
调试与排错
- 打开 stderr 与客户端日志；PTY/tmux 场景同时看面板最后几十行输出。
- 参数错误时对照 SKILL.md 中的 JSON/CLI 示例（引号、转义、工作目录）。
- 网络类失败：查代理、防火墙、MCP 传输方式（stdio / HTTP / SSE）。
速查
| 动作 | 说明 |
|------|------|
| 获取技能包 | ClawHub / 站内 ZIP，核对版本 |
| 权威步骤 | 优先阅读 ZIP 内 SKILL.md |
| 首次试跑 | 使用 SKILL.md 最小示例 |
| 验收 | 对照路径、测试命令或回调负载 |
常见故障
- 无输出或立即退出 → 工作目录错误、依赖未装、或 Claude Code 未登录；按 SKILL.md 自检清单执行。
- 权限被拒绝 → 检查沙箱路径、
--permission-mode与工具白名单。 - 与简介不符 → 以英文 SKILL 与上游仓库为准，站内稿仅作结构化导读。
# OpenAPI Specification (Deep Workflow)
OpenAPI is the **contract** between teams and tools. Quality comes from **consistent schemas**, **realistic examples**, and **lint rules** that catch breaking changes early.
## When to Offer This Workflow
**Trigger conditions:**
- New REST API; **public** or **partner** surface
- **Codegen** for clients/servers; **API gateway** validation from spec
- **Drift** between docs and implementation
**Initial offer:**
Use **six stages**: (1) workflow choice & ownership, (2) info & versioning, (3) resources & operations, (4) schemas & components, (5) security & errors, (6) lint, compatibility & publish). Confirm **OpenAPI** 3.x and **style guide**.
---
## Stage 1: Workflow & Ownership
**Goal:** **Design-first** (spec → implement) vs **code-first** (annotations → export)—pick one per service and **enforce**.
### Ownership
- **Who** approves breaking changes; **where** spec lives in repo
**Exit condition:** Single source of truth for the API contract.
---
## Stage 2: Info & Versioning
**Goal:** `info.title`, **version** scheme aligned with **URL** or **header** versioning strategy.
### Practices
- **Deprecation** policy in description or extension fields
---
## Stage 3: Resources & Operations
**Goal:** **RESTful** naming where appropriate; **operationId** stable for codegen.
### Practices
- **Pagination** (`cursor`/`page`), **filtering**, **sort** documented
- **Idempotency** (`Idempotency-Key`) for unsafe retries when relevant
---
## Stage 4: Schemas & Components
**Goal:** **`components/schemas`** reused; **nullable** vs **optional** correct in JSON Schema sense.
### Practices
- **OneOf** discriminated unions for polymorphic payloads when needed
- **Examples** per schema for human and machine readers
---
## Stage 5: Security & Errors
**Goal:** **`securitySchemes`** (Bearer, OAuth2) applied per operation or globally.
### Errors
- **Problem Details** (`application/problem+json`) pattern with **stable** `type` URIs
---
## Stage 6: Lint, Compatibility & Publish
**Goal:** **Spectral** or **vacuum** rules in CI; **openapi-diff** on PRs.
### Publish
- **Docs** portal (Swagger UI, Redoc); **postman** collections optional
---
## Final Review Checklist
- [ ] Single ownership and design-first or code-first discipline
- [ ] Versioning and deprecation story clear
- [ ] Operations complete with pagination/errors as needed
- [ ] Reusable components and examples
- [ ] Security and error model consistent
- [ ] CI lint and breaking-change detection
## Tips for Effective Guidance
- **Examples** should be **copy-paste valid**—catch enum drift.
- **Nullable** in OpenAPI 3.1 aligns with JSON Schema—**mind** **3.0** differences when mixing.
- **Internal** APIs still benefit from the same rigor—**future** you is a partner team.
## Handling Deviations
- **GraphQL** elsewhere: OpenAPI for **REST** **edge** only—don’t force one doc for both.