content-brief-authoring
How to author a content brief that actually guides a writer (human or AI) to produce a piece that ranks, converts, or both. Per-piece editorial brief: target keyword and cluster, search intent, audience and JTBD, heading structure, entity coverage for AEO/GEO, internal linking strategy, success criteria. The middle path between thin briefs (a keyword and a deadline) and thick briefs (a 4-page document nobody reads). Triggers on content brief, brief the writer, brief the article, brief authoring, content brief template, brief audit, per-piece brief, editorial brief, target keyword brief, search
npx skills add rampstackco/claude-skills --skill content-brief-authoring --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
The skill instructs editors to create a per-piece editorial brief that targets a keyword and cluster, defines search intent, audience, and job-to-be-done, specifies a heading structure, entity coverage, internal linking, and success criteria. It promotes an effective brief format (one to two pages) with 12 concrete fields that earn their keep, and contrasts this with thin and thick briefs. It emphasizes coordinating between program-level strategy (content-strategy) and the writing step (content-and-copy).
How it works
It prescribes briefing a single content artifact: specify 12 fields including 1) Target keyword + supporting cluster, 2) Search intent classification, 3) Target audience, 4) Job to be done, 5) Word count/depth target, 6) Heading structure outline, 7) Required entities/citations, 8) Internal linking strategy, 9) External proof points, 10) Anti-patterns, 11) Success criteria, 12) Author voice and tone reference. It instructs that the brief should be 1–2 pages with every field earning its keep, and warns to remove fields that do not change writer behavior. It situates the brief between content-strategy decisions and content-and-copy execution, and describes how to use the brief in a handoff to a writer (human or AI). It also mentions templates and references for detailed execution. The procedure emphasizes mapping SERP and intent to format, and ensuring the brief provides actionable guidance rather than extraneous context.
When to use it
Use to briefing a writer (human or AI) on an individual content piece, auditing existing briefs, building a brief template for a program, or routing a brief-generation pipeline through tools.
What it can touch
The skill references tools like Frase, AirOps, Surfer SEO for entity gaps and linking strategies, and mentions a workflow that uses those tools to populate the 12 fields (e.g., entity coverage, internal/external linking guidance). It notes that the brief should specify outbound and inbound linking in detail and how to integrate with existing content.
Caveats
License noted as MIT. It emphasizes a one-to-two-page brief with 12 fields and discourages unnecessary fields, avoiding thick or generic briefs. It warns that fields not affecting writer behavior should be removed. It frames the brief as a contract between editorial leader and writer and describes the handoff process for AI or human writers.
# Content Brief Authoring A senior content strategist's playbook for authoring per-piece content briefs that actually guide writers to produce content worth publishing. Most content briefs are some flavor of broken. The thin version is a keyword, a word count, and a deadline; the writer fills in everything else from scratch and the output is generic. The thick version is a 4-page document nobody reads, that the writer skims for the headline and the outline and ignores the rest. Either way, the brief failed at its job: making the writer's work easier and the output more predictable. This skill is the middle path. It defines the 12 fields that earn their keep in a content brief, the fields that bloat without helping, and the discipline of writing briefs that route a writer (human or AI) toward a content piece that ranks for its target keyword, gets cited by AI engines, converts the right reader, or whatever the success criteria say. It assumes you have decided what to write (see `content-strategy` for program-level decisions) and now you are briefing each piece. The piece itself gets written separately (see `content-and-copy`). When to use this skill: briefing a writer (human or AI)
- What this skill is for
- Thin vs thick vs effective briefs
- The 12 fields of an effective brief
- Search intent classification
- Heading structure design
- Entity coverage for AEO and GEO
- Internal linking strategy
- Brief templates by content type
- The brief-to-writer handoff
- Brief governance
- Common failure modes
- The framework: 12 considerations for brief authoring
- Reference files
- Closing: the brief is the contract
What does the content-brief-authoring skill do?
How to author a content brief that actually guides a writer (human or AI) to produce a piece that ranks, converts, or both. Per-piece editorial brief: target keyword and cluster, search intent, audience and JTBD, heading structure, entity coverage for AEO/GEO, internal linking strategy, success criteria. The middle path between thin briefs (a keyword and a deadline) and thick briefs (a 4-page document nobody reads). Triggers on content brief, brief the writer, brief the article, brief authoring, content brief template, brief audit, per-piece brief, editorial brief, target keyword brief, search
How do I install it?
Run `npx skills add rampstackco/claude-skills --skill content-brief-authoring --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From rampstackco/claude-skills, a repository with 515 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.