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/qauth-labs/qauth/validationnpx skills add qauth-labs/qauth --skill validationgit clone --depth 1 https://github.com/qauth-labs/qauthWhat 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.00060 | $0.00913 |
| Opus 5 | $0.00030 | $0.00456 |
| Sonnet 5 | $0.00012 | $0.00183 |
| Haiku 4.5 | $0.00006 | $0.00091 |
Grade A, and why
validation 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 — 101 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Validation (QAuth)
Input validation for the QAuth auth-server using Zod v4. Validate at the route boundary (fail fast), organize schemas consistently, and use the standalone Zod v4 validators. Use this skill when defining or reviewing schemas.
Zod v4 Validators
This project uses Zod v4, where many format validators are standalone functions, not string methods. Do not use the deprecated string-method form.
| Use | Not |
|---|---|
z.email() |
z.string().email() |
z.uuid() |
z.string().uuid() |
z.url() |
z.string().url() |
Optional error message: z.email('Invalid email format'),
z.uuid('Invalid realm ID format'), z.url('Must be a valid URL').
Also standalone in Zod v4: z.httpUrl(), z.hostname(), z.jwt(),
z.iso.date(), z.iso.datetime(), z.ipv4(), z.ipv6(), z.hex(),
z.base64(), etc. See zod.dev/api under "String formats."
If you learn another Zod v4 standalone validator, use it consistently and do not
fall back to the old string-method form.
Export the schema and its inferred type together:
export type RequestType = z.infer<typeof requestSchema>;
Schema Organization
- API schemas:
apps/auth-server/src/app/schemas/(e.g.auth.ts,oauth.ts,common.ts) - Config schemas:
libs/server/config/src/lib/schemas/(env validation) - Shared validators:
libs/shared/validation/(email normalization, password strength)
Security and Best Practices
- Validate all inputs: body, query params, headers, and response shape. Never trust client input.
- Fail fast: validation happens at the route level via the Fastify schema; invalid requests return 400 before the handler runs.
- Normalize before validation/use: email normalization (
normalizeEmail) happens after format validation but before storage/query. - Specific formats: use regex for exact formats (e.g. hex tokens
/^[0-9a-fA-F]{64}$/, PKCE verifiers/^[A-Za-z0-9._~-]{43,128}$/). - Length limits: set
.min()and.max()on strings to prevent DoS (e.g.state: z.string().max(255).optional()). - Password strength: use
zxcvbnvia@qauth-labs/shared-validation; return feedback for weak passwords.
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 · 101 lines · 60 tokens per session scan A 2e12335a9aad
validation is a skill published in the GitHub repository qauth-labs/qauth (24 stars, last pushed 7d ago), licensed Apache-2.0. It adds 60 tokens to every session and 913 once invoked, about $0.0003 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
write-e2e-test
Write end-to-end (e2e) tests for authgear-server. Use when the user asks to write, add, or create e2e tests. The tests live in e2e/tests/ and are YAML-driven.
add-portal-screen
Add screens or components to the portal frontend. Use when the user asks to create a new portal page, screen, tab, or UI component.
api-design
Review or design APIs for Authgear. In review mode, evaluates a design draft against the checklist. In ideation mode, develops a design from a description and self-reviews it.
update-deps
Audit and fix dependency vulnerabilities in Go and Node.js packages. Runs govulncheck for Go and npm audit for each package.json directory. Commits fixes directory by directory.
new-siteadmin-api
Full pipeline for adding a new Site Admin API feature — from OpenAPI spec through implementation plan to working service. Use when adding a new endpoint or filling in real data for an existing stub.
update-portal-ui
Guidelines for updating or designing pages in the portal React frontend (portal/src). Covers component conventions, link rendering rules, i18n patterns, and common pitfalls.