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 skills add kitchen-engineer42/joharnessburg --skill schema-designgit clone --depth 1 https://github.com/kitchen-engineer42/joharnessburgWrote 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/kitchen-engineer42/joharnessburg/schema-design)<a href="https://agentmods.dev/skills/kitchen-engineer42/joharnessburg/schema-design"><img src="https://agentmods.dev/badge/skills/kitchen-engineer42/joharnessburg/schema-design/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/kitchen-engineer42/joharnessburg/schema-design"><img src="https://agentmods.dev/badge/skills/kitchen-engineer42/joharnessburg/schema-design.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.00091 | $0.02258 |
| Opus 5 | $0.00046 | $0.01129 |
| Sonnet 5 | $0.00018 | $0.00452 |
| Haiku 4.5 | $0.00009 | $0.00226 |
Grade A, and why
schema-design 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 9d 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 — 133 lines — stays where its author put it; the contents beside it link to each section on GitHub.
schema-design
This is the most consequential decision in the knowledge phases. Get it wrong-or-too-rigid and every downstream phase pays for it (an earlier production system is a cautionary tale — see references/sku-regression-case-study.md). Get it right and the rest of the pipeline becomes obvious.
What schema-design is NOT
- It's not picking from a closed menu. There is no "the John schema." Different projects want different shapes.
- It's not a one-shot decision. The schema evolves through the early phases as the corpus reveals itself.
- It's not a JSON spec for the John-equipped agent to autocomplete. It's a taste call the user owns.
The app-type definition cascade
The app-type definition cascade — knowledge format → knowledge schema → app mechanism → build pipeline — has each link constrain the next. Schema is the second link in the chain — downstream of what kind of knowledge and upstream of what the app does. The cascade itself is explained in references/app-type-definition-cascade.md and applied in [[plan-md-authoring]]; this skill is where the schema link gets designed.
You make schema decisions only after the format decision is roughly settled. Reverse the order and you end up over-fitting the schema to the corpus, then re-doing it when the runtime asks for something the schema can't represent.
Before you design — read the corpus first
John's job is to teach schema design, not hand you a schema: abstract the methodology from prior projects — what to consider, when and how to iterate — and apply it here. That methodology starts with reading what's actually in the corpus before sketching a schema. Pre-designing in a vacuum is how you get over-fit or under-specified schemas.
Practical method:
- Read [[parsing]]'s output. Walk through a representative sample of
<project>/.john/parsed/*/doc.md(don't read everything; read enough to recognize patterns). - Ask survey questions as you read:
- Is the corpus mostly atomic statements (factual)?
- Mostly prescriptive how-to (procedural / rules)?
- Mostly narrative (storylines / characters / scenes)?
- Heavy on connections between entities (relational / wiki)?
- Mixed? Which mix?
- Notice structural features the corpus already exhibits: causal chains, taxonomies, glossary-shaped terminology, recurring entities, citations, decision flowcharts.
- Cross-reference user intent from PLAN.md's project intent + app mechanism (the app-type definition cascade). A corpus full of facts might suit a quiz app (procedural runtime) OR a wiki (browsable runtime); user intent decides.
- THEN sketch the schema to fit (corpus shape × user intent), not to fit a default.
What ships with it
5 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 9d ago First seen · 133 lines · 91 tokens per session scan A da663b2aa229
schema-design is a skill published in the GitHub repository kitchen-engineer42/joharnessburg (9 stars, last pushed 2mo ago), licensed MIT. It adds 91 tokens to every session and 2,258 once invoked, about $0.0005 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-31.
Other skills, from other repositories
ccc-prompt-fix
Fix and sharpen a prompt. Diagnoses it against the 6 prompt-quality patterns, returns a tightened rewrite with the reasoning, and suggests the right library prompt for your task.
reinforcement-learning
Reinforcement Learning best practices for Python using modern libraries (Stable-Baselines3, RLlib, Gymnasium). Use when: Implementing RL algorithms (PPO, SAC, DQN, TD3, A2C) Creating custom Gymnasium environments Training, debugging, or evaluating RL agents Setting up hyperparameter tuning for RL Deploying RL models…
deep-learning
Comprehensive guide for Deep Learning with Keras 3 (Multi-Backend: JAX, TensorFlow, PyTorch). Use when building neural networks, CNNs for computer vision, RNNs/Transformers for NLP, time series forecasting, or generative models (VAEs, GANs). Covers model building (Sequential/Functional/Subclassing APIs), custom…
ccc-data
For large datasets and data files, the Files API can ingest CSVs, JSON, Parquet, and other formats directly — avoiding token limits for bulk data analysis. Use data-ingestion from ccc-research for document-scale inputs.
agy-prompting
Internal helper — how to tighten a user request into a sharp prompt for the Antigravity CLI (agy / Gemini 3.x with native web search and agentic tools).
grounding
Use before writing, reviewing, or debugging any code that uses a specific ML model (DINOv3, SAM 2, Whisper, Qwen3-Embedding, SigLIP 2…), whenever a model-provenance archive for it exists locally. Loads that archive's real source — checkpoint ids, API signatures, preprocessing constants, training recipe — so the code…