headcount is an organization of independently installable Claude Code plugins, each grouping skills for a department such as finance, security, or demand generation. Claude Code users install the departments they need and invoke their skills for specialized work; the catalogue entries are skills and related agent tooling from that organization.
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 cbrock84/headcount --skill data-modelinggit clone --depth 1 https://github.com/cbrock84/headcountWrote 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/cbrock84/headcount/data-modeling)<a href="https://agentmods.dev/skills/cbrock84/headcount/data-modeling"><img src="https://agentmods.dev/badge/skills/cbrock84/headcount/data-modeling/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/cbrock84/headcount/data-modeling"><img src="https://agentmods.dev/badge/skills/cbrock84/headcount/data-modeling.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00077 | $0.00832 |
| Opus 5.5 | $0.00031 | $0.00333 |
| Sonnet 5.5 | $0.00015 | $0.00166 |
| Haiku 4.5 | $0.00008 | $0.00083 |
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 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 — 83 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 ships with it
1 file 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.
- 1mo ago Changed · +7 lines 337fd67e55b0
- 1mo ago First seen · 76 lines · 77 tokens per session scan A b0534bb8a538
data-modeling is a skill published in the GitHub repository cbrock84/headcount (2,065 stars, last pushed 1mo ago), licensed MIT. It adds 77 tokens to every session and 832 once invoked, about $0.0003 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 skills, from other repositories
consistency-coordination
This skill should be used when the user asks about the "CAP theorem", "PACELC", a "consistency model", "eventual vs strong consistency", "read-your-writes", "causal consistency", "quorum" or "R+W>N", "consensus", "Raft / Paxos", "leader election", "consistent hashing", a "distributed transaction", "2PC", or "saga".…
data-storage
This skill should be used when the user asks "SQL or NoSQL", "which database", how to design a "data model" or "schema design", picks an "indexing" strategy, needs "sharding" or "partitioning", sets up "replication" (leader-follower / multi-leader), defines a "primary key"/"sort key", asks whether to "denormalize", or…
caching
This skill should be used when the user asks about a "caching strategy", "cache invalidation", "what to cache", "read-through vs write-through vs write-back", "cache eviction" (LRU/LFU/TTL), "Redis vs Memcached", "stale reads", or hits "thundering herd", "cache stampede", "cache penetration", or "hot key" problems.…
distributed-search
This skill should be used when the user designs a "search system", needs "full-text search", asks about an "inverted index", "Elasticsearch / OpenSearch", "relevance ranking" (TF-IDF/BM25), "search autocomplete / typeahead", an "indexing pipeline", or "faceted search". It gives the crawl/index/search architecture…
sequencer
This skill should be used when the user needs a "unique ID generator", "distributed IDs", a "Snowflake ID", asks "UUID vs auto-increment", wants a "time-sortable ID", a "monotonic sequence", a "ticket server", or "ID generation at scale". It gives a menu of ID schemes (UUID/ULID, Snowflake-style, DB ticket/range) with…
sharded-counters
This skill should be used when the user needs a "sharded counter", "distributed counter", to "count likes / views at scale", handles a "high-write counter" or "hot counter contention", asks about "approximate counting", "real-time counts", or "HyperLogLog". It gives the recipe for absorbing write-heavy counting…