Decides what content to make and why — topic territory, format mix, cadence, and how content connects to a business outcome rather than to traffic. Use this to plan a content program, choose topics, build an editorial calendar, decide which formats and platforms to commit to, or diagnose why content is producing audience but not results.
npx skills add https://github.com/cbrock84/headcount --skill content-strategy
A content program works when a defined audience learns to expect a specific kind of value from you.
That requires a territory narrow enough to own: the intersection of what you know unusually well,
what your buyer needs help with, and what nobody else is covering properly.
Test it: could a competitor publish your last ten pieces without anyone noticing? If yes, you have a
topic list.
Every piece should have one job, and the job dictates the format:
objection answers.
Programs skew heavily to reach and then wonder why the audience does not convert. Budget across all
four deliberately.
Pick a frequency sustainable at your worst week, not your best. Irregular publishing costs more than
infrequent publishing, because the audience stops expecting you.
Two platforms done properly beat five done adequately. Choose by where the audience already is and
which format you can actually sustain — not by reach numbers.
Every piece should be planned with its derivatives: the long piece is the source, and the short-form
versions are extracted, not written separately.
Measure by job. Reach content is judged on reach; conversion content on conversion. Judging
everything on traffic is why content programs drift toward the reach end and stay there.
Set a review point where a topic that is not working gets dropped. Content strategies fail by
accumulation.
Territory, audience, the four-way format budget, cadence, platforms with rationale, first ten pieces
with the job of each, and what you are choosing not to cover.
Take cbrock84/content-strategy from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.