Verificando acesso...

MÓDULO 3.4

📊 Linear + Notion sync

Engenharia vive no Linear, marketing/produto vivem no Notion. Cowork sincroniza: feature done no Linear vira release note no Notion. Sem cópia manual.

6
Tópicos
40
Minutos
Avanç.
Nível
Prático
Tipo
1

🧱 Por que dois sistemas

Cada ferramenta tem virtude. Linear: velocidade pra eng (atalhos, cycles, GitHub sync nativo). Notion: flexibilidade pra docs, marketing, processo. Forçar tudo em um só vira fricção pros dois lados.

📋 Quem usa o quê

TimeSistemaPor quê
EngenhariaLinearVelocidade, GitHub PR sync, cycles
ProdutoNotion + LinearSpecs em Notion, execução em Linear
MarketingNotionDocs, planning, calendário editorial
Ops/FinanceNotionDatabases custom, dashboards
2

🔄 Os 4 sync mais úteis

Não tente sincronizar tudo. Esses 4 cobrem 90% do valor sem complexidade.

1

Linear DONE → Notion release notes

Issue marcada done no Linear (com label "user-facing") vira entry em Notion "Changelog 2026" automaticamente.

2

Notion spec → Linear issue

Doc no Notion com label "ready-for-dev" vira issue no Linear no projeto correto.

3

Linear roadmap → Notion dashboard

Roadmap (Q1, Q2…) do Linear espelhado em Notion pra visibilidade não-eng.

4

Bug em Notion → Issue Linear urgente

Reclamação cliente capturada em Notion vira issue Linear P0 com link de volta.

3

🚀 Prompt: release notes auto

O sync mais útil. Toda terça (sprint review), Cowork compila tudo done na semana e gera changelog público.

Toda terça 14h:

1. Pega Linear issues DONE na última semana com label
   "user-facing" ou "release-note"
2. Pra cada, escreve entry de release notes:
   - Título user-friendly (não jargão técnico)
   - 1-2 frases do impacto pro user
   - Screenshot se PR tem (busca em GitHub)
   - Categoria: New / Improved / Fixed
3. Adiciona ao Notion page "Changelog 2026"
4. Posta também no Slack #releases (com link Notion)

Tom: amigável, focado no benefício. Não copie título da issue.

Antes de publicar, me mostra rascunho.
4

⚠️ Conflitos de fonte da verdade

A pergunta crítica: quem é dono do dado? Sem regra clara, sync vira ping-pong infinito. Defina UM sistema autoridade por tipo de info.

📌 Source of truth por tipo

  • Specs e propostas: Notion (vai pra Linear quando ready)
  • Issues de eng: Linear (Notion só espelha)
  • Changelog: Notion (Linear é fonte mas Notion é UI pública)
  • Roadmap estratégico: Notion (Linear executa)
  • Status real-time: Linear (sem espelho — vai direto)
5

🎯 Padrões de label

Cowork precisa de pista pra saber o que sincronizar. Labels (Linear) e tags (Notion) são essa pista.

# Labels Linear
- user-facing  → entra em changelog
- internal     → só visível interno (não sync)
- bug-from-customer → cria entry "Fixed" + ping suporte
- breaking-change → alerta especial no changelog

# Tags Notion
- ready-for-dev   → cria issue Linear
- needs-spec      → bloqueado, não sync
- shipped         → não sync (já tá done)
- archived        → ignora
6

🛠️ Manutenção do sync

Sync que dá pau silenciosamente é pior que sem sync. Heartbeat semanal + auditoria mensal.

✓ Manter saudável

  • Heartbeat semanal no Slack
  • Auditoria mensal de divergências
  • Labels com convenção clara
  • 1 dono do sync (não comitê)

✗ Evite

  • Sync bidirecional sem regra clara
  • 10 labels sem documentação
  • Cada um cria label do jeito dele
  • Sync silencioso (sem heartbeat)

📚 Resumo do Módulo

Dois sistemas é OK — Linear (eng) + Notion (resto)
4 sync que cobrem 90% — release notes, spec→issue, roadmap, bug→issue
Release notes auto — terça 14h, label user-facing → Notion + Slack
Source of truth por tipo — sem ping-pong
Labels = convenção — sem labels, sync não sabe o que mover
Heartbeat + auditoria — silêncio é pior que sem sync

Próximo Módulo:

3.5 — 💳 Stripe analytics