Agent skill

Testing

by latitude-dev in latitude-dev/latitude-llm

MITAuto-check passedDatabases

Install Testing

skills CLI

$ npx skills add latitude-dev/latitude-llm --skill testing -a claude-code

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

GitHub CLI

$ gh skill install latitude-dev/latitude-llm testing --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/latitude-dev/latitude-llm.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/testing .claude/skills/testing && 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/

Paste into Claude Code

Install the "testing" agent skill from https://github.com/latitude-dev/latitude-llm/tree/development/.agents/skills/testing into .claude/skills/testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "testing", then confirm the skill loads.

Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

$skill-installer

$skill-installer install https://github.com/latitude-dev/latitude-llm/tree/development/.agents/skills/testing

Type this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.

skills CLI

$ npx skills add latitude-dev/latitude-llm --skill testing -a codex

Project install goes to .agents/skills/; add -g for ~/.codex/skills/.

GitHub CLI

$ gh skill install latitude-dev/latitude-llm testing --agent codex

Project scope by default (.agents/skills/); add --scope user for a personal install.

Manual copy

$ git clone --depth 1 https://github.com/latitude-dev/latitude-llm.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.agents/skills/testing .agents/skills/testing && rm -rf skills-src

Use ~/.agents/skills/ instead of .agents/skills for a personal install.

Codex skills documentation · loads skills from .agents/skills/

Paste into Codex

Install the "testing" agent skill from https://github.com/latitude-dev/latitude-llm/tree/development/.agents/skills/testing into .agents/skills/testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "testing", then confirm the skill loads.

Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

skills CLI

$ npx skills add latitude-dev/latitude-llm --skill testing -a cursor

Project install goes to .agents/skills/; add -g for ~/.cursor/skills/.

GitHub CLI

$ gh skill install latitude-dev/latitude-llm testing --agent cursor

Project scope by default (.agents/skills/); add --scope user for a personal install.

Manual copy

$ git clone --depth 1 https://github.com/latitude-dev/latitude-llm.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.agents/skills/testing .cursor/skills/testing && rm -rf skills-src

Use ~/.cursor/skills/ instead of .cursor/skills for a personal install.

Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/

Paste into Cursor

Install the "testing" agent skill from https://github.com/latitude-dev/latitude-llm/tree/development/.agents/skills/testing into .cursor/skills/testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "testing", then confirm the skill loads.

Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

gemini skills install

$ gemini skills install https://github.com/latitude-dev/latitude-llm.git --path .agents/skills/testing

--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.

skills CLI

$ npx skills add latitude-dev/latitude-llm --skill testing -a gemini-cli

Project install goes to .agents/skills/; add -g for ~/.gemini/skills/.

GitHub CLI

$ gh skill install latitude-dev/latitude-llm testing --agent gemini-cli

Project scope by default (.agents/skills/); add --scope user for a personal install.

Manual copy

$ git clone --depth 1 https://github.com/latitude-dev/latitude-llm.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.agents/skills/testing .gemini/skills/testing && rm -rf skills-src

Use ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.

Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/

Paste into Gemini CLI

Install the "testing" agent skill from https://github.com/latitude-dev/latitude-llm/tree/development/.agents/skills/testing into .gemini/skills/testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "testing", then confirm the skill loads.

Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

GitHub CLI

$ gh skill install latitude-dev/latitude-llm testing

Installs for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).

skills CLI

$ npx skills add latitude-dev/latitude-llm --skill testing -a github-copilot

Project install goes to .agents/skills/; add -g for ~/.copilot/skills/.

Manual copy

$ git clone --depth 1 https://github.com/latitude-dev/latitude-llm.git skills-src && mkdir -p .github/skills && cp -r skills-src/.agents/skills/testing .github/skills/testing && rm -rf skills-src

Use ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.

GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/

Paste into GitHub Copilot

Install the "testing" agent skill from https://github.com/latitude-dev/latitude-llm/tree/development/.agents/skills/testing into .github/skills/testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "testing", then confirm the skill loads.

GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

skills CLI

$ npx skills add latitude-dev/latitude-llm --skill testing -a opencode

OpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.

GitHub CLI

$ gh skill install latitude-dev/latitude-llm testing --agent opencode

