Agent skill

Benchmarking

by garden-co in garden-co/classic-jazz

A skill your agent uses when writing or running performance benchmarks for Jazz packages.

MITAuto-check passedTesting & QA

Install Benchmarking

skills CLI
$ npx skills add garden-co/classic-jazz --skill benchmarking -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install garden-co/classic-jazz benchmarking --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/garden-co/classic-jazz.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.cursor/skills/benchmarking .claude/skills/benchmarking && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
benchmarking
GitHub stars
2.5k
Token cost
~3.2k tokens
SKILL.md length
694 words
Files
1
Skills in repo
8
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when writing or running performance benchmarks for Jazz packages.

  • Works in 4 steps: Use node --experimental-strip-types, NOT… → before/after hooks MUST be async or… → test() can be sync or async → …
  • Running performance benchmarks for Jazz packages
  • SKILL.md covers When to Use This Skill, Do NOT Use This Skill For, Directory Structure and File Naming, plus 5 more sections
  • Calls pnpm and node

What it does

Benchmarking is an agent skill from garden-co/classic-jazz. Use this skill when writing or running performance benchmarks for Jazz packages. Covers cronometro setup, file conventions, gotchas with worker threads, and how to compare implementations.

Its SKILL.md is about 3.2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Testing & QA. It works with npm. The repository describes itself as: A new kind of database that's distributed across your frontend, containers, serverless functions and its own storage cloud. The licence is MIT.

When your agent uses it

  • Running performance benchmarks for Jazz packages

Example prompts

  • “/benchmarking”

Workflow steps

4 steps, taken from the step headings in SKILL.md.

  1. Use node --experimental-strip-types, NOT tsx
  2. before/after hooks MUST be async or accept a callback
  3. test() can be sync or async
  4. TypeScript constraints under --experimental-strip-types

What it can do on your machine

Read from SKILL.md and the folder at commit 4f90501. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • pnpm
    • node

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • github.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Benchmarking loads about 3.2k tokens when it runs. Until then it costs about 50 tokens; SKILL.md has 694 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~50
When it runs · the whole SKILL.md, loaded when a task matches
~3.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from garden-co/classic-jazz at commit 4f90501, republished under its MIT licence (© garden-co). 694 words, ~3,184 tokens.

