social_media_sops v1.0.0

name: "social_media_sops" description: "Build a complete social media team SOP package: risk-tiered approval chains, RACI roles, escalation paths, a voice document, and a publish audit trail. Triggers when a brand needs its social team operations documented, approval workflows designed, escalation rules defined, or a new social hire onboarded with real procedures."

Social Media SOPs

Purpose

Turn tribal knowledge into a written operating package a social team can actually run: who approves what and how fast, who does what on the team, how issues escalate, how the brand sounds, and what gets recorded for every publish.

Workflow

1. Gather inputs. Brand name, the accounts in scope, team roster with names and hats, tools used (scheduler, shared inbox), industry constraints (regulated, legal review required). Ask for what is missing; do not invent names or roles.
2. Classify content risk. Define 3-4 risk tiers (routine, standard, high-risk, crisis). Routine posts take the short path, high-risk takes the long one. Details in references/approval-chains.md.
3. Draw the approval chains. For each tier: the reviewer sequence, the SLA for each step, the backup approver, and what "silence" means (does no response approve, or does the post stall). Use the templates in templates/.
4. Set escalation paths. Define the tiers: what the social manager handles alone, what goes to PR/comms, what goes to legal or executives. Include the decision tree and response SLAs. See references/escalation-paths.md.
5. Write the voice doc. Personality traits, voice attribute chart with do/don't examples, tone-by-context table, banned words. Keep it one scannable page. See references/voice-doc.md.
6. Generate the package. Feed the collected facts into bin/sop_pack.py to emit the full SOP markdown, or fill in the templates/ by hand.
7. Lock the audit trail. Every publish records: post, author, approver(s), approval timestamps, risk tier. That is how you survive an internal review or a regulator.

Output Contract

• A generated SOP.md (or filled templates) covering: team roster and RACI, approval routes per risk tier with SLAs, pre-flight checklist, escalation tiers with owners and response times, voice quick reference, publish audit rules.
• Templates provided: templates/approval-request.md, templates/raci-matrix.md, templates/escalation-playbook.md, templates/voice-doc-template.md.
• Every role named is a real named person or an explicitly marked vacancy. No "someone should" language.

Operating Rules

1. Never invent facts: team names, tools, account handles, and legal requirements come from the user or a primary source.
2. Silence is never approval unless the team explicitly adopted a default-advance rule in writing. When in doubt, the post waits.
3. Crisis response routes through the escalation tiers in references/escalation-paths.md. Do not publish crisis messaging through the routine approval path.
4. Voice guidance here is the operating doc, not the craft. For developing a voice from scratch, use the brand_voice skill; this SOP references the resulting charter.
5. The SOP names a backup approver for every gate. If a gate has no named backup, the SOP is incomplete.
6. Review the package quarterly. Outdated SOPs are worse than none: people trust the document and stop thinking.