Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/gridaco/nothing/fixturesnpx skills add gridaco/nothing --skill fixturesgit clone --depth 1 https://github.com/gridaco/nothingWhat 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 | $0.00040 | $0.01443 |
| Opus 5 | $0.00020 | $0.00722 |
| Sonnet 5 | $0.00008 | $0.00289 |
| Haiku 4.5 | $0.00004 | $0.00144 |
Grade A, and why
fixtures 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 3d ago.
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 — 126 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Fixtures
What fixtures are
Fixtures are static input files — HTML, SVG, CSS, JSON, .grida,
font binaries, images, text samples — used as deterministic inputs to
rendering, parsing, and I/O tests. They exist so that tests are reproducible,
self-contained, and don't depend on external services or generated data.
Why we keep them
- Regression detection — render the same input, compare the output.
- Spec coverage — each fixture maps to a specific feature or property being tested (one concept per file).
- Onboarding — new contributors can see exactly what the renderer handles by browsing fixtures.
- Cross-pipeline validation — the same fixture can be consumed by unit tests, golden tests, reftests, probe tests, and visual inspection.
What should be covered
A fixture should exist for every rendering behavior, format variant, or edge case that the engine supports or intends to support. This includes:
- Each CSS property / SVG element the htmlcss or SVG renderer handles
- Format I/O round-trips (SVG → Grida,
.gridadecode) - Edge cases: zero-size, empty content, deeply nested, degenerate inputs
- Unsupported-but-tracked features (the fixture documents the gap)
Best practices
- One concept per file. Don't combine unrelated properties.
- Self-contained. No external resources, network fetches, or scripts.
- Minimal. Only enough structure to isolate the behavior under test.
- Probe-friendly. High-contrast palette (prefer B/W), round pixel values, ≤ 3 colors. Designed for headless pixel probing, not human aesthetics.
- Descriptive naming.
<domain>-<property>[-<descriptor>].<ext>— the filename alone should tell you what's being tested. - Labeled specimens. Within a fixture, label each test case with the
value being exercised so both humans and heuristics can identify regions.
Keep labels short, and pin the dimensions of any container holding a
label (flex item, grid cell, stretched block) so font-advance-width
differences between engines can't leak into box geometry. When a test
pipeline offers a text-neutralizing stylesheet (e.g.
fixtures/test-html/_reftest/hide-text.cssfor the htmlcss reftests), prefer that over stripping the label — keeping the text helps the next reader understand the fixture. - Match the fixture's subject to the viewport policy. For refbrowser
fixtures under
fixtures/test-html/, paint / visual-property fixtures should size their root to a preset viewport (viamin-height) so grida's cull and Chromium's screenshot have identical dimensions. Layout fixtures (box-model, flex, grid, intrinsic sizing) must NOT force a body size — the output dimensions are what the test measures; amin-heighthack contaminates the result. Seefixtures/test-html/README.mdfor the preset list, the paint-vs-layout rule, and the per-fixtureviewportworkflow for layout tests. - Don't duplicate. Before adding a fixture, check if an existing one already covers the behavior. Extend or split rather than duplicate.
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.
- 3d ago First seen · 126 lines · 40 tokens per session scan A e78ce080b6b7
fixtures is a skill published in the GitHub repository gridaco/nothing (43 stars, last pushed 3d ago), licensed Apache-2.0. It adds 40 tokens to every session and 1,443 once invoked, about $0.0002 per session on Opus 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
fixtures
Guides authoring, organizing, and referencing test fixtures in this repo. Use when creating new fixtures, writing tests that depend on fixtures, or deciding what should be checked into git. Engine fixtures (rendering corpora) live in the engine repo.
spec-driven-tests
Rebuild a package's unit test suite around a behavior specification (SPEC.md) derived from the implementation, with every test citing a numbered rule ID. Use when asked to do a spec-driven test rebuild, write a SPEC.md for a package, repeat the state or store spec process (PRs.
write-unit-tests
Writing unit and integration tests for the tldraw SDK. Use when creating new tests, adding test coverage, or fixing failing tests in packages/editor or packages/tldraw. Covers Vitest patterns, TestEditor usage, and test file organization.
docs-svg-kit
Author SVG figures for Grida docs — diff-able, version-controlled vector diagrams embedded in doc pages instead of screenshots. Provides reusable primitives (selection chrome, size badges, anchor pins, resize cursors, click ripples), color/typography tokens, a starter template, and finished examples to crib from.…
editor-perf
Guides performance investigation, benchmarking, and optimization of the Grida Canvas web editor (TypeScript reducer, Immer, React hooks). Use when profiling reducer dispatch cost, diagnosing slow interactions (drag, resize, color change), writing or running editor benchmarks, instrumenting with PerfObserver, or…
sdk-seam
Discipline for the seam between two SDKs (or two sides of one contract) that the same hand writes. The failure mode: "we own both sides" produces dirty contracts no foreign reviewer would accept. The exercise: pretend the other side is FFI, IPC, or a network protocol you cannot rewrite. Spawn an adversarial subagent…