Token导航 LogoToken导航

Agent Skill · 前端设计

create-evlog-framework-integration(创建 evlog 框架集成)

create-evlog-framework-integration 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

create-evlog-framework-integration 是前端设计类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为需要联网;许可证信息还不明确,第三方扫描已通过,按安装量在前端设计类的 10,216 个 Skill 里排第 937。

总安装 9,495周安装 384GitHub Stars 1,183下载 3,041核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:create-evlog-framework-integration(创建 evlog 框架集成)
来源仓库:https://github.com/hugorcd/evlog
仓库路径:skills/create-evlog-framework-integration
安装命令:
npx skills add https://github.com/hugorcd/evlog --skill create-evlog-framework-integration
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/hugorcd/evlog --skill create-evlog-framework-integration

这个 Skill 是做什么的

前端设计类 Skill 关注页面结构、视觉规范和组件写法,输出通常是可运行的界面代码。

create-evlog-framework-integration 用于向 evlog 日志库添加新的框架中间件集成,如 Express、Fastify 等。它强制完成所有 touchpoint:创建源文件、更新构建配置、修改 package.json 导出声明。

适用于日志系统扩展和多框架兼容需求,确保新增集成不影响现有功能。PR 标题建议使用 feat({framework}): add {Framework} middleware integration 格式提交。

适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:skills/create-evlog-framework-integration

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/hugorcd/evlog --skill create-evlog-framework-i…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

create-evlog-framework-integration 怎么安装?

在终端执行 npx skills add https://github.com/hugorcd/evlog --skill create-evlog-framework-integration。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

create-evlog-framework-integration 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

create-evlog-framework-integration 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

create-evlog-framework-integration 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

create-evlog-framework-integration 用的人多吗?

公开数据是累计安装 9,495 次,近一周安装 384 次,下载 3,041 次,GitHub 1,183 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

create-evlog-framework-integration 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。
  • 来源仓库有 1,183 星,维护活跃度相对可查。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理前端设计类任务、又不想每次都手写提示词的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

前端设计类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
frontend-design

前端设计 · Codex、Claude

8,823,360126,072只读MIT通过
vercel-composition-patterns

Vercel 组合模式 · Codex、Claude

3,858,81625,893需要联网MIT通过
vercel-react-native-skills

Vercel React native skills 前端 · Codex、Claude

2,468,66425,878只读MIT通过
adapt

adapt 搜索 · Codex、Claude

2,027,04023,125操作浏览器未明确通过
bolder

bolder 分析 · Codex、Claude

2,004,28823,130只读未明确通过
create-evlog-framework-integration

创建 evlog 框架集成 · 本页

9,4951,183需要联网未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Create evlog Framework Integration

Add a new framework integration to evlog. Every integration follows the same architecture built on the shared createMiddlewareLogger utility. This skill walks through all touchpoints. Every single touchpoint is mandatory -- do not skip any.

PR Title

Recommended format for the pull request title:

feat({framework}): add {Framework} middleware integration

Touchpoints Checklist

#FileAction
1packages/evlog/src/{framework}/index.tsCreate integration source
2packages/evlog/tsdown.config.tsAdd build entry + external
3packages/evlog/package.jsonAdd exports + typesVersions + peer dep + keyword
4packages/evlog/test/{framework}.test.tsCreate tests
5apps/docs/content/2.frameworks/{NN}.{framework}.mdCreate framework docs page
6apps/docs/content/2.frameworks/00.overview.mdAdd card + table row
7apps/docs/content/1.getting-started/2.installation.mdAdd card in "Choose Your Framework"
8apps/docs/content/0.landing.mdAdd framework code snippet
9apps/docs/app/components/features/FeatureFrameworks.vueAdd framework tab
10skills/review-logging-patterns/SKILL.mdAdd framework setup section + update frontmatter description
11packages/evlog/README.mdAdd framework section + add row to Framework Support table
12examples/{framework}/Create example app with test UI
13package.json (root)Add example:{framework} script
14.changeset/{framework}-integration.mdCreate changeset (minor)
15.github/workflows/semantic-pull-request.ymlAdd {framework} scope
16.github/pull_request_template.mdAdd {framework} scope

