Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/elbwalker/walkerOSnpx agentmods add skills/elbwalker/walkeros/walkeros-testing-strategyWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/elbwalker/walkeros/walkeros-testing-strategy)<a href="https://agentmods.dev/skills/elbwalker/walkeros/walkeros-testing-strategy"><img src="https://agentmods.dev/badge/skills/elbwalker/walkeros/walkeros-testing-strategy/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/elbwalker/walkeros/walkeros-testing-strategy"><img src="https://agentmods.dev/badge/skills/elbwalker/walkeros/walkeros-testing-strategy.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00036 | $0.04132 |
| Opus 5.5 | $0.00014 | $0.01653 |
| Sonnet 5.5 | $0.00007 | $0.00826 |
| Haiku 4.5 | $0.00004 | $0.00413 |
Grade A, and why
walkeros-testing-strategy scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured today.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 493 lines — stays where its author put it; the contents beside it link to each section on GitHub.
walkerOS Testing Strategy
Overview
walkerOS uses a layered testing approach with built-in patterns for mocking and documentation sync. This skill ensures tests are reliable, efficient, and maintainable.
Core principle: Test real behavior using the env pattern, link to dev
examples, verify before claiming complete.
The Rules
Rule 1: Use env for Mocking, Not Jest
walkerOS has a built-in dependency injection pattern via env in context. This
is lighter than Jest mocks, enables documentation generation, and keeps tests in
sync with examples.
Wrong:
jest.mock('../ga4', () => ({ initGA4: jest.fn() }));
expect(initGA4).toHaveBeenCalledWith(...);
Right:
import { examples } from '../dev';
import { mockEnv } from '@walkeros/core';
const calls: Array<{ path: string[]; args: unknown[] }> = [];
const testEnv = mockEnv(examples.env.push, (path, args) => {
calls.push({ path, args });
});
await destination.push(event, { ...context, env: testEnv });
expect(calls).toContainEqual({
path: ['window', 'gtag'],
args: ['event', 'page_view', { page_title: 'Home' }],
});
Rule 2: Link Tests to dev Examples
The dev.ts export provides examples.env, examples.events,
examples.mapping, and examples.step. Using these in tests ensures
documentation stays in sync.
import { examples } from '../dev';
// Use examples.env for mock environment
const testEnv = mockEnv(examples.env.push, interceptor);
// Assert against examples.events (documented expected output)
expect(calls[0].args).toEqual(examples.events.ga4PageView());
// Test with examples.mapping configurations
const config = { mapping: examples.mapping.ecommerce };
Step Examples with it.each
Step examples (examples.step) provide { in, out } pairs for each step. Use
it.each to iterate over them:
import { examples } from '../dev';
describe('step examples', () => {
it.each(Object.entries(examples.step))(
'%s',
async (name, { in: input, out: expected }) => {
const result = await step.push(input, context);
if (expected === false) {
expect(result).toBe(false);
} else {
expect(result).toEqual(expected);
}
},
);
});
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- today Changed · +28 lines f414957f0a61
- 22d ago Changed · +10 lines 10e6815073d3
- 28d ago Changed · +27 lines 659eb70d5f06
- 1mo ago First seen · 428 lines · 36 tokens per session scan A d702b43f455b
walkeros-testing-strategy is a skill published in the GitHub repository elbwalker/walkerOS (347 stars, last pushed today), licensed MIT. It adds 36 tokens to every session and 4,132 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
server-side-calls
Call tRPC procedures directly from server code using t.createCallerFactory() and router.createCaller(context) for integration testing, internal server logic, and custom API endpoints. Catch TRPCError and extract HTTP status with getHTTPStatusCodeFromError(). Error handling via onError option.
fixing-flaky-tests
Guides an agent through reproducing, root-causing, fixing, and validating flaky tests in the PostHog monorepo. Use when a test fails intermittently in CI but passes on rerun or locally, when hogli ci:insights or the debugging-ci-failures skill classifies a failure as a flaky test, when given a GitHub Actions URL for a…
qa-frontend
Internal PostHog developer frontend/browser QA skill. Use only when a PostHog developer explicitly asks to run frontend QA, browser-test a PR, verify a UI flow against the local PostHog stack, use qa-frontend, or QA current frontend changes with browser/runtime evidence, or to make a feature reel (see reel mode…
writing-tests
Gates whether a new test should exist and forces it to be efficient, protecting CI from low-value test bloat. Use before any change to what a pytest, Jest, or Playwright test asserts or sets up, down to one fixture or one assertion added to an existing block. Front-loads the value bar (every test must catch a…
creating-online-evaluations
Author continuously-running online evaluations in PostHog AI observability, grounded in real failure modes you've identified. Use when the user wants evaluations that automatically score new generations or whole traces going forward — "create an eval to catch X", "continuously check that responses do Y", "turn these…
writing-evals
Teaches how to write and run evals on the products/posthogai/evalharness/ harness — sandboxed agent suites that execute the real coding agent in a Docker or Modal sandbox against a seeded Hedgebox project, and one-shot suites that score a single in-process model invocation per case. Use when adding or changing eval…