content-calendar

Content Calendar

Um calendário de conteúdo não é uma grade em branco que você preenche na base do heroísmo — é um ritmo operacional sustentável: uma estrutura recorrente que gera posts para que você nunca fique encarando uma página vazia, em uma cadência que você realmente consegue manter. Duas ideias guiam tudo aqui:

1. Cadência equivale a capacidade. O motivo número um pelo qual calendários falham é o excesso de compromissos. Um piso sustentável que você mantém por um ano vence um plano ambicioso abandonado em fevereiro.
2. Um esqueleto recorrente vence uma página em branco. Defina buckets repetíveis (pilar × formato × slot) e algumas séries nomeadas — então cada ciclo é preencher lacunas, não inventar do zero.

Este skill possui o sistema recorrente. Preencher uma semana/mês específica com posts reais é batch-content-plan; as escolhas de canal/objetivo de nível superior são social-strategy. Ele fica entre elas: estratégia + pilares → o ritmo repetível → (por ciclo) batch-content-plan → skills de conteúdo → agendador.

Passo 0 — Leia a base primeiro

Carregue social-strategy.md, content-pillars.md e brand-profile.md. Se os pilares não existirem, redirecione para content-pillars ou derive pilares provisórios leves — o calendário deve mapear para temas, não flutuar solto.

Passo 1 — Dimensionar a cadência para a capacidade real

Estime a capacidade honesta (tempo, pessoas, orçamento, o piso da semana ruim) e defina uma cadência sustentável por plataforma — diferente por plataforma, não um número único para todas. Escolha uma ou duas plataformas principais para fazer bem. Use reaproveitamento para cobrir mais sem aumentar proporcionalmente o trabalho. Veja references/cadence-and-capacity.md.

Passo 2 — Construir o esqueleto recorrente

Mapeie buckets — pilar × formato × slot/dia/platforma — de modo que cada slot seja uma instrução permanente, não um post fixo. Distribua entre os pilares (o pilar principal recebe os slots principais) e varie os formatos por design. Veja references/calendar-structure.md.

Passo 3 — Projetar uma ou duas séries recorrentes

Adicione uma franquia nomeada em um slot fixo ("Terça do Desmonte", "Registro de Build") para antecipação, menos fadiga de decisão e reconhecimento. Uma ou duas — não todos os slots.

Passo 4 — Datas âncora + reservar espaço reativo

Adicione âncoras temporais (lançamentos, eventos relevantes) sobre o esqueleto, e reserve ~20–30% para conteúdo reativo/oportuno com um ou dois slots abertos por semana (passe a pesquisa de tendências ao vivo para trend-jacking). Estruture para consistência; espaço reativo para relevância.

Passo 5 — Definir o ritmo operacional

Defina o fluxo de trabalho que sustenta isso: um ritual de planejamento (formato mensal, preenchimento semanal, engajamento diário), criação em lote, e um buffer/fila para que uma semana ruim não quebre a sequência. Atribua papéis se houver uma equipe. Veja references/operating-rhythm.md.

Passo 6 — Entregar + hand-off

Produza a cadência + esqueleto recorrente + séries + divisão planejado/reativo + âncoras, mais uma semana de amostra preenchida para tornar concreto. Em seguida:

• Preencher um período específico → batch-content-plan.
• Escrever cada peça → os skills de conteúdo; adaptar entre plataformas → cross-platform-repurposing.
• Agendar → scheduling-and-queue (no buffer).

Barra de qualidade — auto-verificação

• A cadência está dimensionada para a capacidade (o piso, não o teto), e por plataforma?
• Existe um esqueleto recorrente de buckets (pilar × formato × slot), não uma lista única?
• Existem uma ou duas séries nomeadas?
• O espaço reativo está reservado (~20–30%) junto com âncoras sensatas?
• Existe um ritmo de planejamento + buffer, não apenas uma grade?
• Os hand-offs para batch-content-plan / skills de conteúdo / agendador estão claros?
• O multi-plataforma é viabilizado por reaproveitamento, sem nenhuma alegação de analytics?

Casos de borda & pushback

• Excesso de compromissos ("5×/dia em 6 plataformas sozinho") → redimensione com força para um piso sustentável; explique o porquê; use reaproveitamento.
• Muito rígido ("travar 90 dias, sem lacunas") → reserve slots reativos; um calendário totalmente travado não pode surfar tendências.
• "Só me dê 20 ideias de posts" → isso é batch-content-plan; ofereça o esqueleto recorrente aqui.
• "Construa em torno dos nossos melhores horários/melhores performers" → WoopSocial não tem analytics; ofereça dados nativos que o usuário puxa ou revisão qualitativa; não alegue otimização baseada em dados.
• Sem pilares/estratégia ainda → redirecione para content-pillars / social-strategy ou derive pilares provisórios; não flutue solto.
• Continua abandonando cronogramas → corrija o ritmo (piso sustentável + buffer + ritual), não apenas a grade.

Skills relacionados

• social-strategy — as escolhas de canal/objetivo acima disso.
• content-pillars — os temas que o esqueleto mapeia; brand-profile, voice-builder.
• batch-content-plan — preenche um período específico com briefs (a execução por ciclo).
• cross-platform-repurposing — torna o multi-plataforma sustentável.
• Skills de conteúdo (caption-writer, reels-script, tiktok-script, carousel-writer, thread-writer, linkedin-post-writer) — escrevem cada slot.
• trend-jacking — os slots reativos; scheduling-and-queue — enviam para o buffer.

Referências

• references/cadence-and-capacity.md — dimensionar cadência para capacidade; normas por plataforma; reaproveitamento; buffer.
• references/calendar-structure.md — buckets, pilar × formato × slot, séries, planejado/reativo, âncoras.
• references/operating-rhythm.md — o ritual de planejamento, criação em lote, buffer, revisão honesta, hand-offs.
• references/examples.md — calendários trabalhados (solo + equipe) com semanas de amostra, vs um excessivamente ambicioso.