From xonovex-skill-hono
Use when editing or scaffolding Hono 4.0+ API servers in TypeScript. Triggers on `.ts` files with `hono` or `@hono/*` imports, route handlers, middleware, and prompts about validation, error handling, WebSockets, CORS, or building an HTTP API in Hono — even when the user doesn't say 'Hono'.
How this skill is triggered — by the user, by Claude, or both
Slash command
/xonovex-skill-hono:hono-guideThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
- Hono ≥ 4.0, @hono/node-server, @hono/zod-validator, TypeScript ≥ 5.8
SOURCES.mdevals.jsonreferences/application-structure.mdreferences/context-storage.mdreferences/cookie-handling.mdreferences/error-handling.mdreferences/middleware-combine.mdreferences/middleware-patterns.mdreferences/platform-runtime.mdreferences/security-middleware.mdreferences/validation-type-safety.mdreferences/websocket-support.mdc.req.valid boundary; schema design in zod-guide, see references/validation-type-safety.mdsome()/every()/except(), see references/middleware-patterns.md, references/middleware-combine.mdthis binding, see references/websocket-support.mdsecureHeaders() for security headers, see references/security-middleware.mdenv(c) for environment, getRuntimeKey() for detection, see references/platform-runtime.mdimport {Hono} from "hono";
import {secureHeaders} from "hono/secure-headers";
export function createApp() {
const app = new Hono();
app.use("*", secureHeaders());
app.route("/api/v1", v1Router);
return app;
}
c.req.valid('json') is typed by inference only when zValidator is chained inline on the route; an imported base-Context controller sees any, so cast there — but that cast is unchecked and can hide schema driftenv(c) is the portable way to read env vars across runtimes — process.env works on Node but not Workers/Denothis from the closing object — assigning the handler to a variable loses the bindingnpx claudepluginhub xonovex/platform --plugin xonovex-skill-honoGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Resolves in-progress git merge or rebase conflicts by analyzing history, understanding intent, and preserving both changes where possible. Runs automated checks after resolution.