Important: Do NOT consider the task complete until all 16 touchpoints have been addressed.

Naming Conventions

Use these placeholders consistently:

PlaceholderExample (Hono)Usage
{framework}honoDirectory names, import paths, file names
{Framework}HonoPascalCase in type/interface names

Shared Utilities

All integrations share the same core utilities. Never reimplement logic that exists in shared/. These are also publicly available as evlog/toolkit for community-built integrations (see Custom Integration docs).

UtilityLocationPurpose
createMiddlewareLogger../shared/middlewareFull lifecycle: logger creation, route filtering, tail sampling, emit, enrich, drain
extractSafeHeaders../shared/headersConvert Web API Headers → filtered Record<string, string> (Hono, Elysia, etc.)
extractSafeNodeHeaders../shared/headersConvert Node.js IncomingHttpHeaders → filtered Record<string, string> (Express, Fastify, NestJS)
BaseEvlogOptions../shared/middlewareBase user-facing options type with drain, enrich, keep, include, exclude, routes
MiddlewareLoggerOptions../shared/middlewareInternal options type extending BaseEvlogOptions with method, path, requestId, headers
createLoggerStorage../shared/storageFactory returning {storage, useLogger} for AsyncLocalStorage-backed useLogger()

Test Helpers

UtilityLocationPurpose
createPipelineSpies()test/helpers/frameworkCreates mock drain/enrich/keep callbacks
assertDrainCalledWith()test/helpers/frameworkValidates drain was called with expected event shape
assertEnrichBeforeDrain()test/helpers/frameworkValidates enrich runs before drain
assertSensitiveHeadersFiltered()test/helpers/frameworkValidates sensitive headers are excluded
assertWideEventShape()test/helpers/frameworkValidates standard wide event fields

Step 1: Integration Source

Create packages/evlog/src/{framework}/index.ts.

The integration file should be minimal — typically 50-80 lines of framework-specific glue. All pipeline logic (enrich, drain, keep, header filtering) is handled by createMiddlewareLogger.

Template Structure

import type { RequestLogger } from '../types'
import { createMiddlewareLogger, type BaseEvlogOptions } from '../shared/middleware'
import { extractSafeHeaders } from '../shared/headers'       // for Web API Headers (Hono, Elysia)
// OR
import { extractSafeNodeHeaders } from '../shared/headers'    // for Node.js headers (Express, Fastify)
import { createLoggerStorage } from '../shared/storage'

const { storage, useLogger } = createLoggerStorage(
  'middleware context. Make sure the evlog middleware is registered before your routes.',
)

export interface Evlog{Framework}Options extends BaseEvlogOptions {}

export { useLogger }

// Type augmentation for typed logger access (framework-specific)
// For Express: declare module 'express-serve-static-core' { interface Request { log: RequestLogger } }
// For Hono: export type EvlogVariables = { Variables: { log: RequestLogger } }

export function evlog(options: Evlog{Framework}Options = {}): FrameworkMiddleware {
  return async (frameworkContext, next) => {
    const { logger, finish, skipped } = createMiddlewareLogger({
      method: /* extract from framework context */,
      path: /* extract from framework context */,
      requestId: /* extract x-request-id or crypto.randomUUID() */,
      headers: extractSafeHeaders(/* framework request Headers object */),
      ...options,
    })

    if (skipped) {
      await next()
      return
    }

    // Store logger in framework-specific context
    // e.g., c.set('log', logger) for Hono
    // e.g., req.log = logger for Express

    // Wrap next() in AsyncLocalStorage.run() for useLogger() support
    // Express: storage.run(logger, () => next())
    // Hono: await storage.run(logger, () => next())
  }
}

