菜单
Audits an OpenAPI JSON spec (Redocly lint, OpenAPI version, FFS style guide, copy rules). Read-only — no file edits. Use when the user invokes /api-eval or asks to evaluate or audit an API spec.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | api-eval |
| description | Audits an OpenAPI JSON spec (Redocly lint, OpenAPI version, FFS style guide, copy rules). Read-only — no file edits. Use when the user invokes /api-eval or asks to evaluate or audit an API spec. |
/api-eval — Audit OpenAPI spec/api-eval, "evaluate API spec", or "audit OpenAPI".Resolve target spec — Follow _shared/resolve-api-spec.md. Print **Target spec:** \path`` in the output header.
Layer 1 — Redocly lint — Run:
npm run lint:openapi -- <resolved-path>
List every error/warning with path/line. Tag each as api-fix-eligible (→ fix with /api-fix).
Layer 2 — Structure — Load api-ref-structure.mdc. Flag section order, missing license, broken $ref, duplicate schema names. Tag as api-fix-eligible.
Layer 3 — OpenAPI version — Read openapi field. Audit 3.0 vs 3.1 rules per api-ref-schema.mdc ($ref, type arrays, anyOf/null). Flag issues lint may miss.
Layer 4 — FFS style guide — Load api-ref-ffs-styleguide.mdc and ffs-styleguide-checklist.md. Flag significant contract inconsistencies only.
Layer 5 — Documentation — Load api-ref-copy, api-ref-examples, api-ref-tags-errors. Check descriptions, examples, tags, public-facing text (no Jira/FFENT/codenames).
Output format
api-fix-eligible)api-fix-eligible)/api-review for full catalog/api-fix = lint + api-ref-structure; copy/style = /api-review or update refs N,M,…Fixes Redocly lint errors and api-ref-structure.mdc inconsistencies on an OpenAPI JSON spec. Use when the user invokes /api-fix or asks to fix API lint or structure issues. Does not apply FFS style guide or copy fixes.
Catalogs user-readable OpenAPI text in ref-numbered tables with possible issues and proposed content. Read-only unless user asks to update specific refs. Use when the user invokes /api-review or asks to review API descriptions.
Stages all working-tree changes with git add -A, then commits with a message that follows the repository user’s Git commit rules (short imperative subject, blank line, body bullets with 📖/✏️). Use when the user invokes /gc or the gc skill, asks to “gc”, or asks to stage everything and commit with the project commit-message format.
Stages all changes with git add -A, drafts a commit message per the user’s Git commit rules, prints it for review, then waits for the user to edit the message and choose (1) commit or (2) reject. Use when the user invokes /gcam or the gcam skill, asks for stage-all with review before commit, or interactive commit with approve/reject.