Squad content-geo: como o Sinkra Hub automatiza publicação GEO em escala

Por que o squad tem só 2 agentes e não 7 como no design inicial?

A primeira proposta do squad tinha sete agentes especializados: cartographer, editor, schema-engineer, internal-linker, citation-monitor, publishing-orchestrator e writer. Análise crítica via princípio KISS revelou que cada um teria menos de um user real — eram skills disfarçadas de agents. A versão final, formalizada na PRD v0.4.1, tem dois agentes: geo-chief decide e roteia, geo-writer executa o pipeline. Skills carregam o trabalho que num design ingênuo viraria agent.

O critério canônico, registrado em .claude/rules/kiss-no-overengineering.md, é direto: agent só justifica existência quando há decisão criativa não-mecânica. Pesquisa de keyword é procedimento repetível com input/output bem definido — vira skill (research-keyword). Schema enrichment é determinístico — vira script (enrich-schema.cjs). Citation monitoring é amostragem padronizada — vira skill (monitor-citations). Cada um foi colapsado e o resultado é manutenção mais barata, onboarding mais rápido e menos superfície para drift.

Quem é o geo-chief e o que ele decide?

O geo-chief é o entry agent do squad e o orquestrador puro. Função única: decidir e rotear. Recebe missions via slash commands como /geo:geo-chief *generate-from-keyword, *generate-from-youtube, *build-cluster e *audit-fork. Para cada mission, executa nove passos do command flow: parse de args, load do wrangler.toml do fork, load do editorial-manifesto.yaml do business, build do briefing, invocação do writer, recebimento das phases, decisão sobre o resultado, emissão de handoff e auto-delegate para @devops publicar.

O chief nunca executa lógica de domínio. Se mission carece de --fork, HALT com pedido de fork. Se manifesto não existe, HALT com sugestão de *interview-founder. Se writer reporta originality fail na Phase 2, chief decide entre retry com novo ângulo, pivot de keyword ou escalar para @copy-chief. Constitution-compliant: chief nunca chama API de publish diretamente — sempre via @devops em Step 9 do command flow.

Quem é o geo-writer e o que ele executa?

O geo-writer é o executor full-stack do pipeline. Não é user-facing — não tem comandos próprios, só é invocado pelo chief com um briefing object completo. Sua identidade documentada: "executor metódico, evidence-grounded, blocking on quality, brand-voice fidelity". Recebe {mission_id, seed, fork_path, business_slug, lang, manifesto} e executa cinco phases / nove sub-steps emitindo output incremental por phase em outputs/content-geo/missions/{mission_id}/phase-{n}.yaml.

O writer carrega skills on-demand a cada phase. Phase 1 invoca tasks/research-keyword.md. Phase 2 aplica rules/originality-gate.md. Phase 3 lê templates/article-skeleton.html e rules/geo-skeleton-contract.md. Phase 4.1 invoca tasks/verify-claims.md com Exa+Firecrawl. Phase 4.2 roda scripts/score-extractability.cjs. Phase 5.1 invoca scripts/enrich-schema.cjs e scripts/publish-article.cjs. Cada phase emite output ANTES de proceder — crash em phase N preserva phase 1 a N-1, e mission é resumível pelo mission_id.

Como funciona o pipeline 5 phases / 9 sub-steps?

O pipeline é Vish-aligned: sete sub-steps explícitos da metodologia Vish (cenário, concorrentes, tipo, fan-out, brief, draft, verify-final) mais dois adicionais SINKRA-native (score, publish). Phase 1 Research: 1.1 cenário com keywords e question families; 1.2 análise de concorrentes que aparecem em queries; 1.3 decisão do tipo de artigo (tutorial, listicle, guia, comparison, review, news). Phase 2 Outline + Originality: 2.1 outline + check de originalidade; se insuficiente, fan-out de pesquisa paralela.

Phase 3 Brief + Draft: 3.1 brief estruturado antes do draft (Vish: separar brief de draft); 3.2 draft em HTML respeitando geo-skeleton-contract (7-10 H2s, FAQ, KT, brand voice). Phase 4 Verify + Score: 4.1 verify-claims com Exa+Firecrawl, threshold pass rate >=85% para publish; 4.2 score em readability + brand_voice_match + citation_density + extractability, threshold >=70 para auto-publish. Phase 5 Publish: 5.1 enrich-schema + publish via API REST do fork. Target p95 de oito minutos por artigo (NFR11).

O que é o originality gate na Phase 2 e por que ele bloqueia?

Originality gate é a checagem antes de gerar draft. Cinco categorias de ângulo proprietário definidas no editorial-manifesto.yaml de cada business: thesis_contrarian, internal_experience, proprietary_data, practical_application, risk_pitfall. O outline precisa clearar pelo menos três dos cinco. Falha em três significa derivativo, e derivativo perde para a fonte original em retrieval — publicar nessa condição só polui o domínio.

