Agent skill

Create Platform Adapter

by tsedio in tsedio/tsed

Create a production-ready Ts.ED platform adapter for a new HTTP framework or runtime, such as Hono, Elysia, Bun.serve, or a Node framework.

MITAuto-check passedBackend & APIs

Install Create Platform Adapter

skills CLI
$ npx skills add tsedio/tsed --skill create-platform-adapter -a claude-code

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

GitHub CLI
$ gh skill install tsedio/tsed create-platform-adapter --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/tsedio/tsed.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/create-platform-adapter .claude/skills/create-platform-adapter && 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
create-platform-adapter
GitHub stars
3.1k
Token cost
~2.7k tokens
SKILL.md length
1,199 words
Files
3 (incl. references)
Skills in repo
19
Repo updated
First seen
Licence
MIT

At a glance

Create a production-ready Ts.ED platform adapter for a new HTTP framework or runtime, such as Hono, Elysia, Bun.serve, or a Node framework.

  • Works in 6 steps: Establish feasibility and scope → Inspect local precedents → Create the package → …
  • Adding an @tsed/platform- package
  • SKILL.md covers 1. Establish feasibility and…, 2. Inspect local precedents, 3. Create the package and 4. Implement the adaptations, plus 3 more sections
  • Calls yarn and tsc

What it does

Create Platform Adapter is an agent skill from tsedio/tsed. Create a production-ready Ts.ED platform adapter for a new HTTP framework or runtime, such as Hono, Elysia, Bun.serve, or a Node framework. Use when adding an @tsed/platform- package, porting controller and middleware support to another server framework, or assessing whether a framework can satisfy Ts.ED's platform contract.

Its SKILL.md is about 2.7k tokens, which your agent loads only when the skill is triggered. The skill folder holds 4 other files, including reference files (for example `agents/openai.yaml` and `references/adapter-reference.md`).

It sits in Backend & APIs. It works with Hono and Fastify. The repository describes itself as: :triangularruler: Ts.ED is a Node.js and TypeScript framework on top of Express to write your application with TypeScript (or ES6). It provides a lot of decorators and guideline… The licence is MIT.

When your agent uses it

  • Adding an @tsed/platform- package
  • Porting controller and middleware support to another server framework
  • Assessing whether a framework can satisfy Ts.EDs platform contract

Example prompts

  • “/create-platform-adapter”

Workflow steps

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

  1. Establish feasibility and scope
  2. Inspect local precedents
  3. Create the package
  4. Implement the adaptations
  5. Handle framework boundaries explicitly
  6. Build and run the integration matrix

What it can do on your machine

Read from SKILL.md and the folder at commit 5bea797. 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

    Shell commands in SKILL.md call:

    • yarn
    • tsc

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

  • Network

    No URLs in SKILL.md. Its commands use yarn, which can reach the network depending on how they are called.

    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

Create Platform Adapter loads about 2.7k tokens when it runs, and up to ~4.4k if it reads all its reference files. Until then it costs about 88 tokens; SKILL.md has 1,199 words of instructions outside code blocks.

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

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 tsedio/tsed at commit 5bea797, republished under its MIT licence (© tsedio). 1,199 words, ~2,697 tokens.

