How this skill is triggered — by the user, by Claude, or both
Slash command
/oastools:fix-specThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Always start with a dry run to see what would change:
Always start with a dry run to see what would change:
{
"spec": {"file": "<path>"},
"dry_run": true
}
Include any specific fix flags the user requested:
fix_schema_names -- Rename generic names like Object1, Model2 to meaningful namesfix_duplicate_operationids -- Deduplicate operationId valuesprune -- Remove empty paths and unused schemasstub_missing_refs -- Create stub schemas for missing $ref targetsIf no specific flags are given, the tool applies the default fix (missing path parameters).
Show the user a clear summary of planned fixes:
Results are paginated (default limit: 100). When returned < fix_count, there are more fixes:
{"spec": {"file": "<path>"}, "dry_run": true, "offset": 100, "limit": 100}
✅ Page through all fixes so the user gets a complete picture before confirming. Group fixes by type for readability (e.g., "842 missing path parameters, 12 duplicate operationIds").
Ask the user to confirm before proceeding. If they want to exclude certain fixes, adjust the flags accordingly.
Run the fix tool without dry_run, using output to write the result to disk:
{
"spec": {"file": "<path>"},
"output": "<output-path>",
"fix_schema_names": true
}
⚠️ Important: The fix tool does not modify the input file. Without output, the fixed document only exists in the response (when include_document: true). Always use output to persist the result for subsequent steps.
For in-place updates, set output to the same path as the input file. Add "include_document": true if the user also wants to see the full corrected spec in the response.
Run the validate tool on the output file from step 3:
{"spec": {"file": "<output-path>"}}
Report the final validation status. If new issues were introduced, investigate and explain them.
Provide a final summary:
npx claudepluginhub erraggy/oastools --plugin oastoolsStructures OpenAPI 3.x specs with consistent naming, reusable schemas, error modeling, pagination, security schemes, and examples to produce a spec that works as a contract for code generation.
Generates and validates OpenAPI specifications from codebase. Covers endpoint design, schema validation, and documentation generation.
Guides OpenAPI spec writing with best practices on naming conventions, complex patterns like polymorphism, enums, file uploads, server-sent events, and reusability for quality SDKs.