Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
hugorcd avatar

Create Evlog Framework Integration

  • 485 installs
  • 1.7k repo stars
  • Updated August 4, 2026
  • hugorcd/evlog

create-evlog-framework-integration is a contributor agent skill that scaffolds all mandatory files for a new evlog HTTP framework middleware integration for developers adding structured wide-event logging to Express, Hon

About

create-evlog-framework-integration is a hugorcd/evlog agent skill for contributors adding a new framework integration to the evlog structured logging library. Every integration follows shared architecture on createMiddlewareLogger from evlog/toolkit, with manifest mode via defineFrameworkIntegration covering roughly 80% of (ctx, next) middleware frameworks in about 30 lines of glue code. The skill mandates 11 touchpoints: integration source under packages/evlog/src, tsdown build config, package.json exports, tests, framework docs page, overview and installation cards, landing snippet, FeatureFrameworks.vue tab, README section, and public SKILL.md updates. Developers reach for it when evlog lacks built-in support for their HTTP framework and they need the same drain, enrich, keep, and tail-sampling pipeline as Hono, Express, Fastify, Elysia, NestJS, or SvelteKit integrations.

  • Generates full evlog framework integration in one command
  • Produces structured logging, correlation IDs, and context enrichment
  • Creates ready-to-use logger modules with multiple output handlers
  • Includes observability instrumentation and error tracking setup
  • Delivers configuration templates and example usage patterns

Create Evlog Framework Integration by the numbers

  • 485 all-time installs (skills.sh)
  • +5 installs in the week ending Aug 2, 2026 (Skillselion tracking)
  • Ranked #420 of 2,715 Automation & Workflows skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/hugorcd/evlog --skill create-evlog-framework-integration

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs485
repo stars1.7k
Last updatedAugust 4, 2026
Repositoryhugorcd/evlog

How do you add a new evlog framework integration?

Instantly scaffold a complete event logging framework with structured logging, context enrichment, and observability hooks that works with any agent workflow.

Who is it for?

evlog contributors or maintainers adding middleware logging support for an HTTP framework using the library's shared toolkit primitives.

Skip if: Application developers who only need to install existing evlog integrations without contributing new framework adapters to the monorepo.

When should I use this skill?

A new HTTP framework needs evlog middleware support and the contributor must hit every mandatory monorepo touchpoint without skipping files.

What you get

Integration source file, tests, package exports, docs pages, README section, and PR-ready feat({framework}) middleware integration.

  • Framework integration source
  • Test file
  • Documentation pages

By the numbers

  • Requires 11 mandatory monorepo touchpoints per new integration
  • Manifest mode covers about 80% of middleware frameworks in roughly 30 lines

Files

SKILL.mdMarkdownGitHub ↗

Create evlog Adapter

Add a new built-in adapter to evlog. Every adapter follows the same architecture and is built on the public toolkit primitives in evlog/toolkit — so a community adapter has the same shape as a built-in one.

PR Title

Recommended format for the pull request title:

feat: add {name} adapter

The exact wording may vary depending on the adapter (e.g., feat: add OTLP adapter, feat: add Axiom drain adapter), but it should always follow the feat: conventional commit prefix.

Touchpoints Checklist

#FileAction
1packages/evlog/src/adapters/{name}.tsCreate adapter source (built on defineHttpDrain from ../shared/drain)
2packages/evlog/tsdown.config.tsAdd build entry
3packages/evlog/package.jsonAdd exports + typesVersions entries
4packages/evlog/test/adapters/{name}.test.tsCreate tests
5apps/docs/content/4.adapters/{n}.{name}.mdCreate adapter doc page (before custom.md)
6apps/docs/content/4.adapters/1.overview.mdAdd adapter to overview (links, card, env vars)
7skills/review-logging-patterns/SKILL.mdAdd adapter row in the Drain Adapters table
8Renumber custom.mdEnsure custom.md stays last after the new adapter

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

Naming Conventions

Use these placeholders consistently:

PlaceholderExample (Datadog)Usage
{name}datadogFile names, import paths, env var suffix
{Name}DatadogPascalCase in function/interface names
{NAME}DATADOGSCREAMING_CASE in env var prefixes

Standard option naming (use these exact names):

ConceptStandard option name
Bearer-style API secretapiKey
Base URL of the ingest APIendpoint
Service identifierserviceName
Request timeout (ms)timeout

If a service historically used a different name (token, sourceToken, …) keep it as a deprecated alias — see Axiom and Better Stack for the pattern.

Step 1: Adapter Source — built on defineHttpDrain

Create packages/evlog/src/adapters/{name}.ts. Read references/adapter-template.md for the full annotated template.

The contract is now defineHttpDrain<TConfig>({ resolve, encode }). You only ship two pieces of logic:

