Agent skill

Openapi Spec

by BlueAndi in BlueAndi/Pixelix

Write and update OpenAPI 3.0 specification files from REST API code.

MITAuto-check passedBackend & APIs

Install Openapi Spec

skills CLI
$ npx skills add BlueAndi/Pixelix --skill openapi-spec -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install BlueAndi/Pixelix openapi-spec --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/BlueAndi/Pixelix.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.github/skills/openapi-spec .claude/skills/openapi-spec && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
openapi-spec
GitHub stars
443
Token cost
~3.2k tokens
SKILL.md length
903 words
Files
2 (incl. references)
Skills in repo
7
Repo updated
First seen
Licence
MIT

At a glance

Write and update OpenAPI 3.0 specification files from REST API code.

  • Works in 7 steps: Analyze the REST API Code → Discover All Endpoints → Build the OpenAPI Structure → …
  • : documenting REST endpoints
  • SKILL.md covers When to Use, Ground Rules, Procedure and Output Format, plus 5 more sections
  • Reaches swagger.io

What it does

Openapi Spec is an agent skill from BlueAndi/Pixelix. Write and update OpenAPI 3.0 specification files from REST API code. Use when: documenting REST endpoints, creating API specs, generating swagger.yaml, updating API documentation from implementation.

Its SKILL.md is about 3.2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files, including reference files (for example `references/openapi-template.yaml`).

It sits in Backend & APIs, covering OpenAPI specifications and REST APIs. It works with OpenAPI and ESP32. The repository describes itself as: Full RGB LED matrix, based on an ESP32 and WS2812B LEDs or emulated LEDs on TFT. The licence is MIT.

When your agent uses it

  • : documenting REST endpoints
  • Creating API specs
  • Generating swagger.yaml
  • Updating API documentation from implementation

Example prompts

  • “/openapi-spec”

Workflow steps

7 steps, taken from the step headings in SKILL.md.

  1. Analyze the REST API Code
  2. Discover All Endpoints
  3. Build the OpenAPI Structure
  4. Document Each Endpoint
  5. Extract Response Schemas
  6. Document Authentication
  7. Validate and Refine

What it can do on your machine

Read from SKILL.md and the folder at commit 10209e7. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are yaml, cpp and bash).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • swagger.io

    Also links to:

    • editor.swagger.io

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Openapi Spec loads about 3.2k tokens when it runs, and up to ~3.9k if it reads all its reference files. Until then it costs about 53 tokens; SKILL.md has 903 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~53
When it runs · the whole SKILL.md, loaded when a task matches
~3.2k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~3.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from BlueAndi/Pixelix at commit 10209e7, republished under its MIT licence (© BlueAndi). 903 words, ~3,214 tokens.

Download SKILL.mdSave it as .claude/skills/openapi-spec/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
openapi-spec
description
Write and update OpenAPI 3.0 specification files from REST API code. Use when: documenting REST endpoints, creating API specs, generating swagger.yaml, updating API documentation from implementation.
argument-hint
Describe the API endpoints to document or specify the code files containing REST handlers

OpenAPI 3.0 Specification Writer

When to Use

Load this skill when asked to:

  • Create an OpenAPI/Swagger specification from existing REST API code
  • Document REST endpoints in OpenAPI 3.0 format
  • Update an existing openapi.yaml or swagger.yaml file
  • Generate API documentation that follows OpenAPI 3.0 standards
  • Extract endpoint definitions, parameters, and responses from code

Ground Rules

  • Target specification: OpenAPI 3.0.x (not Swagger 2.0)
  • Output format: YAML (preferred) or JSON
  • Follow OpenAPI 3.0 Specification
  • Include examples for complex schemas
  • Document all response codes actually returned by the implementation

Procedure

1. Analyze the REST API Code
Static Route Registration

Search for and identify:

  • HTTP request handlers and route definitions (e.g., server.on(), route arrays)
  • HTTP methods (GET, POST, PUT, PATCH, DELETE, OPTIONS)
  • Path patterns and parameters (:id, {id}, wildcards)
  • Query parameters from request->getParam() or equivalent
  • Request body parsing (JSON, form data, multipart)
  • Response codes and JSON structures
  • Authentication/authorization requirements
  • Error responses and status codes