O gate é blocking por design. Quando falha, writer emite phase-2.yaml com verdict: BLOCKED e motivo concreto (qual ângulo falta), e devolve controle para o chief. Chief nunca faz bypass — Constitution-compliant. As opções são: retry com angle injection (e.g., enriquecer a fonte com dado proprietário do business), pivot para keyword menos commodificada, ou escalation para @copy-chief. Esse gate é também a defesa do squad contra spam de conteúdo IA-gerado: artigo gerado sem ângulo proprietário não passa pelo gate, então não vira draft, então não vira publish.

Por que verify-claims usa Exa+Firecrawl e não Perplexity?

A escolha vem da heurística VS_006 do mind do Vish: synthesis não é extraction. Perplexity sintetiza resposta a partir de várias fontes — bom para descobrir, ruim para verificar fato discreto. Exa retorna trechos exatos das páginas (formato Highlight) — bom para verify factual claim. Firecrawl extrai conteúdo limpo de URL específica — bom para validar atribuição direta. A combinação cobre o que verify precisa: claim, source URL, exact text supportando.

Threshold de pass rate é tier: >=95% libera auto-publish, 85-94% emite warning e vai para review queue, <85% bloqueia publish. O risco que o gate protege é legal: artigo afirmando algo errado sobre concorrente vira passivo jurídico real (Vish: "risco legal real ao errar sobre concorrente"). Verify é o cost center do pipeline (50-70% do budget de LLM por artigo) justamente porque é onde o squad é mais conservador.

Como o squad respeita a Constitution AIOX?

Quatro pontos de compliance explícitos. (1) Agent Authority: chief nunca executa push, PR, deploy, MCP, ou D1 migration — sempre delega para @devops ou @db-sage. Step 9 do command flow é auto-trigger: depois de mission report com verdict PUBLISH-READY, chief escreve devops-handoff.md com paths, curls, checklist e rollback, e invoca @devops via Agent tool.

(2) CLI First: todos os comandos do squad são CLI-only. Sem UI, sem dashboard. (3) Story-Driven: cada mission gera mission_id com traceability completo em outputs/content-geo/missions/{mission-id}/ (briefing, phase-1..5, mission-report). (4) KISS: dois agentes, estrutura flat de squad, skills no lugar de agents inflados. Cada compliance ponto é também um veto: chief que tentar push direto trava no hook enforce-git-push-authority.sh; mission sem mission_id falha critério de completion; squad com mais de dois agentes triggera revisão de KISS gates.

Quais comandos CLI o squad expõe?

Quatorze comandos, todos prefixados com /geo:geo-chief: (1) *help; (2) *generate-from-keyword; (3) *generate-from-youtube; (4) *build-cluster (pillar + 5-8 spokes interlinked); (5) *report-citations (window 7d/30d/90d); (6) *audit-fork (drift entre template canônico e fork); (7) *audit-orphans (artigos publicados sem links de entrada).

(8) *audit-blog-geo (full-stack health audit); (9) *fix-coverage-gaps (gaps editoriais com auto-generate opcional); (10) *review-queue; (11) *interview-founder (gera editorial-manifesto.yaml); (12) *execute-mission (roda mission pre-definida); (13) *status; (14) *exit. Cada comando exige --fork apps/blog-{business}-{lang}/; sem fork, chief HALT.

Como content-geo se compara com aigrowthagent.co, seomachine.ai, ALwrity e claude-seo?

O squad content-geo nasceu de pesquisa direta sobre quatro concorrentes — dois SaaS proprietários e dois open-source citados na PRD v0.4.1. A matriz abaixo mostra onde o squad bate, onde empata e onde perde explicitamente, sem floreio comercial.

Top-line

Matriz por dimensão (12)

Verdict: content-geo cobre aproximadamente 80% das funcionalidades de seomachine.ai com 2 agents em vez de 7, sem custo de SaaS recorrente, com integração nativa em hub-and-spoke e governance enforced via Constitution. Perde para os SaaS em maturidade de citation monitoring (que está em roadmap v2 do squad) e em interface não-CLI (decisão deliberada via ADR — CLI First). Para times multi-business e CLI-fluentes, a equação favorece content-geo; para single-business com time não-técnico, SaaS pode fazer sentido.

Quais limites operacionais estão registrados em NFR?

Três limites operacionais críticos. NFR11: p95 de oito minutos por artigo no pipeline completo, do *generate-from-keyword até o POST /api/publish/{slug}. NFR15: verify pass rate mínimo de 95% para auto-publish; abaixo disso vira review queue ou bloqueio. NFR16: teto de cinco artigos por dia por fork — limite Vish para evitar spam de publicação que afeta sinal de domínio em retrieval. Chief enforça o teto contando artigos publicados nas últimas 24h via GET /api/articles?status=published.

Os NFRs estão na PRD v0.4.1 como contrato testável. Eles são citáveis tanto pelo squad em runtime (chief consulta a tabela de NFR para decidir warn/block) quanto por audit externo: *audit-blog-geo reporta artigos publicados que violaram NFR retroativamente. Sem NFRs, "qualidade" vira opinião; com NFRs, vira gate executável.