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/cbrock84/headcount/data-modelingnpx skills add cbrock84/headcount --skill data-modelinggit clone --depth 1 https://github.com/cbrock84/headcountWhat 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.00077 | $0.00757 |
| Opus 5 | $0.00039 | $0.00378 |
| Sonnet 5 | $0.00015 | $0.00151 |
| Haiku 4.5 | $0.00008 | $0.00076 |
Grade A, and why
data-modeling 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 — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Data modeling
Layers, and why the middle one matters
Three layers, each with one job:
-
Raw — source data, append-only, otherwise unmodified. Do not apply business logic on ingest: you cannot recover what you discarded, and the logic will need to change retroactively.
Privacy and security transformations are the exception, and belong at ingest. Credentials and secrets should never land in the warehouse at all. Personal data that is not needed should be dropped rather than stored and governed later, and identifiers you must keep but rarely need in the clear should be tokenized or encrypted on arrival. Retention and deletion apply from ingest, not from the marts.
The distinction: strip what you must not hold, keep everything you are entitled to hold, and leave interpretation for later.
-
Staging — cleaned and conformed: consistent types, standardized names, deduplicated, no business logic yet.
-
Marts — business-facing models shaped for how questions are asked.
The discipline that pays is keeping business logic out of layers 1 and 2. Logic embedded in ingestion cannot be changed retroactively, and it will need to change.
Grain is the decision everything follows from
State the grain of every table in one sentence: one row per what. "One row per order line per day" is a grain. "Order data" is not.
Most modeling errors are grain errors, and they surface as fan-out — a join multiplying rows so every downstream sum is inflated. If a number is mysteriously too high, check the grain before checking the logic.
Dimensional structure
Facts for events and measurements; dimensions for the things being described. Keep facts narrow and long, dimensions wide and short.
Conform dimensions across facts — one customer dimension, used everywhere. Separate customer tables per domain is how the same customer gets counted differently in two reports.
Handle history deliberately. Overwriting a dimension attribute rewrites the past: last year's revenue silently re-attributes to this year's segment. Decide per attribute whether history matters, and where it does, keep versions with valid-from and valid-to.
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 · 76 lines · 77 tokens per session scan A b0534bb8a538
data-modeling is a skill published in the GitHub repository cbrock84/headcount (578 stars, last pushed 3d ago), licensed MIT. It adds 77 tokens to every session and 757 once invoked, about $0.0004 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
model-compatibility
Model family compatibility matrix covering loaders, resolutions, samplers, CFG, VAE, ControlNet, and LoRA compatibility for SD 1.5, SDXL, Flux, SD3, and video models.
comfyui-node-registry
Authoring & publishing ComfyUI custom nodes to the Comfy Registry, covering node structure, pyproject.toml spec, comfy-cli publishing, and CI.
performance-analysis
Measurement approaches, profiling patterns, bottleneck identification, and optimization guidance. Use when diagnosing performance issues, establishing baselines, identifying bottlenecks, or planning for scale. Always measure before optimizing.
optimize
Self-contained compound loop: read threadsskilllearnings.log, cluster the misses, propose concrete sub-skill rule edits, and apply them with the user's approval. The fourth step after Plan / Work / Review. Trigger words: 'optimize', 'compound', '優化skill', '自我優化', '閉環'.
changelog-detective
Detect what changed in the product by comparing before and after a deploy or date — find new behaviors, new errors, changed user flows, and unexpected side effects that weren't in the release notes. Use after a deploy or when the user suspects something changed but doesn't know what.
repair-orchestrator
5-level repair escalation when quality gates fail. Surgical → Section-rewrite → Stage-rewrite → Full-regen → From-scratch. Hard cap 4 rounds total. Use when quality.json reports overallpassed=false OR reviewer rejects. Last line of defense before declaring an article unsalvageable.