Dynamic Route Registration

Some REST APIs use plugin or service architectures where endpoints are registered dynamically:

Common patterns to search for:

  • getTopics() or registerTopics() methods in plugins/services
  • Topic handler or topic registration services
  • Topic constants (e.g., TOPIC_CONFIG, TOPIC_STATUS)
  • Dynamic endpoint builders that construct paths from entity IDs and topic names

Topic-based endpoint patterns:

  • Plugin endpoints: /api/v1/display/uid/{uid}/{topic} or /display/alias/{alias}/{topic}
  • Service endpoints: /api/v1/{entityId}/{topic}
  • System endpoints: /api/v1/{topic} (empty entityId)
  • Indexed endpoints: /api/v1/{entityId}/{index}/{topic}

How to find dynamic endpoints:

  1. Search for getTopics() implementations - these list available topics
  2. Find getTopic() and setTopic() methods - these handle GET/POST requests
  3. Locate topic registration code - shows how topics become REST endpoints
  4. Check for TopicHandlerService or similar dynamic registration systems
  5. Look for topic constants defined in header or source files

Example (C++):

cpp
// Plugin defines topics
const char* TOPIC_CONFIG = "config";
const char* TOPIC_STATUS = "status";

void Plugin::getTopics(JsonArray& topics) const
{
    topics.add(TOPIC_CONFIG);  // Creates GET/POST /display/uid/{uid}/config
    topics.add(TOPIC_STATUS);  // Creates GET/POST /display/uid/{uid}/status
}

bool Plugin::getTopic(const String& topic, JsonObject& value) const
{
    if (topic.equals(TOPIC_CONFIG)) {
        // Handle GET request
    }
}

bool Plugin::setTopic(const String& topic, const JsonObjectConst& value)
{
    if (topic.equals(TOPIC_CONFIG)) {
        // Handle POST request
    }
}
2. Discover All Endpoints

Critical: Don't assume you've found all endpoints after discovering static routes.

Complete discovery workflow:

  1. Static routes: Find route registration arrays or explicit route handlers
  2. Plugin topics: Search for classes implementing plugin interfaces
    • Look for getTopics() implementations
    • Each plugin may expose multiple topics as REST endpoints
  3. Service topics: Search for service classes that register topics
    • Services often register multiple topics (e.g., files, upload, remove)
  4. Topic registration: Find the topic handler or registration service
    • Understand how topics are converted to REST paths
    • Check for path prefix construction (e.g., base + entityId + topic)
  5. Validate completeness: Cross-reference existing OpenAPI spec
    • Check for endpoints in old spec that might still exist
    • Verify each documented endpoint still exists in code
    • Add missing endpoints found in code

Search patterns:

bash
# Find topic definitions
grep -r "TOPIC_" --include="*.cpp" --include="*.h"

# Find getTopics implementations
grep -r "getTopics" --include="*.cpp"

# Find topic handlers
grep -r "getTopic\|setTopic" --include="*.cpp"

# Find topic registration
grep -r "registerTopic" --include="*.cpp"
3. Build the OpenAPI Structure

Start with the base template:

yaml
openapi: 3.0.3
info:
  title: [API Name]
  version: [Version from VERSION constant or git tag]
  description: [Brief API description]
  contact:
    name: [From LICENSE or README]
    email: [If available]

servers:
  - url: http://{host}/rest/api/v1
    description: REST API base path
    variables:
      host:
        default: localhost
        description: Device hostname or IP

paths:
  # Endpoints go here

components:
  schemas:
    # Reusable schemas
  responses:
    # Common responses
  securitySchemes:
    # Auth schemes
4. Document Each Endpoint

For each route/handler found:

yaml
/path/{param}:
  get:
    summary: [One-line description from code comments]
    description: [Detailed behavior from docstrings/comments]
    operationId: [camelCase unique identifier]
    tags:
      - [Logical grouping]
    parameters:
      - name: param
        in: path
        required: true
        schema:
          type: string
        description: [From parameter docs]
      - name: query
        in: query
        required: false
        schema:
          type: integer
        description: [From code inspection]
    responses:
      '200':
        description: Success
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/SuccessResponse'
            example:
              status: "ok"
              data: {}
      '400':
        $ref: '#/components/responses/BadRequest'
      '404':
        $ref: '#/components/responses/NotFound'
