Token导航 LogoToken导航TokenDH.com
前端设计需要联网github未标认证来源可访问许可证需确认审计通过

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

Agent Skill

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

总安装

9,495

周安装

384

GitHub Stars

1,183

下载量

3,041
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 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

简介

create-evlog-framework-integration 用于向 evlog 日志库添加新的框架中间件集成,如 Express、Fastify 等。

  • 它强制完成所有 touchpoint:创建源文件、更新构建配置、修改 package.json 导出声明。
  • 适用于日志系统扩展和多框架兼容需求,确保新增集成不影响现有功能。
  • PR 标题建议使用 feat({framework}): add {Framework} middleware integration 格式提交。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

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 extractorextractSafeHeaders for Web API Headers, extractSafeNodeHeaders for Node.js IncomingHttpHeaders
  3. Spread user options into createMiddlewareLoggerdrain, 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 logiccallEnrichAndDrain 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 HandlingcreateError() + parseError() + framework error handler
  5. Drain & Enrichers — middleware options with inline example
  6. Pipeline (Batching & Retry)createDrainPipeline example
  7. Tail Samplingkeep callback
  8. Route Filteringinclude / 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 routecreateError() 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

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

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