> Establish durable brand and voice context for cross-skill consumption. Generates BRAND.md (audience, positioning, do/don't editorial rules, taboo phrases, competitor differentiation) and VOICE.md (existing persona JSON re-expressed as readable prose), both written to the project root. When present, the blog orchestrator auto-loads these files for write, rewrite, brief, outline, calendar, and strategy workflows. Pairs with blog-persona, which manages the structured persona JSON. Use when user says "blog brand", "create brand context", "brand voice doc", "BRAND.md", "VOICE.md", "establish editorial brand", "brand guidelines for blog".
npx skills add https://github.com/AgriciDaniel/claude-blog --skill blog-brand
Generates two project-root files that the blog orchestrator auto-loads for supported writing and planning commands when present:
BRAND.md: who the audience is, what the brand stands for, what to never sayVOICE.md: how the brand sounds, structurally and lexicallyThese are the editorial equivalent of impeccable's PRODUCT.md / DESIGN.md pattern: persistent context that survives across sessions and propagates to every command.
Today, persona JSON (from blog-persona) is loaded by some skills and not others. Topic-cluster context lives inside cluster vaults. Competitor positioning lives nowhere. Each blog command re-derives "what is the brand" from whatever context it has.
BRAND.md and VOICE.md fix this: one canonical source, loaded by the blog orchestrator at the start of every command.
When neither file exists, behavior is unchanged from v1.7.1. Backward compatible.
| Command | Purpose |
|---|---|
| /blog brand init | Interactive interview, writes BRAND.md and VOICE.md to project root |
| /blog brand show | Display current contents (or report missing) |
| /blog brand update | Re-run the interview with current values as defaults |
Run the 5-step interactive interview. Ask each step, wait for response, then proceed. If blog-persona JSON already exists, pre-fill voice answers from it.
Ask:
Ask:
Ask:
Ask:
Ask:
Write to project root as:
# Brand Context
> This file is auto-loaded by all blog sub-skills. Last updated: YYYY-MM-DD.
## Audience
- **Primary**: [role + context]
- **Secondary**: [if any]
- **Expertise**: [level]
- **Active problems**:
- [problem 1]
- [problem 2]
- [problem 3]
- **Common misconceptions**:
- [misconception 1]
- [misconception 2]
## Positioning
- **Official entity name**: [brand/entity]
- **Homepage**: [canonical URL]
- **Logo**: [URL or file path]
- **sameAs profiles**:
- [profile URL 1]
- [profile URL 2]
- **Wikidata Q-ID**: [QID or none]
- **Mission**: [one sentence]
- **Distinctive POV**: [contrarian or non-obvious belief]
- **What we are NOT**: [anti-positioning]
- **Competitors**:
- [Competitor A]: [our one-line differentiator]
- [Competitor B]: [our one-line differentiator]
- [Competitor C]: [our one-line differentiator]
## Editorial Rules
### Always do
- [rule 1]
- [rule 2]
- [rule 3]
### Never do
- [rule 1]
- [rule 2]
- [rule 3]
### Taboo phrases
- [phrase 1]
- [phrase 2]
### Required disclosures
- [disclosure rule]
## Topic Scope
- **In scope**: [pillars]
- **Partial scope**: [adjacent topics]
- **Out of scope**: [topics to refuse]
- **Recurring formats**: [if any]
Write to project root as:
# Voice Context
> This file is auto-loaded by all blog sub-skills. Last updated: YYYY-MM-DD.
## Pronoun stance
[first-person / second-person / third-person / mixed]
## Lexical rules
- **Contractions**: [full / partial / none]
- **Sentence ceiling**: [N words max]
- **Paragraph ceiling**: [N words max, default 150]
- **Summary label**: [Key Takeaways / TL;DR / etc.]
## Headline patterns
- **Favor**: [list]
- **Avoid**: [list]
## Voice fingerprint (from blog-persona)
- Funny vs serious: [0.0 to 1.0]
- Formal vs casual: [0.0 to 1.0]
- Respectful vs irreverent: [0.0 to 1.0]
- Enthusiastic vs matter-of-fact: [0.0 to 1.0]
## Readability target
- Audience tier: [consumer / professional / technical]
- Flesch Grade: [range]
- Flesch Ease: [range]
## Reference samples
- [URL 1] (extracted patterns: [summary])
- [URL 2] (extracted patterns: [summary])
BRAND.md and VOICE.md at project root./blog brand init.Same as Init, but pre-fills every answer with the current value. The user can press enter to accept or type a new value. After collecting all answers, overwrite both files with the new contents and update the Last updated: line.
When /blog write, /blog rewrite, /blog brief, /blog outline, /blog calendar, or /blog strategy runs, the orchestrator (skills/blog/SKILL.md) checks for BRAND.md and VOICE.md at the project root. If present, the contents are injected into the system prompt for downstream agents (blog-researcher, blog-writer, blog-seo, blog-reviewer).
If absent, behavior is unchanged. The orchestrator does not prompt the user to create them; they are opt-in context.
| Concern | blog-persona | blog-brand |
|---|---|---|
| Structured persona JSON for programmatic use | Yes | No |
| Readable brand context for cross-skill prompts | No | Yes |
| Audience and positioning | No | Yes |
| Taboo phrases and editorial don'ts | Partial (don't list) | Full (taboo + disclosures + scope) |
| Competitor differentiation | No | Yes |
| Topic boundaries | No | Yes |
| Voice fingerprint (tone sliders) | Yes (canonical) | Mirror (read-only) |
blog-brand does not replace blog-persona; it consumes it. The persona JSON remains the source of truth for tone dimensions, sentence-length distribution, and contraction frequency. VOICE.md mirrors the readable parts so prompts are self-contained.
If no persona exists when /blog brand init runs, the voice questions still produce a VOICE.md. Users who want programmatic enforcement can run /blog persona create after.
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
Structured manuscript/grant review with checklist-based evaluation. Use when writing formal peer reviews with specific criteria methodology assessment, statistical validity, reporting standards compliance (CONSORT/STROBE), and constructive feedback. Best for actual review writing, manuscript revision. For evaluating claims/evidence quality use scientific-critical-thinking; for quantitative scoring frameworks use scholar-evaluation.
Agile product ownership toolkit for Senior Product Owner including INVEST-compliant user story generation, sprint planning, backlog management, and velocity tracking. Use for story writing, sprint planning, stakeholder communication, and agile ceremonies.
Expert guidance for writing secure, reliable, and performant Claude Code hooks - validates design decisions, enforces best practices, and prevents common pitfalls. Use when creating, reviewing, or debugging Claude Code hooks.
Use when creating or developing anything, before writing code or implementation plans - refines rough ideas into fully-formed designs through structured Socratic questioning, alternative exploration, and incremental validation
Structured manuscript/grant review with checklist-based evaluation. Use when writing formal peer reviews with specific criteria methodology assessment, statistical validity, reporting standards compliance (CONSORT/STROBE), and constructive feedback. Best for actual review writing, manuscript revision. For evaluating claims/evidence quality use scientific-critical-thinking; for quantitative scoring frameworks use scholar-evaluation.
Conducts structured requirements workshops to produce feature specifications, user stories, EARS-format functional requirements, acceptance criteria, and implementation checklists. Use when defining new features, gathering requirements, or writing specifications. Invoke for feature definition, requirements gathering, user stories, EARS format specs, PRDs, acceptance criteria, or requirement matrices.
Use markdown formatting when drafting content intended for external systems (GitHub issues/PRs, Jira tickets, wiki pages, design docs, etc.) so formatting is preserved when the user copies it. Load this skill before producing any draft the user will paste elsewhere.
Take agricidaniel/blog-brand 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.