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.
git clone --depth 1 https://github.com/kaptinlin/gozodWrote 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/rules/kaptinlin/gozod/schema_test_implementation_guide)<a href="https://agentmods.dev/rules/kaptinlin/gozod/schema_test_implementation_guide"><img src="https://agentmods.dev/badge/rules/kaptinlin/gozod/schema_test_implementation_guide/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/rules/kaptinlin/gozod/schema_test_implementation_guide"><img src="https://agentmods.dev/badge/rules/kaptinlin/gozod/schema_test_implementation_guide.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.04495 | $0.04495 |
| Opus 5.5 | $0.01798 | $0.01798 |
| Sonnet 5.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 1mo 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.
- 1mo 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 (25 stars, last pushed 2mo ago), licensed MIT. It adds 4,495 tokens to every session, about $0.0180 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 cursor rules, from other repositories
gonavi-go
A Go coding rule set for the GoNavi repository, based on common Go style guides and the project's own conventions. It covers file structure, errors, context, concurrency, logging, and tests.
go
Idiomatic Go rules. Explicit error handling, interface-based design, context-first concurrency.
go
Go development guidelines — error handling, concurrency, interfaces, context propagation, and testing. Applied when working with Go code.
mockery
Mockery Mock Generation Rules.
go-test
Go test conventions — parallelism, table-driven tests, assertions.
d-test-unit-test
A set of rules for writing unit tests in Go, the programming language used by the examples. It covers test names, table-driven cases, subtests, mocks, assertions, file placement, and basic test quality principles.