원클릭으로
validate-spec
Validate an OpenAPI spec, explain errors clearly, and suggest or apply fixes
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Validate an OpenAPI spec, explain errors clearly, and suggest or apply fixes
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Prepare a release (phases 1-6). Usage: /prepare-release [version]. If version omitted, infers from conventional commits. Coordinates agents for review, runs prepare-release.sh, then enhances release notes with rich formatting.
Run corpus regression tests against real-world OpenAPI specs. Usage: /corpus-test [short]
Generate test scaffolding for a Go file following oastools conventions. Usage: /gen-test <file.go> [function names...]
Review unpushed commits before pushing for code quality, bugs, security issues, and error handling. Use when preparing to push commits, want pre-push code review, or need to validate changes before pushing. Runs comprehensive analysis using specialized review agents.
Publish a prepared release (phase 7). Usage: /publish-release <version>. Requires version argument. Wraps publish-release.sh for deterministic execution.
Run full validation suite (make check + gopls diagnostics) and report structured pass/fail. Usage: /quality-gate [package...]
SOC 직업 분류 기준
| name | validate-spec |
| description | Validate an OpenAPI spec, explain errors clearly, and suggest or apply fixes |
Call the validate tool on the user's spec:
{"spec": {"file": "<path>"}}
If the user wants strict validation, add "strict": true.
⚠️ Tip for large specs: Use "no_warnings": true for initial triage. Large specs can produce hundreds of warnings that obscure the actual errors. Get the error picture first, then run again without no_warnings to review warnings separately.
If the spec is valid:
no_warnings was set)If the spec has errors:
$ref targets)Results are paginated (default limit: 100). When returned < error_count, there are more errors:
{"spec": {"file": "<path>"}, "offset": 100, "limit": 100}
⚠️ Strategy for large error sets: Analyze the first page for patterns — if errors are repetitive (e.g., hundreds of missing path parameters), summarize the pattern and total count rather than paging through all of them. Only page further when errors appear diverse or the user needs specifics.
For each error, explain how to fix it. Common patterns:
| Error type | Suggested fix |
|---|---|
| Missing path parameter | Add the parameter to the operation's parameters array |
| Duplicate operationId | Rename to be unique, following a verb+resource pattern |
Invalid $ref target | Fix the reference path, or stub the missing schema |
| Missing required field | Add the field with an appropriate value |
If the errors are auto-fixable, offer to run the fix tool:
{"spec": {"file": "<path>"}, "dry_run": true}
Show the user the planned fixes before applying. ✅ When applying, use output to persist:
{"spec": {"file": "<path>"}, "output": "<output-path>"}
⚠️ The fix tool does not modify the input file. Without output, the fixed document is not persisted to disk.
After any changes, ✅ run validate on the output file (not the original input):
{"spec": {"file": "<output-path>"}}
Report the final status.