Download SKILL.mdSave it as .claude/skills/create-platform-adapter/SKILL.md (or your agent's skills folder). This skill also uses 2 other files; get the full folder from GitHub.
name
create-platform-adapter
description
Create a production-ready Ts.ED platform adapter for a new HTTP framework or runtime, such as Hono, Elysia, Bun.serve, or a Node framework. Use when adding an @tsed/platform-* package, porting controller and middleware support to another server framework, or assessing whether a framework can satisfy Ts.ED's platform contract.
metadata.internal
true

Create Ts.ED Platform Adapter

Build the adapter around Ts.ED's HTTP abstractions, not by copying an existing implementation wholesale. Preserve the target framework's lifecycle and native request/response model.

Read the adapter reference before designing or implementing. It summarizes the repository's Express, Koa, and Fastify patterns and the PlatformAdapter contract.

1. Establish feasibility and scope

  1. Confirm the target runtime can support Ts.ED routing, async middleware, status/headers/cookies, streams or equivalent bodies, error propagation, and a testable HTTP entry point.
  2. Identify whether it is Node IncomingMessage/ServerResponse compatible. For Fetch-native runtimes, explicitly design the bridge instead of pretending Node response mutation works.
  3. Record framework-version support, required plugins, and unsupported Ts.ED features. Do not silently omit multipart uploads, static assets, or serverless callback support.
  4. Do not start or apply an OpenSpec workflow from this skill. The workflow below is the source of truth for the adapter implementation.

2. Inspect local precedents

Read these sources before creating files:

  • packages/platform/platform-http/src/common/services/PlatformAdapter.ts
  • packages/platform/platform-express/src/components/PlatformExpress.ts
  • packages/platform/platform-koa/src/components/PlatformKoa.ts
  • packages/platform/platform-fastify/src/components/PlatformFastify.ts
  • Each package's src/services/, src/utils/convertPath.ts, src/index.ts, package manifest, Vitest config, and focused specs.
  • packages/platform/platform-express/test/platform-express.spec.ts, packages/platform/platform-koa/test/platform-koa.spec.ts, and packages/platform/platform-fastify/test/platform-fastify.spec.ts.
  • docs/introduction/capabilities.md, docs/docs/configuration/{express,koa,fastify}.md, docs/docs/configuration/index.md, docs/index.md, and docs/.vitepress/config.mts.

Choose the closest precedent by execution model: Express for Connect-style middleware, Koa for composed async middleware, Fastify for plugin/route-registration APIs. Reuse intent and coverage, not framework-specific calls.

3. Create the package

Create packages/platform/platform-<framework>/ using a comparable package as a structural template. Adapt, do not blindly duplicate:

  • package.json: ESM exports, build/test/barrel scripts, framework peer dependency, Ts.ED peer dependencies, and only runtime dependencies required by the adapter.
  • tsconfig.esm.json, vitest.config.mts, .npmignore, and package readme.md.
  • src/index.ts: export only the supported public adapter class, settings, decorators, and helpers.
  • test/app/: a minimal server, framework-plugin setup, and shared integration fixtures compatible with PlatformTestSdk.
  • test/platform-<framework>.spec.ts: the explicit @tsed/platform-test-sdk integration capability matrix. This file is mandatory for every new platform; a route-conversion or unit-only test suite is not a substitute.

Keep the framework itself a peer dependency; put it in devDependencies at a pinned test version. The workspace glob already discovers packages/platform/*; only update other package catalogues if a real registry, docs, or release surface needs the entry.

For vitest.config.mts, use the workspace preset import with this explicit type-resolution exception:

typescript
// @ts-ignore
import {presets} from "@tsed/vitest/presets";

Add the new public package alias to both tsconfig.node.json and tsconfig.spec.json. For Fetch-native platforms with native FormData parsing, prefer that API in the platform package and document Multer decorators and storage engines as unsupported; do not create a @tsed/platform-multer/<framework> alias unless the Multer middleware contract is proven compatible.

4. Implement the adaptations

Create Platform<Framework> extends PlatformAdapter<App> with:

  1. NAME, static create() and bootstrap() through PlatformBuilder.
  2. createApp() returning the framework app and a valid request callback. If the framework cannot yield a Node callback, implement and document the appropriate server/runtime boundary.
  3. useContext() that creates a PlatformContext, awaits $ctx.start(), makes it available to mapped handlers, and reliably calls $ctx.finish() when the response completes.
  4. mapLayers() translating PlatformLayer methods, paths, wildcard parameters, statics, and handler ordering to the framework router.
  5. mapHandler() that runs in the Ts.ED DI context, captures async errors, and preserves error-middleware and response-function semantics.
  6. bodyParser(), statics(), server/listening hooks, and framework-specific lifecycle hooks where the base contract requires them.
  7. adapter() bindings for the framework-specific PlatformRequest, PlatformResponse, and PlatformHandler implementations.

Do not expose a framework's raw request/response directly to controllers without adapters. Map all semantics needed by PlatformRequest and PlatformResponse: URL and query, params, protocol and host, cookies/session, status, headers, redirect, body serialization, file/download, stream, and completion state.

5. Handle framework boundaries explicitly

  • Convert Ts.ED route syntax with a framework-specific convertPath() and test named, optional, regexp, and wildcard paths.
  • Preserve the framework's error path. Do not call a Connect next(error) from a Koa/Fastify/Fetch handler unless the target framework actually supports it.
  • Route errors through PlatformExceptions.catch(error, $ctx) and route unknown paths through PlatformExceptions.resourceNotFound($ctx). Reuse the existing exception filters; do not handcraft framework-specific error or 404 response payloads.
  • Register body parsing, multipart support, static serving, view rendering, and raw-body capture only when supported. Make plugin registration awaitable when required. Match PlatformBuilder's global rawBody policy: capture the raw buffer only when rawBody is configured or @RawBodyParams() is detected, while preserving the framework-parsed body. For Fetch-native runtimes, capture it before parsing with request.clone() only when request.body exists; do not globally disable parsing with a per-route parse: "none" strategy. Fall back to body when no raw capture is active.
  • Make HTTP/HTTPS creation and listen() match the framework's ownership model. Confirm the callback works with serverless-http-style consumers if the adapter claims serverless support.
  • Keep framework module augmentation and Ts.ED global declarations narrow and public.
Show full SKILL.md (456 more words)Show less

6. Build and run the integration matrix

After the package and platform adaptations exist, add focused unit tests and create test/platform-<framework>.spec.ts with PlatformTestSdk.create({rootDir, adapter, server}). Build the spec from the Express, Koa, and Fastify precedents, then run it before documenting the platform as supported.

  • Use Express and Koa as the implementation baseline.
  • Use Fastify only to understand framework-specific integration differences; do not copy its skips as an escape hatch.
  • Add the test/app/ fixtures needed by the SDK instead of omitting a scenario.

The following SDK groups are mandatory for every new platform. Keep them enabled, make them pass, and do not wrap them in describe.skip:

  • handlers, childrenControllers, inheritanceController, response, stream, middlewares, scopeRequest, headers, acceptMime, headerParams, pathParams, queryParams, bodyParams, cookies, session, location, redirect, errors, responseFilter, routing, locals, auth, module, and cache.
  • view, statics, deepQueryParams, and custom404.

For Fetch-native platforms, test multipart independently with native FormData and File body parameters. Do not add the SDK Multer suite when Multer's middleware contract is incompatible; document that Multer decorators and storage engines are unavailable.

Iterate on the adapter until the mandatory suite passes. Tackle isolated SDK gaps first (for example custom 404, deep query parsing, framework plugins, and test fixtures). Defer structural Fetch-native response work—stream bridging, response finalization, and Node callback emulation—until those simpler gaps are resolved. Then add coverage for adapter-specific behavior not supplied by the SDK, including bootstrap/create, native callback behavior, route conversion, error propagation, raw body, native multipart, and runtime/server lifecycle.

Update all public documentation in the same change:

  1. Add the framework column and supported/unsupported states to both feature and plugin tables in docs/introduction/capabilities.md; explain limitations below the tables when a marker needs context.
  2. Create docs/docs/configuration/<framework>.md, modeled on the closest adapter page. Cover installation, framework settings/plugins, static files, and use of a custom application instance.
  3. Link the new page from docs/docs/configuration/index.md and add it to the Configuration sidebar in docs/.vitepress/config.mts.
  4. Add the platform and configuration-page link to docs/index.md wherever the existing Express/Koa/Fastify list appears.

Follow this order: create the package; implement the platform adaptations; add the SDK matrix and its fixtures; execute the matrix; iterate on missing framework features until it passes; then run the package tests, yarn tsc -b from the repository root, affected lint checks, and the documentation build. Do not use a package-scoped tsc --build command.

Completion checklist

  • Every mandatory PlatformTestSdk group is enabled and passing; none is skipped.
  • The complete test/platform-<framework>.spec.ts matrix, checked against the Express, Koa, and Fastify precedents, exists and has been executed successfully.
  • Framework capability gaps are documented in capabilities.md, the platform configuration page, navigation, and homepage.
  • PlatformAdapter lifecycle, request/response/handler bindings, and route conversion are covered.
  • Public package metadata, exports, peer dependencies, docs, and integration tests are complete.
  • No Express/Koa/Fastify assumptions remain in the new adapter.

© tsedio, 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 2 other files (references) in .agents/skills/create-platform-adapter of tsedio/tsed.

  • SKILL.md
  • agents/openai.yaml
  • references/adapter-reference.md

Open the folder on GitHubat commit 5bea797

Compare with similar skills

Create Platform Adapter 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.

Create Platform Adapter compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Create Platform Adapter this skilltsedio/tsed3.1k—~2.7kAutomated safety check: PassMIT
Fishjam JS Server SDKsoftware-mansion-labs/skills291—~1.4kAutomated safety check: PassMIT
Workflow Initusenotra/notra255—~821Automated safety check: PassAGPL-3.0
Inngest SetupAsymmetric-al/core382—~3.3kAutomated safety check: NotesAGPL-3.0
SiwaBankrBot/skills1.2k—~379Automated safety check: PassNone
Review Logging Patternsevloghq/evlog1.9k—~11kAutomated safety check: PassMIT

Similar skills

  • Fishjam JS Server SDK

    software-mansion-labs/skills

    Node.js / TypeScript server SDK for Fishjam — backends that create rooms, mint peer tokens, listen to server notifications, and run agents.

    291 GitHub stars~1.4k tokensUpdated 9 days ago
    Backend & APIsAuto-check passed
  • Workflow Init

    usenotra/notra

    Install and configure Vercel Workflow SDK before it exists in nodemodules.

    255 GitHub stars~821 tokensUpdated today
    Backend & APIsAuto-check passed
  • Inngest Setup

    Asymmetric-al/core

    A skill your agent uses when adding durable execution to a TypeScript project — building retry-safe webhook handlers, background jobs that survive crashes, scheduled tasks, or long-running workflows…

    382 GitHub stars~3.3k tokensUpdated today
    Backend & APIsAuto-check: notes
  • Siwa

    BankrBot/skills

    SIWA (Sign-In With Agent) authentication for ERC-8004 registered agents.

    1.2k GitHub stars~379 tokensUpdated 2 days ago
    Backend & APIsAuto-check passed
  • Review code for logging patterns and suggest evlog adoption.

    1.9k GitHub stars~11k tokensUpdated today
    DatabasesAuto-check passed
  • Nodejs Backend Patterns

    ever-works/ever-works

    Build production-ready Node.js backend services with Express/Fastify, implementing middleware patterns, error handling, authentication, database integration, and API design best practices.

    158 GitHub starsUsed in 17 repos~4k tokens
    Backend & APIsAuto-check passed

More from tsedio/tsed

All 19 skills in this repo
  • Tsed CLI

    tsedio/tsed

    Scaffolds Ts.ED v8 projects and generates files with the Ts.ED CLI v7, through its MCP server (tools set-workspace, init-project, list-templates, get-template, generate-file) or the tsed binary…

    3.1k GitHub stars~2.7k tokensUpdated 2 days ago
    Auto-check passed
  • Configure and bootstrap a Ts.ED v8 server - the @Configuration decorator or configuration() on the Server class, PlatformExpress/PlatformKoa/PlatformFastify.bootstrap, server options (mount…

    3.1k GitHub stars~2.1k tokensUpdated 2 days ago
    Auto-check: notes
  • Tsed Di

    tsedio/tsed

    Declare, inject and scope Ts.ED v8 providers and wire lifecycle hooks - @Injectable, @Module, @Controller, @Inject, the functional API (inject, injectMany, lazyInject, constant, refValue…

    3.1k GitHub stars~2.1k tokensUpdated 2 days ago
    Auto-check passed
  • Tsed Docs

    tsedio/tsed

    Locates authoritative Ts.ED v8 documentation and API reference instead of guessing framework APIs.

    3.1k GitHub stars~2.6k tokensUpdated 2 days ago
    Auto-check passed
  • Tsed Logger

    tsedio/tsed

    Configure and use logging in a Ts.ED v8 application with @tsed/logger v8.

    3.1k GitHub stars~2.3k tokensUpdated 2 days ago
    Auto-check passed
  • Tsed MCP Server

    tsedio/tsed

    Expose Model Context Protocol (MCP) tools, resources and prompts from a Ts.ED v8 application with @tsed/platform-mcp, over the application's HTTP endpoint or as a standalone stdio / Streamable HTTP…

    3.1k GitHub stars~2.8k tokensUpdated 2 days ago
    Auto-check passed

Works with

Categories

Questions about Create Platform Adapter

What does Create Platform Adapter do?

Create a production-ready Ts.ED platform adapter for a new HTTP framework or runtime, such as Hono, Elysia, Bun.serve, or a Node framework. Create Platform Adapter is an agent skill from tsedio/tsed.serve, or a Node framework.

When should I use Create Platform Adapter?

Create Platform Adapter fits situations like: adding an @tsed/platform- package; porting controller and middleware support to another server framework; assessing whether a framework can satisfy Ts.EDs platform contract.

How do I install Create Platform Adapter in Claude Code?

Run `npx skills add tsedio/tsed --skill create-platform-adapter -a claude-code`. Or copy the skill folder (.agents/skills/create-platform-adapter in tsedio/tsed) into .claude/skills/create-platform-adapter in your project. Claude Code loads it when a task matches its description.

How do I install Create Platform Adapter in Codex?

Run `npx skills add tsedio/tsed --skill create-platform-adapter -a codex`. Or copy the skill folder (.agents/skills/create-platform-adapter in tsedio/tsed) into .agents/skills/create-platform-adapter in your project. Codex loads it when a task matches its description.

Can I use Create Platform Adapter 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 tsedio/tsed --skill create-platform-adapter -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/create-platform-adapter, .gemini/skills/create-platform-adapter, .github/skills/create-platform-adapter and .opencode/skills/create-platform-adapter in your project.

What does Create Platform Adapter need to run?

Going by SKILL.md and its folder, Create Platform Adapter needs the command-line tools its instructions call (yarn and tsc).

Does Create Platform Adapter access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Create Platform Adapter 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 Create Platform Adapter use?

Create Platform Adapter 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 Create Platform Adapter use?

About 2.7k tokens (SKILL.md is roughly 11k 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 1.7k tokens, read only when the agent opens those files.

What are the alternatives to Create Platform Adapter?

Skills that share tags, products or a category with Create Platform Adapter: Fishjam JS Server SDK (software-mansion-labs/skills, 291 stars), Workflow Init (usenotra/notra, 255 stars), Inngest Setup (Asymmetric-al/core, 382 stars) and Siwa (BankrBot/skills, 1.2k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Create Platform Adapter?

tsedio (a GitHub organization) maintains it in tsedio/tsed, which has 3,087 GitHub stars. The repository holds 19 skills in this directory. The repository was last updated on October 5, 2026.

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