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 agentmods add skills/cbrock84/headcount/data-migrationnpx skills add cbrock84/headcount --skill data-migrationgit 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-migration)<a href="https://agentmods.dev/skills/cbrock84/headcount/data-migration"><img src="https://agentmods.dev/badge/skills/cbrock84/headcount/data-migration.svg" alt="Measured on agentmods" 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 | $0.00102 | $0.00961 |
| Opus 5 | $0.00051 | $0.00481 |
| Sonnet 5 | $0.00020 | $0.00192 |
| Haiku 4.5 | $0.00010 | $0.00096 |
Grade A, and why
data-migration 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 yesterday.
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.
Copies of this mod
1 near-identical copy found in the catalogue:
- react-typed-events — 86% identical, 176 lines differ
How it starts
The opening of the file, as written. The whole thing — 80 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Data migration
Migrations are estimated as a data-movement problem and turn out to be a data-quality problem. The transfer is the easy part; discovering what the old system actually contains is where the time goes.
Profile the source before you map anything
Look at the real data, not the schema and not what anyone tells you it contains. Every legacy system has fields used for something other than their name, free-text where an enumeration was intended, duplicates that both look canonical, and records predating a rule everyone believes has always applied.
Count distinct values, null rates, format variance, and outliers on every field you intend to move. This is the single highest-return activity in a migration and the one most often skipped in favor of starting the mapping.
Decide what not to move. Migrating everything is the default and rarely the right answer. Archive what has no live use and move a clean subset — it shrinks the mapping, the reconciliation, and the cutover window all at once.
Write the mapping down field by field, including the ugly parts
For each target field: source field, transformation, what happens when the source is empty, and what happens when it does not fit. That last column is the one that decides how the migration goes.
Records that will not map cleanly need a decision, not a default. A row silently dropped, a required field filled with a placeholder, or a truncated value is a defect discovered months later by someone who trusted the number. Route exceptions to a list a human works through, and count them.
Rehearse on a full copy, more than once
A rehearsal on a sample proves the mapping compiles. A rehearsal on a full copy proves the timing, finds the pathological records, and gives you a real number for the cutover window.
Expect several rehearsals. Each one should end with a reconciliation and a defect list, and the last one should be clean and timed. Going into cutover having never completed a full run at production volume means the cutover is the first full run.
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.
- yesterday First seen · 80 lines · 102 tokens per session scan A e4b930bf2059
data-migration is a skill published in the GitHub repository cbrock84/headcount (1,247 stars, last pushed 2d ago), licensed MIT. It adds 102 tokens to every session and 961 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-09-03.
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".…
swiftdata-workflow
Design, implement, migrate, test, and integrate SwiftData persistence in Apple apps using current Apple documentation. Use for @Model schemas, ModelContainer and ModelContext ownership, @Query integration, relationships, uniqueness, deletion, concurrency, migrations, preview or test stores, and boundaries between…
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…
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…