hjemmesidekongen/openapi-typescript
plugins/smedjen/skills/openapi-typescript/SKILL.md
OpenAPI code generation, type-safe API clients, schema validation, and contract-first development. Covers openapi-typescript, openapi-fetch, zod-openapi, breaking change detection, and CI integration.
tools
Updated Apr 5, 2026
$ install --global
skillsauthnpx skillsauth add hjemmesidekongen/ai openapi-typescriptInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 5, 2026, 5:29 PM14.3s2 files scanned
SKILL.md
- name:
- openapi-typescript
- description:
- >
- user_invocable:
- false
- interactive:
- false
- model_tier:
- senior
- depends_on:
- []
- reads:
- []
- writes:
- []
- type:
- data_validation
- - name:
- schema_validation_at_boundary
- verify:
- Runtime validation (zod-openapi or typebox) is applied at the API boundary, not assumed
- fail_action:
- Add a validation layer — generated types are compile-time only, not runtime guarantees
- on_fail:
- Contract integrity has gaps — fix before shipping
- on_pass:
- OpenAPI contract is type-safe and CI-enforced
- origin:
- smedjen
- inspired_by:
- original
- ported_date:
- 2026-03-10
- iteration:
- 1
- changes:
- Original skill, no port
openapi-typescript
The spec is the contract. Generate types from it — never write them by hand. If the spec and the types drift, every downstream assumption silently breaks.
Contract-First Approach
Write (or own) the OpenAPI spec before writing any implementation. The spec defines the surface area: request shapes, response shapes, error variants, auth requirements. Code should conform to the spec, not the other way around.
Spec-first wins: schema is the source of truth, clients and servers share one contract, breaking changes are detectable before they ship, mock servers are derivable from the spec alone.
Code Generation Workflow
Pipeline: openapi.yaml → openapi-typescript → schema.d.ts → openapi-fetch client → typed call sites.
Run generation as a script, not manually. Check the diff in CI — if generated output changes unexpectedly, the build fails. This catches spec drift before it reaches consumers.
Type Safety Strategy
openapi-typescript generates a paths object and component types. openapi-fetch consumes paths and infers request/response types from the path key + method — no casting, no any.
For runtime safety, pair with zod-openapi or @sinclair/typebox to derive Zod or JSON Schema validators from the same spec. This closes the gap between compile-time types and actual API responses.
Key Rules
- Generated files are artifacts, not source. Commit them only if the team needs them for offline use; otherwise generate on install.
- Never cast response data to a generated type — validate it. Types are promises the compiler accepts; validation is the runtime proof.
- Breaking changes (removed fields, narrowed types, changed required status) must go through a versioning strategy — path versioning (
/v2/) or header versioning. - If a field is optional in the spec, treat it as absent at call sites until the validation layer confirms it.
- Mocks derived from the spec (e.g.,
msw-auto-mock, Prism) keep tests honest without a live server.
See references/process.md for full package usage, schema validation patterns, versioning strategies, breaking change detection, mock server setup, CI integration, and anti-patterns.
Related Skills
hjemmesidekongen/brand-strategy
development
VerifiedTrustedCommunity
Creates a brand from scratch through market research and interactive sparring. Runs competitive research via Perplexity, then guides the user through positioning, audience, voice, values, and content pillars. Produces the full brand guideline set at .ai/brand/{name}/. Use when building a new brand, defining brand strategy for a product, or when /våbenskjold:create is invoked.
SKILL.mdUpdated Apr 5, 2026
hjemmesidekongen/brand-loader
testing
VerifiedTrustedCommunity
Loads brand guidelines from .ai/brand/{name}/ and makes them available to the current context. Progressive disclosure: L1 confirms brand exists, L2 loads summary, L3 loads specific files on demand. Use when a downstream skill or user needs brand context, or when /våbenskjold:apply is invoked.
SKILL.mdUpdated Apr 5, 2026
hjemmesidekongen/brand-evolve
documentation
VerifiedTrustedCommunity
Guided reinvention of an existing brand guideline. Loads current brand from .ai/brand/{name}/, identifies what to keep vs change, and walks the user through targeted evolution. Preserves brand equity while updating positioning, voice, or values. Use when refreshing a brand or when /våbenskjold:evolve is invoked.
SKILL.mdUpdated Apr 5, 2026
hjemmesidekongen/brand-audit
development
VerifiedTrustedCommunity
Codifies an existing brand from materials, samples, and references. Analyzes provided content to extract voice patterns, values, and positioning. Produces the same guideline format as brand-strategy. Use when a brand already exists but isn't documented, or when /våbenskjold:audit is invoked.
SKILL.mdUpdated Apr 5, 2026