vercel-labs / emulate

The always-on emulate skill covers the CLI itself: starting some or all of the services, seeding data through a YAML or JSON config, and wiring the whole thing into a test suite or CI run with no network access. Eleven more skills are per-service reference guides — apple, aws, github, google, linear, microsoft, resend, slack, stripe, twilio, and vercel — each documenting that one API's local emulation: OAuth and OIDC flows for the identity providers, S3/SQS/IAM for AWS, checkout and webhooks for Stripe, and so on. The last two, next and nuxt, are framework adapters for embedding the emulators directly inside a Next.js or Nuxt app instead of running them as a separate process.

This is for a team writing integration tests or a CI pipeline that talks to Vercel, GitHub, Google, Slack, Apple, Microsoft, AWS, Resend, Stripe, Twilio, or Linear, and wants production-shaped responses without live credentials or network access. All fourteen skills are local-tool: nothing here needs a stored API key, which fits the emulator's whole premise of standing in for the real service.

READ THE FULL ANALYSIS＋

Three emulated services have no matching skill. The CLI itself also stands up Okta, MongoDB Atlas, and Clerk — the README lists all three with their own default ports, and Clerk is even named in the emulate skill's own description — but none of the three gets a dedicated skill file the way the other eleven services do; an agent has to fall back on the general emulate skill or the README itself to use them.

The README frames this as testing infrastructure, not a skills package. Its own pitch is local drop-in replacement services for CI and no-network sandboxes, and the fourteen skills exist to let a skills-aware agent discover and drive that CLI rather than as a separate feature — the same emulator ships equally as a plain npm package or a programmatic API for anyone not using an agent at all.