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 code-reviewgit 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/code-review)<a href="https://agentmods.dev/skills/cbrock84/headcount/code-review"><img src="https://agentmods.dev/badge/skills/cbrock84/headcount/code-review/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/code-review"><img src="https://agentmods.dev/badge/skills/cbrock84/headcount/code-review.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Anti-Refusal · line 33 Skill instructs the agent to omit warnings, disclaimers, or ethical commentary. Stripping safety caveats hides risk from the user and is a common jailbreak preamble.Fix: Remove instructions that suppress warnings, disclaimers, or ethical commentary. Let the agent surface safety-relevant caveats to the user.
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.00072 | $0.00472 |
| Opus 5.5 | $0.00029 | $0.00189 |
| Sonnet 5.5 | $0.00014 | $0.00094 |
| Haiku 4.5 | $0.00007 | $0.00047 |
Grade A, and why
code-review 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.
What it actually says
Code review
Two directions, one skill: reviewing, and being reviewed.
Reviewing
Read the diff against what the change is for, not against your preferences. Order matters — spend attention where damage is expensive:
- Correctness — does it do what it claims, including at the boundaries and on the error path?
- Blast radius — what else consumes this? Signature and schema changes are the ones that break things far away.
- Security and data — untrusted input, authorization, anything logged or persisted.
- Tests — do they pin the new behavior, or do they pass regardless?
- Design — will this shape hold under the next change?
- Style — last, and only where a linter cannot.
Say which category each comment is, and whether it blocks. A review that mixes a data-loss bug with a naming preference in one undifferentiated list wastes the author's judgment.
Receiving
Feedback is a report of a reader's experience, and that part is always valid — if the reviewer misread it, the code is misleading. The proposed remedy is a separate thing and may be wrong.
- Verify before implementing. A suggestion that would break behavior gets a reply, not a commit.
- Disagreeing is fine; ignoring is not. Answer every comment: changed, or why not.
- Do not batch-accept. Applying every suggestion without judgment is how good code becomes incoherent.
- Where a reviewer is factually wrong, show the evidence — the test, the spec, the failing case — rather than asserting.
Never
- Approve your own work, or a change you authored under another name.
- Leave a blocking comment without saying what would unblock it.
- Rewrite the author's approach in a review comment. Propose it, and let them decide.
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 First seen · 43 lines · 72 tokens per session scan A 539e1580e339
code-review is a skill published in the GitHub repository cbrock84/headcount (2,077 stars, last pushed 2d ago), licensed MIT. It adds 72 tokens to every session and 472 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-09-03.
Other skills, from other repositories
guidance
Authoritative guidance for building Claude Code skills, agents, and plugins, vendored into this repository. Use when you need the rules or best practices for a skill, agent, hook, or plugin — designing, reviewing, hardening, or checking one against the guidance. Does not run an interview to build a new skill or agent…
code-quality
Use when validating code quality after modifications -- SOLID compliance, DRY duplication, linter errors, architecture violations. Do NOT use for functional verification (run verification FIRST, then code-quality).
phase-preview
Preview a signed-off design one release phase at a time — cut it down into a series of phase screens, each showing only what exists by that phase with the layout untouched, then put them on a scrubber you drag to watch the screen fill in release by release. Use when the user wants a Phase 1 / MVP version of an…
launch-meta-campaign
Launch a complete Meta Ads campaign — campaign, ad set, and ad(s) — built paused and ready to review. Use when the user wants a new Facebook/Instagram campaign.
radin-review
Review a commit, PR, directory or range for the simplest native solution, maintainability and documented repo rubrics, triage findings with the user. Use for /radin-review, "review and log to backlog".
pdlc-refactor
A refactoring workflow for improving a program's internal structure while keeping its observable behavior the same. It uses existing tests, small changes, and repeated test runs to reduce risk.