Reference Implementations

  • Hono (~40 lines): packages/evlog/src/hono/index.ts — Web API Headers, c.set('log', logger), wraps next() in try/catch
  • Express (~80 lines): packages/evlog/src/express/index.ts — Node.js headers, req.log, res.on('finish'), AsyncLocalStorage for useLogger()
  • Elysia (~70 lines): packages/evlog/src/elysia/index.ts — Web API Headers, derive() plugin, onAfterHandle/onError, AsyncLocalStorage for useLogger()

Key Architecture Rules

  1. Use createMiddlewareLogger — never call createRequestLogger directly
  2. Use the right header extractor — extractSafeHeaders for Web API Headers, extractSafeNodeHeaders for Node.js IncomingHttpHeaders
  3. Spread user options into createMiddlewareLogger — drain, enrich, keep are handled automatically by finish()
  4. Store logger in the framework's idiomatic context (e.g., c.set() for Hono, req.log for Express, .derive() for Elysia)
  5. Export useLogger() — backed by AsyncLocalStorage so the logger is accessible from anywhere in the call stack
  6. Call finish() in both success and error paths — it handles emit + enrich + drain
  7. Re-throw errors after finish() so framework error handlers still work
  8. Export options interface with drain/enrich/keep for feature parity across all frameworks
  9. Export type helpers for typed context access (e.g., EvlogVariables for Hono)
  10. Framework SDK is a peer dependency — never bundle it
  11. Never duplicate pipeline logic — callEnrichAndDrain is internal to createMiddlewareLogger

Framework-Specific Patterns

Hono: Use MiddlewareHandler return type, c.set('log', logger), c.res.status for status, c.req.raw.headers for headers.

Express: Standard (req, res, next) middleware, res.on('finish') for response end, storage.run(logger, () => next()) for useLogger(). Type augmentation targets express-serve-static-core (NOT express). Error handler uses ErrorRequestHandler type.

Elysia: Return new Elysia({name: 'evlog'}) plugin, use .derive({as: 'global'}) to create logger and attach log to context, onAfterHandle for success path, onError for error path. Use storage.enterWith(logger) in derive for useLogger() support. Note: onAfterResponse is fire-and-forget and may not complete before app.handle() returns in tests — use onAfterHandle instead.

Fastify: Use fastify-plugin wrapper, fastify.decorateRequest('log', null), onRequest/onResponse hooks.

NestJS: NestInterceptor with intercept(), tap()/catchError() on observable, forRoot() dynamic module.

Step 2: Build Config

Add a build entry in packages/evlog/tsdown.config.ts:

'{framework}/index': 'src/{framework}/index.ts',

Place it after the existing framework entries (workers, next, hono, express).

Also add the framework SDK to the external array:

external: [
  // ... existing externals
  '{framework-package}',  // e.g., 'elysia', 'fastify', 'express'
],

Step 3: Package Exports

In packages/evlog/package.json, add four entries:

In exports (after the last framework entry):

"./{framework}": {
  "types": "./dist/{framework}/index.d.mts",
  "import": "./dist/{framework}/index.mjs"
}

**In typesVersions["*"]**:

"{framework}": [
  "./dist/{framework}/index.d.mts"
]

In peerDependencies (with version range):

"{framework-package}": "^{latest-major}.0.0"

In peerDependenciesMeta (mark as optional):

"{framework-package}": {
  "optional": true
}

In keywords — add the framework name to the keywords array.

Step 4: Tests

Create packages/evlog/test/{framework}.test.ts.

Import shared test helpers from ./helpers/framework:

import {
  assertDrainCalledWith,
  assertEnrichBeforeDrain,
  assertSensitiveHeadersFiltered,
  createPipelineSpies,
} from './helpers/framework'

Required test categories:

  1. Middleware creates logger — verify c.get('log') or req.log returns a RequestLogger
  2. Auto-emit on response — verify event includes status, method, path, duration
  3. Error handling — verify errors are captured and event has error level + error details
  4. Route filtering — verify skipped routes don't create a logger
  5. Request ID forwarding — verify x-request-id header is used when present
  6. Context accumulation — verify logger.set() data appears in emitted event
  7. Drain callback — use assertDrainCalledWith() helper
  8. Enrich callback — use assertEnrichBeforeDrain() helper
  9. Keep callback — verify tail sampling callback receives context and can force-keep logs
  10. Sensitive header filtering — use assertSensitiveHeadersFiltered() helper
  11. Drain/enrich error resilience — verify errors in drain/enrich do not break the request
  12. Skipped routes skip drain/enrich — verify drain/enrich are not called for excluded routes
  13. useLogger() returns same logger — verify useLogger() === req.log (or framework equivalent)
  14. useLogger() throws outside context — verify error thrown when called without middleware
  15. useLogger() works across async — verify logger accessible in async service functions