5. Extract Response Schemas

From JSON response building code, create reusable schemas:

yaml
components:
  schemas:
    SuccessResponse:
      type: object
      required:
        - status
        - data
      properties:
        status:
          type: string
          enum: [ok]
        data:
          type: object
          description: Endpoint-specific response data
    
    ErrorResponse:
      type: object
      required:
        - status
        - msg
      properties:
        status:
          type: string
          enum: [error]
        msg:
          type: string
          description: Human-readable error message
6. Document Authentication

If authentication is present:

yaml
components:
  securitySchemes:
    basicAuth:
      type: http
      scheme: basic
      description: HTTP Basic Authentication

# Then apply to protected endpoints:
paths:
  /protected:
    get:
      security:
        - basicAuth: []
7. Validate and Refine
  • Check that all paths start with /
  • Verify all $ref references exist
  • Ensure required fields are present
  • Add examples for complex request/response bodies
  • Group related endpoints with tags
  • Document error responses consistently

Output Format

Save the specification as:

  • docs/openapi.yaml or docs/swagger.yaml (YAML preferred)
  • docs/api-spec.yaml (alternative naming)

Include a comment header:

yaml
# OpenAPI 3.0.3 Specification
# Generated from: [source files]
# Last updated: [date]
# See: https://swagger.io/docs/specification/v3_0/

Common Patterns

REST API with CRUD Operations
yaml
/items:
  get:
    summary: List all items
    responses:
      '200':
        description: Array of items
  post:
    summary: Create new item
    requestBody:
      required: true
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ItemCreate'
    responses:
      '201':
        description: Item created

/items/{id}:
  get:
    summary: Get single item
  put:
    summary: Update item
  delete:
    summary: Delete item
Query Parameters
yaml
parameters:
  - name: limit
    in: query
    schema:
      type: integer
      minimum: 1
      maximum: 100
      default: 20
  - name: offset
    in: query
    schema:
      type: integer
      minimum: 0
      default: 0
File Upload
yaml
requestBody:
  content:
    multipart/form-data:
      schema:
        type: object
        properties:
          file:
            type: string
            format: binary
          path:
            type: string

Common Pitfalls & Lessons Learned

File Paths vs Numeric IDs

Issue: APIs may use numeric IDs internally instead of file paths.

Example:

yaml
# WRONG - assumes API uses file paths
parameters:
  - name: iconPath
    schema:
      type: string
    example: "/images/icon.bmp"

# CORRECT - API uses numeric file IDs
parameters:
  - name: iconFileId
    schema:
      type: number
    example: 1234

How to identify: Check the actual implementation - look for FileId types, ID resolution methods like getFileFullPathById(), or file manager services that map IDs to paths.

Show full SKILL.md (351 more words)Show less
Missing Dynamic Endpoints

Issue: Forgetting to document endpoints that are registered dynamically via plugin/service systems.

Solution:

  1. Don't rely only on static route definitions
  2. Search for getTopics(), registerTopics(), or similar methods
  3. Check for topic registration services that create REST endpoints
  4. Look for topic handler implementations
  5. Verify each plugin/service that registers topics

Example: In Pixelix, sensor endpoints (/sensors/{index}/{channelName}) are created dynamically by SensorDataProvider registering topics via TopicHandlerService, not found in static route arrays.

Path Pattern Consistency

Issue: API paths may have multiple formats depending on registration method.

Check for:

  • Service endpoints: /{serviceId}/{topic}
  • Plugin endpoints by UID: /display/uid/{uid}/{topic}
  • Plugin endpoints by alias: /display/alias/{alias}/{topic}
  • Indexed endpoints: /{entityId}/{index}/{topic}
  • System endpoints: /{topic} (no prefix)
Parameter Types from Code

Issue: Documentation doesn't match actual parameter types used in code.

Verify:

  • Check actual JSON key names in getTopic()/setTopic() implementations
  • Confirm data types (string, number, boolean, array, object)
  • Note optional vs required parameters
  • Check for parameter validation rules (min/max, enums)
