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 rules/kaptinlin/gozod/schema_test_implementation_guidegit clone --depth 1 https://github.com/kaptinlin/gozodWhat 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.04495 | $0.04495 |
| Opus 5 | $0.02247 | $0.02247 |
| Sonnet 5 | $0.00899 | $0.00899 |
| Haiku 4.5 | $0.00449 | $0.00449 |
Grade A, and why
schema_test_implementation_guide 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 2d 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 — 473 lines — stays where its author put it; the contents beside it link to each section on GitHub.
GoZod Schema Test Implementation Guide
A concise and practical guide for building GoZod Schema test files, updated with the latest practices from string_test.go, object_test.go, and complex_test.go.
🎯 Core Principles
- Complete Strict Type Semantics: Test both
Parse(any)andStrictParse(T)methods thoroughly. - Parse vs StrictParse Duality: Verify Parse provides runtime flexibility while StrictParse provides compile-time type safety.
- Generic Type Safety: All tests must verify compile-time type safety and proper constraint handling.
- Modifier Behavior: Test immutability, correct type transformations, and Default/Prefault semantics.
- Comprehensive & Organized: Follow the unified section structure for clarity. Test boundaries and edge cases thoroughly.
- Real-World Patterns: Tests should reflect actual API usage, including modifier chaining and error handling.
- Default vs Prefault: Verify Default short-circuits validation while Prefault goes through full parsing pipeline.
🏗️ Test File Architecture
Each test file for a schema type should follow this consolidated architecture based on latest implementations:
package types
// ... imports
// =============================================================================
// Basic functionality tests
// =============================================================================
func Test<Type>_BasicFunctionality(t *testing.T) {
t.Run("valid <type> inputs", func(t *testing.T) { /* ... */ })
t.Run("invalid type inputs", func(t *testing.T) { /* ... */ })
t.Run("Parse and MustParse methods", func(t *testing.T) { /* ... */ })
t.Run("custom error message", func(t *testing.T) { /* ... */ })
}
// =============================================================================
// StrictParse and MustStrictParse tests
// =============================================================================
func Test<Type>_StrictParse(t *testing.T) {
t.Run("basic functionality", func(t *testing.T) { /* ... */ })
t.Run("with validation constraints", func(t *testing.T) { /* ... */ })
t.Run("with pointer types", func(t *testing.T) { /* ... */ })
t.Run("with default values", func(t *testing.T) { /* ... */ })
t.Run("with prefault values", func(t *testing.T) { /* ... */ })
}
func Test<Type>_MustStrictParse(t *testing.T) { /* ... */ }
// =============================================================================
// Type safety tests
// =============================================================================
func Test<Type>_TypeSafety(t *testing.T) { /* ... */ }
// =============================================================================
// Modifier methods tests
// =============================================================================
func Test<Type>_Modifiers(t *testing.T) { /* ... */ }
// =============================================================================
// Chaining tests
// =============================================================================
func Test<Type>_Chaining(t *testing.T) { /* ... */ }
// =============================================================================
// Default and prefault tests
// =============================================================================
func Test<Type>_DefaultAndPrefault(t *testing.T) {
t.Run("Default has higher priority than Prefault", func(t *testing.T) { /* ... */ })
t.Run("Default short-circuits validation", func(t *testing.T) { /* ... */ })
t.Run("Prefault goes through full validation", func(t *testing.T) { /* ... */ })
t.Run("Prefault only triggers for nil input", func(t *testing.T) { /* ... */ })
}
// =============================================================================
// Refine tests
// =============================================================================
func Test<Type>_Refine(t *testing.T) { /* ... */ }
func Test<Type>_RefineAny(t *testing.T) { /* ... */ }
// =============================================================================
// Coercion tests (Primitives only)
// =============================================================================
func Test<Type>_Coercion(t *testing.T) { /* ... */ }
// =============================================================================
// Error handling and edge case tests
// =============================================================================
func Test<Type>_ErrorHandling(t *testing.T) { /* ... */ }
// =============================================================================
// OVERWRITE TESTS (Transform/Pipe operations)
// =============================================================================
func Test<Type>_Overwrite(t *testing.T) { /* ... */ }
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.
- 2d ago First seen · 473 lines · 4,495 tokens per session scan A ef4557d5b0d4
schema_test_implementation_guide is a cursor rule published in the GitHub repository kaptinlin/gozod (24 stars, last pushed 1mo ago), licensed MIT. It adds 4,495 tokens to every session, about $0.0225 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 cursor rules, from other repositories
unit-test-coverage-95
Unit test coverage ≥95% per Go package (binding rule).
go-test
Go test conventions — parallelism, table-driven tests, assertions.
d-test-unit-test
Cursor rule "d-test-unit-test" from xyzbit/AI-Coding, covering golang 单元测试规范, 命名规范, 测试用例组织, 测试代码结构 and 测试原则.
go-testing-practices
Go Testing Best Practices.
python_tests
We use the unit tests to cover internal behavior that can work without the web / backend counterpart. We aim for 95%+ unit test coverage of our Python code in lib/streamlit.
unit-tests-tdd
TDD required for behavior changes; ≥80% package coverage on touched packages; unit-test conventions.