Use the framework's test utilities when available (e.g., Hono's app.request(), Express's supertest, Fastify's inject()).

Step 5: Framework Docs Page

Create apps/docs/content/2.frameworks/{NN}.{framework}.md with a comprehensive, self-contained guide.

Use zero-padded numbering ({NN}) to maintain correct sidebar ordering. Check existing files to determine the next number.

Frontmatter:

---
title: {Framework}
description: Using evlog with {Framework} — automatic wide events, structured errors, drain adapters, enrichers, and tail sampling in {Framework} applications.
navigation:
  title: {Framework}
  icon: i-simple-icons-{framework}
links:
  - label: Source Code
    icon: i-simple-icons-github
    to: https://github.com/HugoRCD/evlog/tree/main/examples/{framework}
    color: neutral
    variant: subtle
---

Sections (follow the Express/Hono/Elysia pages as reference):

  1. Quick Start — install + register middleware (copy-paste minimum setup)
  2. Wide Events — progressive log.set() usage
  3. useLogger() — accessing logger from services without passing req
  4. Error Handling — createError() + parseError() + framework error handler
  5. Drain & Enrichers — middleware options with inline example
  6. Pipeline (Batching & Retry) — createDrainPipeline example
  7. Tail Sampling — keep callback
  8. Route Filtering — include / exclude / routes
  9. Client-Side Logging — HTTP drain (evlog/http) (only if framework has a client-side story)
  10. Run Locally — clone + bun run example:{framework}
  11. Card group linking to GitHub source

Step 6: Overview & Installation Cards

In apps/docs/content/2.frameworks/00.overview.md:

  1. Add a row to the Overview table with framework name, import, type, logger access, and status
  2. Add a :::card in the appropriate section (Full-Stack or Server Frameworks) with color: neutral

In apps/docs/content/1.getting-started/2.installation.md:

  1. Add a :::card in the "Choose Your Framework" ::card-group with color: neutral
  2. Place it in the correct order relative to existing frameworks (Nuxt, Next.js, SvelteKit, Nitro, TanStack Start, NestJS, Express, Hono, Fastify, Elysia, CF Workers)

Step 7: Landing Page (unchanged)

Add a code snippet in apps/docs/content/0.landing.md for the framework.