Configuration vs Command Topics

Issue: Some topics serve dual purposes.

Pattern:

  • Config topics: GET returns current config, POST updates and persists config
  • Command topics: GET returns status, POST executes actions with action parameter
  • Status topics: GET only, returns current state

Example:

yaml
# Command topic - action-based
/display/uid/{uid}/playCtrl:
  post:
    parameters:
      - name: action
        schema:
          type: string
          enum: [next, previous, pause, continue]

Tips

  • Use $ref for reusability: Common responses and schemas should be defined once in components
  • Include examples: Especially for complex nested objects
  • Document all response codes: Even error cases (400, 401, 403, 404, 500)
  • Add operation IDs: Unique, descriptive operationId for code generation tools
  • Group with tags: Logical grouping improves generated documentation (e.g., by plugin name or service name)
  • Version properly: Use info.version matching your API versioning scheme
  • Add curl examples: Include practical curl command examples in endpoint descriptions to show authentication and parameter usage
  • Consistency matters: Keep response schemas, error formats, and authentication patterns consistent across all endpoints
  • Trace the implementation: Don't guess parameter types or structures - read the actual code that builds JSON responses

Validation

After generating the spec, validate it using:

  • Swagger Editor - paste YAML to check for errors
  • swagger-cli validate openapi.yaml - CLI validation
  • VS Code OpenAPI extensions for real-time validation

References

© BlueAndi, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file (references) in .github/skills/openapi-spec of BlueAndi/Pixelix.

  • SKILL.md
  • references/openapi-template.yaml

Open the folder on GitHubat commit 10209e7

Compare with similar skills

Openapi Spec next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Openapi Spec compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Openapi Spec this skillBlueAndi/Pixelix443—~3.2kAutomated safety check: PassMIT
API DesignerJeffallan/claude-skills12k2 repos~2kAutomated safety check: PassMIT
OpenAPI to MCP Servermcp-use/mcp-use11k—~5.2kAutomated safety check: PassApache-2.0
Use Yaakmountain-loop/yaak19k—~1.9kAutomated safety check: PassMIT
Old Coder API DesignAmazingAng/old-coder7491 repos~3.4kAutomated safety check: PassMIT
API CallerNVIDIA/SkillEvaluator5441 repos~1.1kAutomated safety check: PassApache-2.0

Similar skills

  • API Designer

    Jeffallan/claude-skills

    Designs REST and GraphQL APIs from resource modeling to an OpenAPI 3.1 contract, with versioning, pagination and RFC 7807 error handling.

    12k GitHub starsUsed in 2 repos~2k tokens
    Backend & APIsAuto-check passed
  • OpenAPI to MCP Server

    mcp-use/mcp-use

    Turns an OpenAPI or Swagger spec into an MCP server with the mcp-use TypeScript SDK, mapping each operation to a tool, wiring auth, testing and deploying.

    11k GitHub stars~5.2k tokensUpdated yesterday
    Backend & APIsAuto-check passed
  • Use Yaak

    mountain-loop/yaak

    A skill your agent uses when the user mentions Yaak, a Yaak workspace, or the yaak command, or asks to call, hit, or smoke test HTTP/REST endpoints, save or organize API requests for reuse or manual…

    19k GitHub stars~1.9k tokensUpdated today
    Backend & APIsAuto-check passed
  • Old Coder API Design

    AmazingAng/old-coder

    Reviews or designs an HTTP/JSON API's endpoints, auth, pagination, versioning and deprecations, guarding against inventing a bespoke interface or silently breaking consumers.

    749 GitHub starsUsed in 1 repo~3.4k tokens
    Backend & APIsAuto-check passed
  • API Caller

    NVIDIA/SkillEvaluator

    Official

    Call any REST API dynamically. An agent skill from NVIDIA/SkillEvaluator.

    544 GitHub starsUsed in 1 repo~1.1k tokens
    Backend & APIsAuto-check passed
  • API Generating

    huangjia2019/claude-code-engineering

    Generate API endpoint code and documentation from specifications.

    1.1k GitHub starsUsed in 1 repo~379 tokens
    Backend & APIsAuto-check passed

More from BlueAndi/Pixelix

  • Openscad Mechanical

    BlueAndi/Pixelix

    Create and edit OpenSCAD (.scad) files for 3D-printable mechanical parts and housings.

    443 GitHub stars~1.8k tokensUpdated yesterday
    Auto-check passed
  • Plantuml Diagrams

    BlueAndi/Pixelix

    Model, create, update, and embed PlantUML diagrams (.wsd files).

    443 GitHub stars~1.2k tokensUpdated yesterday
    Auto-check passed
  • Bootstrap Reference

    BlueAndi/Pixelix

    A skill your agent uses when building or reviewing UI with Bootstrap 5.3 — setting up the CDN/npm, using the grid & breakpoints, utility classes (spacing/color/flex/display), components (navbar…

    443 GitHub stars~2k tokensUpdated yesterday
    Auto-check passed
  • Embedded Cpp14 Misra

    BlueAndi/Pixelix

    Write and refactor embedded C/C++14 code with MISRA-oriented rules, defensive programming, Yoda conditions, pathfinder rule, mandatory Doxygen, and clang-format compliance.

    443 GitHub stars~936 tokensUpdated yesterday
    Auto-check passed
  • Html5 Reference

    BlueAndi/Pixelix

    A skill your agent uses when authoring, reviewing, or validating HTML markup — choosing the right element, deciding what may nest inside what, writing forms/inputs, adding accessible semantics, or…

    443 GitHub stars~2.3k tokensUpdated yesterday
    Auto-check passed
  • Javascript Reference

    BlueAndi/Pixelix

    A skill your agent uses when writing, reviewing, or debugging JavaScript — reasoning about type coercion, equality, this, closures, scope/hoisting, prototypes, async/promises, iterators, modules, or…

    443 GitHub stars~2.4k tokensUpdated yesterday
    Auto-check passed

Works with

Categories

Questions about Openapi Spec

What does Openapi Spec do?

Write and update OpenAPI 3.0 specification files from REST API code. Openapi Spec is an agent skill from BlueAndi/Pixelix.0 specification files from REST API code.

When should I use Openapi Spec?

Openapi Spec fits situations like: : documenting REST endpoints; creating API specs; generating swagger.yaml; updating API documentation from implementation.

How do I install Openapi Spec in Claude Code?

Run `npx skills add BlueAndi/Pixelix --skill openapi-spec -a claude-code`. Or copy the skill folder (.github/skills/openapi-spec in BlueAndi/Pixelix) into .claude/skills/openapi-spec in your project. Claude Code loads it when a task matches its description.

How do I install Openapi Spec in Codex?

Run `npx skills add BlueAndi/Pixelix --skill openapi-spec -a codex`. Or copy the skill folder (.github/skills/openapi-spec in BlueAndi/Pixelix) into .agents/skills/openapi-spec in your project. Codex loads it when a task matches its description.

Can I use Openapi Spec in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add BlueAndi/Pixelix --skill openapi-spec -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/openapi-spec, .gemini/skills/openapi-spec, .github/skills/openapi-spec and .opencode/skills/openapi-spec in your project.

What does Openapi Spec need to run?

SKILL.md names no scripts, command-line tools or credentials: Openapi Spec is instructions for the agent only.

Does Openapi Spec access the network?

SKILL.md names 2 domains. In commands or code: swagger.io; the agent is likely to contact it when it follows the instructions. As links in the text: editor.swagger.io. This is read from the text; nothing was executed.

Is Openapi Spec safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Openapi Spec use?

Openapi Spec is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Openapi Spec use?

About 3.2k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 722 tokens, read only when the agent opens those files.

What are the alternatives to Openapi Spec?

Skills that share tags, products or a category with Openapi Spec: API Designer (Jeffallan/claude-skills, 12k stars), OpenAPI to MCP Server (mcp-use/mcp-use, 11k stars), Use Yaak (mountain-loop/yaak, 19k stars) and Old Coder API Design (AmazingAng/old-coder, 749 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Openapi Spec?

BlueAndi (a GitHub user) maintains it in BlueAndi/Pixelix, which has 443 GitHub stars. The repository holds 7 skills in this directory. The repository was last updated on October 6, 2026.

Source: BlueAndi/Pixelix on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.