Project scope by default (.agents/skills/); add --scope user for a personal install.

Manual copy

$ git clone --depth 1 https://github.com/latitude-dev/latitude-llm.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.agents/skills/testing .opencode/skills/testing && rm -rf skills-src

Use ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.

OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/

Paste into OpenCode

Install the "testing" agent skill from https://github.com/latitude-dev/latitude-llm/tree/development/.agents/skills/testing into .opencode/skills/testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "testing", then confirm the skill loads.

OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

Facts

Skill name: testing
GitHub stars: 4.7k
Token cost: ~1.1k tokens
SKILL.md length: 393 words
Files: 1
Skills in repo: 28
Repo updated: Oct 6, 2026
First seen: Oct 7, 2026
Licence: MIT

At a glance

Tasks that involve Data warehousing
SKILL.md covers Package exports (test code…, Conventions, Database testing (in-memory) and Why not vi.mock?
Calls pnpm

What it does

Testing is an agent skill from latitude-dev/latitude-llm. Writing or debugging tests, choosing unit vs integration style, Postgres/ClickHouse tests, regenerating ClickHouse test schema, or exporting test helpers from packages without pulling test code into production bundles.

Its SKILL.md is about 1.1k 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 Databases, covering Data warehousing. It works with ClickHouse and PostgreSQL. The repository describes itself as: Open-source observability for AI agents. Find where your agents fail, dispatch your coding agent to fix it, and verify the fix against real traces. The licence is MIT.

When your agent uses it

Tasks that involve Data warehousing

Example prompts

“/testing”

What it can do on your machine

Read from SKILL.md and the folder at commit 87e8aa0. 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
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md. Its commands use pnpm, which can reach the network depending on how they are called.
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

Testing loads about 1.1k tokens when it runs. Until then it costs about 57 tokens; SKILL.md has 393 words of instructions outside code blocks.

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

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 latitude-dev/latitude-llm at commit 87e8aa0, republished under its MIT licence (© latitude-dev). 393 words, ~1,142 tokens.

Download SKILL.mdSave it as .claude/skills/testing/SKILL.md (or your agent's skills folder).

name: testing
description: Writing or debugging tests, choosing unit vs integration style, Postgres/ClickHouse tests, regenerating ClickHouse test schema, or exporting test helpers from packages without pulling test code into production bundles.

Testing conventions and in-memory databases

When to use: Writing or debugging tests, choosing unit vs integration style, Postgres/ClickHouse tests, regenerating ClickHouse test schema, or exporting test helpers from packages without pulling test code into production bundles.

Package exports (test code isolation)

Test utilities (fakes, in-memory DB helpers, fixtures) must not be exported from a package’s main entry (src/index.ts).

Never re-export from ./test/ or ./testing/ in the main src/index.ts
To expose test helpers, add a /testing subpath in package.json exports:

json

{
  "exports": {
    ".": "./src/index.ts",
    "./testing": "./src/testing/my-test-helpers.ts"
  }
}

Consumers: import { Fake } from "@platform/my-package/testing"
Biome noRestrictedImports blocks test paths in production source; tsdown fails the build if test code is resolved from prod entry points

Conventions

Shared default environment: Node with globals enabled (packages/vitest-config/index.ts)
Write tests, mostly e2e, some unit tests when logic is complex
Unit tests: domain entities/use-cases/policies with fakes
Contract tests: adapter compliance against domain ports
Integration tests: infra-backed tests for Postgres/ClickHouse/Redis/BullMQ/object storage
End-to-end tests: ingest boundary to query boundary across organization scoping
Keep tests deterministic and isolated
Prefer package-local runs during iteration; run full monorepo tests before PR

Database testing (in-memory)

Always use in-memory databases for tests. Do not use vi.mock/vi.fn to mock repository methods and do not require running database servers. The project provides embedded, in-process database engines that run the real SQL against the real schema:

ClickHouse → chdb (chdb package): An in-process ClickHouse engine via @platform/testkit.
Postgres → PGlite (@electric-sql/pglite): An in-process Postgres via WASM via @platform/testkit.

Show full SKILL.md (162 more words)Show less

Postgres test setup (`@platform/testkit`)

typescript

import { setupTestPostgres } from "@platform/testkit"
import { beforeAll, describe, it } from "vitest"

const pg = setupTestPostgres()

describe("MyRepository", () => {
  it("does something", async () => {
    // pg.postgresDb is a real Drizzle instance backed by PGlite in-memory
    // pg.db is the lower-level Drizzle/PGlite instance for direct queries
  })
})

setupTestPostgres() registers vitest hooks automatically:

beforeAll: creates a PGlite instance, creates the latitude_app role, and runs all Drizzle migrations
afterAll: closes the PGlite connection

ClickHouse test setup (`@platform/testkit`)

Local developers must build the chdb native binding once before running ClickHouse-backed tests:

bash

pnpm --filter @platform/testkit chdb:build

Package-level test scripts intentionally do not run that build step; CI builds chdb once in the ClickHouse integration job before running the packages that need it.

typescript

import { setupTestClickHouse } from "@platform/testkit"
import { beforeAll, describe, it } from "vitest"

const ch = setupTestClickHouse()

describe("MyRepository", () => {
  let repo: ReturnType<typeof createMyRepository>

  beforeAll(() => {
    repo = createMyRepository(ch.client)
  })

  it("does something", async () => {
    // ch.client is a real ClickHouseClient backed by chdb in-memory
  })
})

setupTestClickHouse() registers vitest hooks automatically:

beforeAll: creates a chdb session and loads the schema from schema.sql
beforeEach: truncates all tables for test isolation
afterAll: destroys the session and cleans up temp files

After new ClickHouse migrations, regenerate the in-memory test schema (only if the user asked you to run migration-related commands — see database-clickhouse-weaviate):

bash

pnpm --filter @platform/db-clickhouse ch:schema:dump

Why not `vi.mock`?

Mocking repositories with vi.fn() tests the wiring, not the queries. In-memory databases catch real bugs: wrong column names, broken argMax aggregations, incorrect GROUP BY clauses, and schema mismatches. They run quickly with zero external dependencies.

Files

Just SKILL.md in .agents/skills/testing of latitude-dev/latitude-llm.

Open the folder on GitHubat commit 87e8aa0

Compare with similar skills

Testing 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.

Testing compared with similar skills
Skill	Stars	Used in	Tokens	Auto-check	Licence	Repo updated
Testing this skilllatitude-dev/latitude-llm	4.7k	—	~1.1k	Automated safety check: Pass	MIT	yesterday
Chdb SQLvemetric/vemetric	394	1 repos	~1.2k	Automated safety check: Pass	Apache-2.0	today
Observal AdminObserval/Observal	4.1k	—	~774	Automated safety check: Pass	Apache-2.0	today
Querying Tempotempoxyz/tidx	107	—	~3.1k	Automated safety check: Pass	MIT	today
Local Platform E2Ecomputesdk/benchmarks	126	—	~3k	Automated safety check: Notes	MIT	today
Clickhouse Managed Postgres RcaClickHouse/agent-skills	544	—	~1.2k	Automated safety check: Pass	Apache-2.0	8 days ago

Similar skills

Chdb SQL
vemetric/vemetric
A skill your agent uses when the user wants to run SQL — especially analytical SQL — on local files (parquet/csv/json), URLs, S3 paths, or remote databases (Postgres, MySQL, MongoDB, ClickHouse…
394 GitHub starsUsed in 1 repo~1.2k tokens
DatabasesAuto-check passed
Observal Admin
Observal/Observal
Administers Observal users, settings, diagnostics, review queues, security events, audit logs, SAML, SCIM, the local Observal server, its upgrades and rollback, and its own PostgreSQL and ClickHouse…
4.1k GitHub stars~774 tokensUpdated today
DatabasesAuto-check passed
Querying Tempo
tempoxyz/tidx
Query indexed Tempo chain data via tidx HTTP API and CLI. An agent skill from tempoxyz/tidx.
107 GitHub stars~3.1k tokensUpdated today
DatabasesAuto-check passed
Local Platform E2E
computesdk/benchmarks
Stand up benchmarks-platform locally (Postgres + MinIO + ClickHouse in docker) and run a real @benchsdk/runner benchmark against it, with no cloud or provider credentials.
126 GitHub stars~3k tokensUpdated today
DatabasesAuto-check: notes
Clickhouse Managed Postgres Rca
ClickHouse/agent-skills
MUST USE when investigating performance issues on a ClickHouse-managed Postgres instance.
544 GitHub stars~1.2k tokensUpdated 8 days ago
DatabasesAuto-check passed
Semantic Analyst
sidequery/sidemantic
Answer analytical, KPI, metric, trend, cohort, and business-performance questions through a Sidemantic semantic layer.
129 GitHub stars~982 tokensUpdated today
DatabasesAuto-check passed

Questions about Testing

What does Testing do?

Writing or debugging tests, choosing unit vs integration style, Postgres/ClickHouse tests, regenerating ClickHouse test schema, or exporting test helpers from packages without pulling test code into…. Testing is an agent skill from latitude-dev/latitude-llm. Writing or debugging tests, choosing unit vs integration style, Postgres/ClickHouse tests, regenerating ClickHouse test schema, or exporting test helpers from packages without pulling test code into production bundles.

When should I use Testing?

Testing fits situations like: tasks that involve Data warehousing.

How do I install Testing in Claude Code?

Run `npx skills add latitude-dev/latitude-llm --skill testing -a claude-code`. Or copy the skill folder (.agents/skills/testing in latitude-dev/latitude-llm) into .claude/skills/testing in your project. Claude Code loads it when a task matches its description.

How do I install Testing in Codex?

Run `npx skills add latitude-dev/latitude-llm --skill testing -a codex`. Or copy the skill folder (.agents/skills/testing in latitude-dev/latitude-llm) into .agents/skills/testing in your project. Codex loads it when a task matches its description.

Can I use Testing 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 latitude-dev/latitude-llm --skill testing -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/testing, .gemini/skills/testing, .github/skills/testing and .opencode/skills/testing in your project.

What does Testing need to run?

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

Does Testing access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Testing 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 Testing use?

Testing 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 Testing use?

About 1.1k tokens (SKILL.md is roughly 4.6k 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 Testing?

Skills that share tags, products or a category with Testing: Chdb SQL (vemetric/vemetric, 394 stars), Observal Admin (Observal/Observal, 4.1k stars), Querying Tempo (tempoxyz/tidx, 107 stars) and Local Platform E2E (computesdk/benchmarks, 126 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Testing?

latitude-dev (a GitHub organization) maintains it in latitude-dev/latitude-llm, which has 4,712 GitHub stars. The repository holds 28 skills in this directory. The repository was last updated on October 6, 2026.

Source: latitude-dev/latitude-llm on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.

Testing

Install Testing

Facts

At a glance

What it does

When your agent uses it

Example prompts

What it can do on your machine

Tool permissions

Runs code

Network

Credentials

Context cost

Safety

SKILL.md

Testing conventions and in-memory databases

Package exports (test code isolation)

Conventions

Database testing (in-memory)

Postgres test setup (`@platform/testkit`)

ClickHouse test setup (`@platform/testkit`)

Why not `vi.mock`?

Files

Compare with similar skills

Similar skills

Chdb SQL

Observal Admin

Querying Tempo

Local Platform E2E

Clickhouse Managed Postgres Rca

Semantic Analyst

More from latitude-dev/latitude-llm

Better Auth Best Practices

Artifact Designer

CI Watchdog

Temporal Developer

Docs

Managing Maintenance Windows

Questions about Testing

Install Testing

Facts

At a glance

What it does

When your agent uses it

Example prompts

What it can do on your machine

Tool permissions

Runs code

Network

Credentials

Context cost

Safety

SKILL.md

Testing conventions and in-memory databases

Package exports (test code isolation)

Conventions

Database testing (in-memory)

Postgres test setup (@platform/testkit)

ClickHouse test setup (@platform/testkit)

Why not vi.mock?

Files

Compare with similar skills

Similar skills

More from latitude-dev/latitude-llm

Related

Questions about Testing

Postgres test setup (`@platform/testkit`)

ClickHouse test setup (`@platform/testkit`)

Why not `vi.mock`?