Find the FeatureFrameworks MDC component usage (the section with #nuxt, #nextjs, #hono, #express, etc.) and add a new slot:

  #{framework}

// Framework-specific code example showing evlog usage

Place the snippet in the correct order relative to existing frameworks.

Step 8: FeatureFrameworks Component

Update apps/docs/app/components/features/FeatureFrameworks.vue:

  1. Add the framework to the frameworks array with its icon and the next available tab index
  2. Add a <div v-show="activeTab === {N}"> with <slot name="{framework}" /> in the template
  3. Increment tab indices for any frameworks that come after the new one

Icons use Simple Icons format: i-simple-icons-{name} (e.g., i-simple-icons-express, i-simple-icons-hono).

Step 9: Update skills/review-logging-patterns/SKILL.md

In skills/review-logging-patterns/SKILL.md (the public skill distributed to users):

  1. Add ### {Framework} in the "Framework Setup" section, after the last existing framework entry and before "Cloudflare Workers"
  2. Include:

- Import + initLogger + middleware/plugin setup - Logger access in route handlers (req.log, c.get('log'), or { log } destructuring) - useLogger() snippet with a short service function example - Full pipeline example showing drain, enrich, and keep options

  1. Update the description: line in the YAML frontmatter to mention the new framework name

Step 10: Update packages/evlog/README.md

In the root packages/evlog/README.md:

  1. Add a ## {Framework} section after the Elysia section (before ## Browser), with a minimal setup snippet and a link to the example app
  2. Add a row to the "Framework Support" table:
| **{Framework}** | `{registration pattern}` with `import { evlog } from 'evlog/{framework}'` ([example](./examples/{framework})) |

Keep the snippet short — just init, register/use middleware, and one route handler showing logger access. No need to repeat drain/enrich/keep here.

Step 11: Example App

Create examples/{framework}/ with a runnable app that demonstrates all evlog features.

The app must include:

  1. evlog() middleware with drain (PostHog) and enrich callbacks
  2. Health route — basic log.set() usage
  3. Data route — context accumulation with user/business data, using useLogger() in a service function
  4. Error route — createError() with status/why/fix/link
  5. Error handler — framework's error handler with parseError() + manual log.error()
  6. Test UI — served at /, a self-contained HTML page with buttons to hit each route and display JSON responses

Drain must use PostHog (createPostHogDrain() from evlog/posthog). The POSTHOG_API_KEY env var is already set in the root .env. This ensures every example tests a real external drain adapter.

Pretty printing should be enabled so the output is readable when testing locally.

Type the enrich callback parameter explicitly — use type EnrichContext from evlog to avoid implicit any:

import { type EnrichContext } from 'evlog'

app.use(evlog({
  enrich: (ctx: EnrichContext) => {
    ctx.event.runtime = 'node'
  },
}))

Test UI

Every example must serve a test UI at GET / — a self-contained HTML page (no external deps) that lets the user click routes and see responses without curl.

The UI must:

  • List all available routes with method badge + path + description
  • Send the request on click and display the JSON response with syntax highlighting
  • Show status code (color-coded 2xx/4xx/5xx) and response time
  • Use a dark theme with monospace font
  • Be a single .ts file (src/ui.ts) exporting a testUI() function returning an HTML string
  • The root / route must be registered before the evlog middleware so it doesn't get logged

Reference: examples/hono/src/ui.ts for the canonical pattern. Copy and adapt for each framework.

Required files

FilePurpose
src/index.tsApp with all features demonstrated
src/ui.tsTest UI — testUI() returning self-contained HTML
package.jsondev and start scripts
tsconfig.jsonTypeScript config (if needed)
README.mdHow to run + link to the UI

Package scripts

{
  "scripts": {
    "dev": "bun --watch src/index.ts",
    "start": "bun src/index.ts"
  }
}

Step 12: Root Package Script

Add a root-level script in the monorepo package.json:

"example:{framework}": "dotenv -- turbo run dev --filter=evlog-{framework}-example"

The dotenv -- prefix loads the root .env file (containing POSTHOG_API_KEY and other adapter keys) into the process before turbo starts. Turborepo does not load .env files — dotenv-cli handles this at the root level so individual examples need no env configuration.

Step 13: Changeset

Create .changeset/{framework}-integration.md:

---
"evlog": minor
---

Add {Framework} middleware integration (`evlog/{framework}`) with automatic wide-event logging, drain, enrich, and tail sampling support

Step 15 & 16: PR Scopes

Add the framework name as a valid scope in both files so PR title validation passes:

.github/workflows/semantic-pull-request.yml — add {framework} to the scopes list:

scopes: |
  # ... existing scopes
  {framework}

.github/pull_request_template.md — add {framework} to the Scopes section:

- {framework} ({Framework} integration)

Verification

After completing all steps, run from the repo root:

cd packages/evlog
bun run build    # Verify build succeeds with new entry
bun run test     # Verify unit tests pass
bun run lint     # Verify no lint errors

Then type-check the example:

cd examples/{framework}
npx tsc --noEmit  # Verify no TS errors in the example

平台分布

Codex

37.95%
按下载量换算1,154

Claude

28.68%
按下载量换算872

Cursor

19.06%
按下载量换算580

Gemini CLI

8.44%
按下载量换算257

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills