Hono v4（TypeScriptエッジWebフレームワーク）用のCursorプラグイン。BAD/CORRECTペア付きの59件のLLMリグレッション。hono ^4.12.19（CVE-2025-59139対応の>= 4.9.7）に固定。Expressミドルウェアの漏洩、v3時代に削除されたAPI、RPC推論の落とし穴、Cloudflare Workersの注意点、セキュリティのデフォルト設定、JSX SSRの堅牢化をカバー。
Hono v4（TypeScript エッジ Web フレームワーク）+ TypeScript 向けの Cursor プラグイン。hono ^4.12.19、@hono/zod-validator ^0.8.0、@hono/zod-openapi ^1.4.0（peer zod ^4.x）、@hono/node-server ^2.0.3（Node 20+）に固定されています。2024 年より前のデータで学習した LLM が知らない v4 API（c.json() は常に型付き、バリデータは HTTPException をスロー、getCookie/setCookie は hono/cookie から、c.env はプロパティ、streamText は hono/streaming から、showRoutes は hono/dev から、getRuntimeKey は hono/adapter から、fire(app) は hono/service-worker から、Workers Static Assets バインディング（非推奨の serveStatic の代わり）、Deno 用の JSR @hono/hono）を教えます。BAD / CORRECT の TypeScript ペアで 50 以上の LLM の回帰をキャッチします。
Hono v5 は存在しません。 最新の安定版は v4.12.19 です。生成コード内の "v5" はすべて幻覚です。
Hono のメンテナー自身が Issue #3906（"llm.txt file"）と Issue #4812（"Official AI Agent Skill for Hono"）を提出した理由は、まさに 「LLM は最新の Hono の動作をほとんど知らない」 からです。2025 年より前のトレーニングデータは v3 時代のものです。LLM は以下を出力します。
c.jsonT() の代わりに c.json()（v4.0.0 以降は常に型付き）c.stream() / c.streamText() を Context のメソッドとして（v4 で hono/streaming に移動）c.env() 関数形式（現在はプロパティ；ランタイム検出は hono/adapter の getRuntimeKey() を使用）c.req.cookie()（削除されました；hono/cookie の getCookie(c) を使用）app.showRoutes(), app.routerName（hono/dev に移動）addEventListener('fetch') + app.handleEvent()（Service Worker 構文；export default { fetch: app.fetch } を使用）app.head(...) ルート（v4 では HEAD は GET から自動派生）hono/nextjs インポート（hono/vercel を使用）hono/middleware バレルインポート（ミドルウェアごとのサブパスを使用）c.req.headers() / c.req.body() / c.req.signal() アクセサメソッド（c.req.raw.* を使用）FC 暗黙の children 付き（PropsWithChildren<P> を使用）app.fire()（v4.8.0 で非推奨；hono/service-worker の fire(app) を使用）import { Hono } from 'https://deno.land/x/hono/mod.ts'（Deno 上。v4.4.0 以降は古い；jsr:@hono/hono を使用）c.json() に return がない（undefined に解決；v4 では "Context is not finalized" がスローされる）c.json() の代わりに res.json() / res.send()（Hono に res はない）(req, res, next) ミドルウェアシグネチャ（(c, next) を使用）(err, req, res, next) エラーミドルウェア（app.onError + HTTPException を使用）app.use(express.json()) ボディパーサー（Hono は c.req.json() 経由でオンデマンドに解析）import cors from 'cors'（npm から。hono/cors を使用）supertest テスト用（app.request() / testClient(app) を使用）c.req.body をすでに解析済みとして扱う（ReadableStream です）c.req.parseBody() を JSON に使用（フォーム / multipart のみ）c.req.text() の後に c.req.json()（ボディが 2 回消費される）c.userId = ... インライン代入（c.set('userId', ...) と型付き Variables を使用）new Hono() に Bindings / Variables ジェネリクスがない（c.env が {} になる）app.get(...) の後に app.post(...)） - RPC 型が失われるapp.route() 呼び出しを文として定義 - 同じルールContext を渡す（パスパラメータ推論が失われる。Hono ベストプラクティスによる）app.use('/path', zValidator(...)) をルート引数としてではなく使用（TS エラー：'json' は 'never' に代入できません）c.notFound()（クライアント側で型付け不可）new Response(JSON.stringify(...))（クライアントは unknown を受け取る）hc<AppType>('/') 相対 URL（$url() でスロー）drizzle-orm、fs、ネイティブ依存を引きずる - RPC バンドル肥大化の最大の落とし穴）createMiddleware<Env> なしのミドルウェア（Variables 型が伝播しない）process.env.X（undefined；型付き Bindings で c.env.X を使用）fs / path インポート（ファイルシステムなし）compatibility_flags: ["node_compat"] レガシーフラグ（nodejs_compat を使用）hono/cloudflare-workers からの非推奨 serveStatic（v4.3.0 以降；アセットバインディングを使用）c.executionCtx.waitUntil() の欠落（fire-and-forget 用）if (c.executionCtx) の真偽チェック（Bun と Next.js App Router でゲッターがスロー）.run() / .first() / .all()（ワーカー終了時に挿入がキャンセルされる）secureHeaders() ミドルウェアがないcsrf() がないcors({ origin: '*', credentials: true })（ブラウザが静かにドロップ；AJAX が失敗）bodyLimit() がない、かつ hono >= 4.9.7 に固定していない（CVE-2025-59139）httpOnly / secure / sameSite / path なしのクッキーsameSite: 'None' かつ secure: true がない（静かにドロップされる）etag() / cache() がないstreamText の代わりにメモリ内で大きな JSON を構築（Workers の 128MB 上限）notFound ハンドラ（デッドコード；トップレベルのみが発火）/users と /users/ はデフォルトで別のルート）await next() を複数回呼び出す（ダウンストリームの作業が倍になる）app.use(prefix, mw) + app.route(prefix, subApp) の重複（ミドルウェアが 2 回発火）app.basePath('/api') を文として使用（プレフィックスが型から失われる）@hono/node-server で serve(app)（serve({ fetch: app.fetch }) を使用）export default app（export default { fetch: app.fetch } を使用）Bun.serve({ fetch: app })（app.fetch を使用）c.req.query() で単一の値を期待している場合c.req.param('id')（パスに :id がない場合 undefined）@hono/zod-openapi なしの手書き OpenAPIcors()（決して一致しない）cursor.directory と awesome-cursorrules（PR #152）にはすでにいくつかの Hono ルールがあります。これらは c.json() の戻り値、zValidator + Zod、Workers の c.env、RPC のチェーンルート、app.fetch Workers エクスポートをカバーしています。しかし、このプラグインが修正する 3 つの構造的な問題があります。
c.jsonT、c.stream、c.env()、c.req.cookie、app.showRoutes、hono/middleware バレル、app.handleEvent を出力します。これらはすべて v4.0.0（2024-02）で削除されました。既存のルールはそれらを静かに許可します。(req, res, next)、(err, req, res, next)、npm cors、app.use(express.json())、supertest、c.json の return 欠落 - これらはすべて LLM 生成の Hono コードで常に発生します。既存のルールはそれらを一回限りとして扱います。secureHeaders() / csrf() を強制するものはなく、bodyLimit CVE-2025-59139（v4.9.7 で修正）に言及するものもなく、RPC クライアントの落とし穴（相対 URL、値インポートの漏洩、c.notFound の型付け）に対処するものもありません。このプラグインが提供するもの：
globs 付き。ルート / RPC チェックは src/routes/**、Workers チェックは wrangler.{toml,jsonc} + Worker エントリ、セキュリティチェックはミドルウェアファイルなどに発火）/hono-new-route、/hono-rpc-setup、/hono-cloudflare-workers-setup、/hono-migrate-to-v4、/hono-validatecorrect-sample（ゴールドスタンダードの Hono 4.12.19 + Workers + D1 + Drizzle + Zod）と anti-pattern-sample（25 以上の追跡違反がある Hono v3 の後遺症）ルール、スキル、エージェントをプロジェクトの Cursor 設定にコピーします。まず既存のファイルをバックアップしてください。cp -r は同じ名前のルールを上書きします。
git clone https://github.com/RoninForge/roninforge-hono.git
# 既存のカスタマイズされた同じ名前のルールを上書きしないように -n を使用します。
cp -rn roninforge-hono/rules/* your-project/.cursor/rules/
cp -rn roninforge-hono/skills/* your-project/.cursor/skills/
cp -rn roninforge-hono/agents/* your-project/.cursor/agents/
または、リポジトリ全体を your-project/.cursor/plugins/ の下に git サブモジュールとしてベンダー化します。現在の Cursor バージョンのグローバルインストールパスについては、Cursor プラグインドキュメント を参照してください。