1. `resolve()` — produce a fully-resolved config or null to skip. Use resolveAdapterConfig for the standard precedence (overrides → runtimeConfig.evlog.{name}runtimeConfig.{name} → env vars). List NUXT_{NAME}_* before {NAME}_* in ConfigField.env for silent Nuxt compat; show only {NAME}_* in user-facing messages via formatPublicEnvKeys. 2. `encode(events, config)` — produce { url, headers, body } for a batch of events (or null to skip). HTTP transport, retries, timeout, and error logging are handled by defineHttpDrain.

Key rules:

  • Single factory. Export one create{Name}Drain(overrides?: Partial<{Name}Config>). No dual-API factories: if a service has multiple ingest modes (logs vs events), expose them via a mode option (see PostHog).
  • No HTTP code in the adapter. Don't call fetch directly — let defineHttpDrain do it. If your service truly needs custom transport (e.g. binary envelopes), use defineDrain and call httpPost from evlog/toolkit.
  • No bespoke config resolution. Always go through resolveAdapterConfig. If you need to support a deprecated alias (tokenapiKey), include both in the ConfigField[] and fall through in resolve().
  • Exported converters. If the service needs a specific event shape, export a to{Name}Event() (or buildPayload()) helper so it can be tested independently.

Step 2: Build Config

Add a build entry in packages/evlog/tsdown.config.ts alongside the existing adapters:

'adapters/{name}': 'src/adapters/{name}.ts',

Place it after the last adapter entry in tsdown.config.ts (follow existing ordering in that file).

Step 3: Package Exports

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

In `exports` (after the last adapter, currently ./posthog):

"./{name}": {
  "types": "./dist/adapters/{name}.d.mts",
  "import": "./dist/adapters/{name}.mjs"
}

*In `typesVersions[""]`** (after the last adapter):

"{name}": [
  "./dist/adapters/{name}.d.mts"
]

Step 4: Tests

Create packages/evlog/test/adapters/{name}.test.ts.

Read references/test-template.md for the full annotated template.

Required test categories:

1. URL construction (default + custom endpoint) 2. Headers (auth, content-type, service-specific) 3. Request body format (JSON structure matches service API) 4. Skip behavior when apiKey (or required field) is missing 5. Batch operations 6. Deprecated alias still works (when applicable)

Step 5: Adapter Documentation Page

Create apps/docs/content/4.adapters/{n}.{name}.md where {n} is the next number before custom.md (custom should always be last).

Use the existing Axiom adapter page (apps/docs/content/4.adapters/2.axiom.md) as a reference for frontmatter structure, tone, and sections. Key sections: intro, quick setup, configuration (env vars table + priority), advanced usage, querying in the target service, troubleshooting, direct API usage, next steps.

Important: multi-framework examples. The Quick Start section must include a ::code-group with tabs for all supported frameworks (Nuxt/Nitro, Hono, Express, Fastify, Elysia, NestJS, Standalone). Do not only show Nitro examples. See any existing adapter page for the pattern.

Step 6: Update Adapters Overview Page

Edit apps/docs/content/4.adapters/1.overview.md to add the new adapter in three places (follow the pattern of existing adapters):

1. Frontmatter `links` array — add a link entry with icon and path 2. `::card-group` section — add a card block before the Custom card 3. Zero-Config Setup `.env` example — add the adapter's env vars

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

In skills/review-logging-patterns/SKILL.md (the public skill distributed to users), find the Drain Adapters table and add a new row:

| {Name} | `evlog/{name}` | `{NAME}_API_KEY`, `{NAME}_DATASET` (or equivalent) |

Follow the pattern of the existing rows (Axiom, OTLP, PostHog, Sentry, Better Stack).

Step 8: Renumber custom.md

If the new adapter's number conflicts with custom.md, renumber custom.md to be the last entry. For example, if the new adapter is 5.{name}.md, rename 5.custom.md to 6.custom.md.

Verification

After completing all steps, run:

cd packages/evlog
pnpm run lint
pnpm run typecheck
pnpm run test
pnpm run build

Related skills

How it compares

Pick create-evlog-framework-integration over generic logging guides when contributing a new built-in adapter to the evlog monorepo with full docs and export wiring.

FAQ

How many touchpoints does create-evlog-framework-integration require?

create-evlog-framework-integration mandates 11 touchpoints including integration source, tsdown build entry, package.json exports, tests, framework docs, overview cards, landing snippet, Vue feature tab, README, and public skill updates.

When should create-evlog-framework-integration use manifest mode?

create-evlog-framework-integration recommends defineFrameworkIntegration manifest mode for standard (ctx, next) HTTP middleware frameworks, producing about 30 lines of glue while createMiddlewareLogger handles drain, enrich, keep, and tail sampling.

Automation & Workflowsintegrationsbackend

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.