Download SKILL.mdSave it as .claude/skills/benchmarking/SKILL.md (or your agent's skills folder).
name
benchmarking
description
Use this skill when writing or running performance benchmarks for Jazz packages. Covers cronometro setup, file conventions, gotchas with worker threads, and how to compare implementations.

Writing Benchmarks

When to Use This Skill

  • Comparing implementations: Measuring old vs new approach after an optimization
  • Regression testing: Verifying a refactor doesn't degrade performance
  • Comparing with published version: Benchmarking workspace code against the latest published npm package

Do NOT Use This Skill For

  • General app-level performance optimization (use jazz-performance)
  • Profiling or debugging slow user-facing behavior

Directory Structure

All benchmarks live in the bench/ directory at the repository root:

bench/
├── package.json              # Dependencies: cronometro, cojson, jazz-tools, vitest
├── jazz-tools/               # jazz-tools benchmarks
│   └── *.bench.ts

File Naming

Benchmark files follow the pattern: <subject>.<operation>.bench.ts

Each file should focus on a single benchmark comparing multiple implementations (e.g., @latest vs @workspace).

Examples:

  • comap.create.jazz-tools.bench.ts — benchmarks CoMap creation
  • filestream.getChunks.bench.ts — benchmarks FileStream.getChunks()
  • filestream.asBase64.bench.ts — benchmarks FileStream.asBase64()
  • binaryCoStream.write.bench.ts — benchmarks binary stream writes

Benchmark Library: cronometro

Benchmarks use cronometro, which runs each test in an isolated worker thread for accurate measurement.

Basic Template
ts
import cronometro from "cronometro";

const TOTAL_BYTES = 5 * 1024 * 1024;
let data: SomeType;

await cronometro(
  {
    "operation - @latest": {
      async before() {
        // Setup — runs once before the test iterations
        data = prepareTestData(TOTAL_BYTES);
      },
      test() {
        // The code being benchmarked — runs many times
        latestImplementation(data);
      },
      async after() {
        // Cleanup — runs once after all iterations
        cleanup();
      },
    },
    "operation - @workspace": {
      async before() {
        data = prepareTestData(TOTAL_BYTES);
      },
      test() {
        workspaceImplementation(data);
      },
      async after() {
        cleanup();
      },
    },
  },
  {
    iterations: 50,
    warmup: true,
    print: {
      colors: true,
      compare: true,
    },
    onTestError: (testName: string, error: unknown) => {
      console.error(`\nError in test "${testName}":`);
      console.error(error);
    },
  },
);
Single Cronometro Instance Per Benchmark

Each benchmark file should have a single cronometro() call that compares multiple implementations of the same operation. This makes results easier to read and compare:

ts
import cronometro from "cronometro";

const TOTAL_BYTES = 5 * 1024 * 1024;
let data: InputType;

await cronometro(
  {
    "operationName - @latest": {
      async before() {
        data = generateInput(TOTAL_BYTES);
      },
      test() {
        latestImplementation(data);
      },
      async after() {
        cleanup();
      },
    },
    "operationName - @workspace": {
      async before() {
        data = generateInput(TOTAL_BYTES);
      },
      test() {
        workspaceImplementation(data);
      },
      async after() {
        cleanup();
      },
    },
  },
  {
    iterations: 50,
    warmup: true,
    print: { colors: true, compare: true },
    onTestError: (testName: string, error: unknown) => {
      console.error(`\nError in test "${testName}":`);
      console.error(error);
    },
  },
);

Key principles:

  • One file = one benchmark (e.g., getChunks, asBase64, write)
  • One cronometro call comparing @latest vs @workspace (or old vs new)
  • Fixed data size at the top of the file (e.g., const TOTAL_BYTES = 5 * 1024 * 1024)
  • Descriptive test names with format "operation - @implementation"
Comparing workspace vs published package

To compare current workspace code against the latest published version:

1. Add npm aliases to bench/package.json:

json
{
  "dependencies": {
    "cojson": "workspace:*",
    "cojson-latest": "npm:cojson@0.20.7",
    "jazz-tools": "workspace:*",
    "jazz-tools-latest": "npm:jazz-tools@0.20.7"
  }
}

Then run pnpm install in bench/.

2. Import both versions:

ts
import * as localTools from "jazz-tools";
import * as latestPublishedTools from "jazz-tools-latest";
import { WasmCrypto as LocalWasmCrypto } from "cojson/crypto/WasmCrypto";
import { WasmCrypto as LatestPublishedWasmCrypto } from "cojson-latest/crypto/WasmCrypto";

3. Use @ts-expect-error when passing the published package since the types won't match the workspace version:

ts
ctx = await createContext(
  // @ts-expect-error version mismatch
  latestPublishedTools,
  LatestPublishedWasmCrypto,
);
Benchmarking with a Jazz context

When benchmarking CoValues (not standalone functions), create a full Jazz context. Use this helper pattern:

ts
async function createContext(tools: typeof localTools, wasmCrypto: typeof LocalWasmCrypto) {
  const ctx = await tools.createJazzContextForNewAccount({
    creationProps: { name: "Bench Account" },
    peers: [],
    crypto: await wasmCrypto.create(),
    sessionProvider: new tools.MockSessionProvider(),
  });
  return { account: ctx.account, node: ctx.node };
}

Key points:

  • Pass peers: [] — benchmarks don't need network sync
  • Use MockSessionProvider — avoids real session persistence
  • Call (ctx.node as any).gracefulShutdown() in after() to clean up
Test data strategy

Define a fixed data size constant at the top of the file, then generate test data inside the before hook:

ts
const TOTAL_BYTES = 5 * 1024 * 1024; // 5MB

let chunks: Uint8Array[];

await cronometro({
  "operationName - @workspace": {
    async before() {
      chunks = makeChunks(TOTAL_BYTES, CHUNK_SIZE);
    },
    test() {
      doWork(chunks);
    },
  },
}, options);

Choose a size large enough to measure meaningfully. Small data (e.g., 100KB) may complete so fast that measurement noise dominates. 5MB is typically a good default for file/stream operations.

All fixture generation must be done inside the before hook, not at module level. This ensures data is created in the same worker thread that runs the test.

Running Benchmarks

Add a script entry to bench/package.json:

json
{
  "scripts": {
    "bench:mytest": "node --experimental-strip-types --no-warnings ./jazz-tools/mytest.jazz-tools.bench.ts"
  }
}

Then run from the bench/ directory:

sh
cd bench
pnpm run bench:mytest

Critical Gotchas

1. Use node --experimental-strip-types, NOT tsx

Cronometro spawns worker threads that re-import the benchmark file. Workers don't inherit tsx's custom ESM loader, so the TypeScript import fails silently and the benchmark hangs forever.

Use node --experimental-strip-types --no-warnings instead:

json
"bench:foo": "node --experimental-strip-types --no-warnings ./jazz-tools/foo.bench.ts"
Show full SKILL.md (268 more words)Show less
2. before/after hooks MUST be async or accept a callback

Cronometro's lifecycle hooks expect either:

  • An async function (returns a Promise)
  • A function that accepts and calls a callback parameter

A plain synchronous function that does neither will silently prevent the test from ever starting, causing the benchmark to hang indefinitely:

ts
// BAD — test never starts, benchmark hangs
{
  before() {
    data = generateInput();  // sync, no callback, no promise
  },
  test() { ... },
}

// GOOD — async function returns a Promise
{
  async before() {
    data = generateInput();
  },
  test() { ... },
}

// ALSO GOOD — callback style
{
  before(cb: () => void) {
    data = generateInput();
    cb();
  },
  test() { ... },
}
3. test() can be sync or async

Unlike before/after, the test function works correctly as a plain synchronous function. Make it async only if the code under test is genuinely asynchronous.

4. TypeScript constraints under --experimental-strip-types

Node's type stripping handles annotations, as casts, and ! assertions. But it does not support:

  • enum declarations (use const objects instead)
  • namespace declarations
  • Parameter properties in constructors (constructor(private x: number))
  • Legacy import = / export = syntax

Keep benchmark files to simple TypeScript that only uses type annotations, interfaces, type aliases, and casts.

Example: Full Benchmark

This example shows a benchmark comparing getChunks() between the published package and workspace code:

ts
import cronometro from "cronometro";
import * as localTools from "jazz-tools";
import * as latestPublishedTools from "jazz-tools-latest";
import { WasmCrypto as LocalWasmCrypto } from "cojson/crypto/WasmCrypto";
import { cojsonInternals } from "cojson";
import { WasmCrypto as LatestPublishedWasmCrypto } from "cojson-latest/crypto/WasmCrypto";

const CHUNK_SIZE = cojsonInternals.TRANSACTION_CONFIG.MAX_RECOMMENDED_TX_SIZE;
const TOTAL_BYTES = 5 * 1024 * 1024;

function makeChunks(totalBytes: number, chunkSize: number): Uint8Array[] {
  const chunks: Uint8Array[] = [];
  let remaining = totalBytes;
  while (remaining > 0) {
    const size = Math.min(chunkSize, remaining);
    const chunk = new Uint8Array(size);
    for (let i = 0; i < size; i++) {
      chunk[i] = Math.floor(Math.random() * 256);
    }
    chunks.push(chunk);
    remaining -= size;
  }
  return chunks;
}

type Tools = typeof localTools;

async function createContext(tools: Tools, wasmCrypto: typeof LocalWasmCrypto) {
  const ctx = await tools.createJazzContextForNewAccount({
    creationProps: { name: "Bench Account" },
    peers: [],
    crypto: await wasmCrypto.create(),
    sessionProvider: new tools.MockSessionProvider(),
  });
  return { account: ctx.account, node: ctx.node, FileStream: tools.FileStream };
}

function populateStream(ctx: Awaited<ReturnType<typeof createContext>>, chunks: Uint8Array[]) {
  let totalBytes = 0;
  for (const c of chunks) totalBytes += c.length;
  const stream = ctx.FileStream.create({ owner: ctx.account });
  stream.start({ mimeType: "application/octet-stream", totalSizeBytes: totalBytes });
  for (const chunk of chunks) stream.push(chunk);
  stream.end();
  return stream;
}

const benchOptions = {
  iterations: 50,
  warmup: true,
  print: { colors: true, compare: true },
  onTestError: (testName: string, error: unknown) => {
    console.error(`\nError in test "${testName}":`);
    console.error(error);
  },
};

let readCtx: Awaited<ReturnType<typeof createContext>>;
let readStream: ReturnType<typeof populateStream>;

await cronometro(
  {
    "getChunks - @latest": {
      async before() {
        readCtx = await createContext(
          // @ts-expect-error version mismatch
          latestPublishedTools,
          LatestPublishedWasmCrypto,
        );
        readStream = populateStream(readCtx, makeChunks(TOTAL_BYTES, CHUNK_SIZE));
      },
      test() {
        readStream.getChunks();
      },
      async after() {
        (readCtx.node as any).gracefulShutdown();
      },
    },
    "getChunks - @workspace": {
      async before() {
        readCtx = await createContext(localTools, LocalWasmCrypto);
        readStream = populateStream(readCtx, makeChunks(TOTAL_BYTES, CHUNK_SIZE));
      },
      test() {
        readStream.getChunks();
      },
      async after() {
        (readCtx.node as any).gracefulShutdown();
      },
    },
  },
  benchOptions,
);

Checklist

  • One benchmark file per operation (e.g., filestream.getChunks.bench.ts)
  • Single cronometro() call comparing @latest vs @workspace
  • Fixed data size constant at top of file (e.g., const TOTAL_BYTES = 5 * 1024 * 1024)
  • Benchmark file placed in bench/jazz-tools/ with *.bench.ts naming
  • Script added to bench/package.json using node --experimental-strip-types --no-warnings
  • before/after hooks are async (not plain sync)
  • iterations set to at least 50 for stable results
  • warmup: true enabled
  • onTestError handler included to surface worker failures
  • Test names follow format "operation - @implementation" (e.g., "getChunks - @workspace")
  • When comparing vs published: npm aliases added to bench/package.json and pnpm install run
  • When using Jazz context: gracefulShutdown() called in after() hook
  • Test data generated inside before() hooks (not at module level or inside test())

© garden-co, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .cursor/skills/benchmarking of garden-co/classic-jazz.

Open the folder on GitHubat commit 4f90501

Compare with similar skills

Benchmarking next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Benchmarking compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Benchmarking this skillgarden-co/classic-jazz2.5k—~3.2kAutomated safety check: PassMIT
OpenHarness End-to-End EvalsHKUDS/OpenHarness16k1 repos~2.1kAutomated safety check: NotesMIT
Qwen Code E2E TestingQwenLM/qwen-code28k—~2.1kAutomated safety check: PassApache-2.0
Quality Scandiegosouzapw/OmniRoute74k—~748Automated safety check: PassMIT
E2E TestingInsForge/InsForge13k—~1.5kAutomated safety check: PassApache-2.0
Analogjsanalogjs/analog3.2k—~891Automated safety check: PassMIT

Similar skills

  • Validates OpenHarness features by running real multi-turn agent loops with live LLM calls against an unfamiliar codebase, checking actual tool execution.

    16k GitHub starsUsed in 1 repo~2.1k tokens
    Testing & QAAuto-check: notes
  • Qwen Code E2E Testing

    QwenLM/qwen-code

    Guides end-to-end testing of the Qwen Code CLI in headless mode with real model calls, MCP test servers and inspection of raw API traffic.

    28k GitHub stars~2.1k tokensUpdated today
    Testing & QAAuto-check passed
  • Quality Scan

    diegosouzapw/OmniRoute

    Runs a scoped, read-only quality scan on a repository candidate and reports exact evidence, failures and frozen debt, without treating a static scan as release acceptance.

    74k GitHub stars~748 tokensUpdated today
    Testing & QAAuto-check passed
  • E2E Testing

    InsForge/InsForge

    A skill your agent uses when an InsForge maintainer has finished an OSS repo change and is ready to open, update, or submit the InsForge PR.

    13k GitHub stars~1.5k tokensUpdated 2 days ago
    Testing & QAAuto-check passed
  • Analogjs

    analogjs/analog

    Conventions for working in an AnalogJS app (an Angular meta-framework powered by Vite) — file-based routing with .page.ts files, RouteMeta, server and API routes on Nitro/h3, page load functions and…

    3.2k GitHub stars~891 tokensUpdated today
    Testing & QAAuto-check passed
  • Runs RStudio's Playwright end-to-end tests against the desktop app or a server build with the project's npm scripts, asking you which mode to use first.

    5.1k GitHub stars~801 tokensUpdated today
    Testing & QAAuto-check passed

More from garden-co/classic-jazz

All 8 skills in this repo
  • Jazz Performance

    garden-co/classic-jazz

    A skill your agent uses when optimizing Jazz applications for speed, responsiveness, and scalability.

    2.5k GitHub stars~1.9k tokensUpdated 1 mo ago
    Auto-check passed
  • Jazz Testing

    garden-co/classic-jazz

    A skill your agent uses when you need to write, review, or debug automated tests for applications built on the Jazz framework.

    2.5k GitHub stars~1.6k tokensUpdated 1 mo ago
    Auto-check passed
  • Jazz UI Development

    garden-co/classic-jazz

    A skill your agent uses when building, debugging, or optimizing Jazz applications.

    2.5k GitHub stars~1.7k tokensUpdated 1 mo ago
    Auto-check passed
  • Jazz Permissions Security

    garden-co/classic-jazz

    A skill your agent uses when designing data schemas, implementing sharing workflows, or auditing access control in Jazz applications.

    2.5k GitHub stars~2.9k tokensUpdated 1 mo ago
    Auto-check passed
  • Jazz Schema Design

    garden-co/classic-jazz

    Design and implement collaborative data schemas using the Jazz framework.

    2.5k GitHub stars~3.2k tokensUpdated 1 mo ago
    Auto-check passed
  • Changeset

    garden-co/classic-jazz

    Generate changeset files for versioning and changelog management in this monorepo.

    2.5k GitHub stars~538 tokensUpdated 1 mo ago
    Auto-check passed

Works with

Categories

Questions about Benchmarking

What does Benchmarking do?

A skill your agent uses when writing or running performance benchmarks for Jazz packages. Benchmarking is an agent skill from garden-co/classic-jazz. Use this skill when writing or running performance benchmarks for Jazz packages.

When should I use Benchmarking?

Benchmarking fits situations like: running performance benchmarks for Jazz packages.

How do I install Benchmarking in Claude Code?

Run `npx skills add garden-co/classic-jazz --skill benchmarking -a claude-code`. Or copy the skill folder (.cursor/skills/benchmarking in garden-co/classic-jazz) into .claude/skills/benchmarking in your project. Claude Code loads it when a task matches its description.

How do I install Benchmarking in Codex?

Run `npx skills add garden-co/classic-jazz --skill benchmarking -a codex`. Or copy the skill folder (.cursor/skills/benchmarking in garden-co/classic-jazz) into .agents/skills/benchmarking in your project. Codex loads it when a task matches its description.

Can I use Benchmarking in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add garden-co/classic-jazz --skill benchmarking -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/benchmarking, .gemini/skills/benchmarking, .github/skills/benchmarking and .opencode/skills/benchmarking in your project.

What does Benchmarking need to run?

Going by SKILL.md and its folder, Benchmarking needs the command-line tools its instructions call (pnpm and node).

Does Benchmarking access the network?

SKILL.md names 1 domain. As links in the text: github.com. This is read from the text; nothing was executed.

Is Benchmarking safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Benchmarking use?

Benchmarking is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Benchmarking use?

About 3.2k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Benchmarking?

Skills that share tags, products or a category with Benchmarking: OpenHarness End-to-End Evals (HKUDS/OpenHarness, 16k stars), Qwen Code E2E Testing (QwenLM/qwen-code, 28k stars), Quality Scan (diegosouzapw/OmniRoute, 74k stars) and E2E Testing (InsForge/InsForge, 13k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Benchmarking?

garden-co (a GitHub organization) maintains it in garden-co/classic-jazz, which has 2,534 GitHub stars. The repository holds 8 skills in this directory. The repository was last updated on September 7, 2026.

Source: garden-co/classic-jazz on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.