Pesquisa para blog
Um briefing é a diferença entre um post que afirma coisas e um post que afirma coisas que alguém pode verificar. Cada preço, cada reclamação citada e cada "a maioria das ferramentas para nos 60 fps" no blog é uma afirmação sobre o produto de outra pessoa, e uma errada desacredita todas as certas na página. Esta habilidade produz a lista verificada a partir da qual o escritor trabalha, e nada mais: ela não escreve o post.
Os fatos da Prequel não vêm da web. Eles vêm do repositório, e a primeira seção abaixo diz onde. Procurar por "Prequel screen recorder" encontra uma avaliação desatualizada ou um produto diferente com o mesmo nome.
Onde as coisas vão
| Caminho | O que é |
|---|---|
.context/research/<slug>.md | O briefing. Gitignorado; andaime, não entregue. |
apps/web/src/content/competitors.ts | Preços e recursos verificados para os seis com páginas |
.claude/skills/comparison-posts/assets/quotes.json | Cada citação do Reddit já capturada |
apps/web/src/content/posts.ts | O que o blog já cobre |
O briefing não é commitado porque o post carrega suas próprias evidências: preços
na tabela com uma data de verificação, threads do Reddit linkadas na citação, e
qualquer coisa que precise sobreviver ao post movida para competitors.ts ou
quotes.json. Um briefing commitado fica desatualizado na primeira vez que um preço
muda e ninguém o atualiza, e então se torna uma segunda fonte de verdade que discorda
da página.
Fase 1: o mapa do tópico
Antes de pesquisar qualquer coisa, escreva o que é o post e confirme. Três linhas, na resposta:
-
A pesquisa que ele responde. "screen recorder mac no watermark", "how to record system audio on mac". O post é construído para esta consulta, e ela decide o slug, a pergunta definidora e o FAQ.
-
O gênero. Um roundup vai para
[[comparison-posts]]; um post "melhores alternativas a " vai para[[alternatives-posts]]; um how-to, explicador ou pilar vai para[[guide-posts]]. Eles exigem pesquisa diferente: um roundup precisa de preços para dez ferramentas, um guia precisa dos fatos do macOS e das reclamações. -
A pergunta definidora. Todo post abre uma seção
## O que é <coisa>?e a pergunta precisa ser única no blog. Gerepo os posts existentes antes de propor uma:grep -h "^## O que é\|^## Como você" apps/web/src/content/blog/*.mdx
Depois, o pilar sob o qual ela se situa, a partir de posts.ts. Hoje há três:
screen-recording-on-mac, product-demo-videos,
screen-recording-for-youtube. Um post sem pilar é um pilar, e isso é uma
decisão do usuário, não do briefing.
Apresente isto e aguarde. Pesquisar no gênero errado é uma hora perdida.
Fase 2: fatos da própria Prequel, a partir do repositório
Leia estes antes da web, para que o briefing contraste os concorrentes com o que a Prequel realmente entrega, em vez de contra o que um mecanismo de busca lembra:
| Fato | Fonte |
|---|---|
| Resolução, fps, codecs, saída | SPECS em apps/web/src/components/landing/LandingBody.tsx |
| O que a primeira passagem automática faz | ALREADY_DONE no mesmo arquivo. Nada mais é automático. |
| Preço, duração do teste | apps/web/src/lib/pricing.ts, nunca um número da memória |
| Respostas do produto | apps/web/src/lib/faq.ts |
| Linhas de recursos e o que afirmamos | FEATURE_ROWS em competitors.ts |
| Requisitos | Apple Silicon, macOS 14 ou superior, concessão de Gravação de Tela |
Duas regras de [[no-dead-air-claim]] e [[site-copy]] se aplicam tanto ao briefing
quanto ao post. Prequel não corta, aparara nem remove silêncios; cortar
é uma passagem manual na timeline. E nada vai para o briefing como uma deficiência
da Prequel: onde um rival realmente vence em algo, o briefing registra
para que o escritor saiba não abordar o assunto, marcado não escreva.
Fase 3: os streams de busca
Firecrawl é a ferramenta de busca. firecrawl_search retorna títulos, trechos e
URLs; firecrawl_scrape busca uma página como markdown; firecrawl_map lista as
páginas de um site quando um fornecedor esconde o preço três cliques abaixo. Execute os streams
que o gênero precisa, em paralelo como subagentes quando houver mais de três
ferramentas a cobrir, inline caso contrário.
Stream 1, fatos do fornecedor. Para cada ferramenta que o post nomeia: a página de preços
do próprio fornecedor, raspada e lida. Registre cada nível com seu período de faturamento,
porque um valor mensal citado sem o anual é o erro mais prejudicial
que uma comparação pode cometer, e é verificável em um clique. Registre a data.
Se a página for renderizada por JS e firecrawl_scrape retornar uma casca vazia,
diga isso e busque-a com Chrome headless ([[headless-chrome-screenshots]] em
memória). Para os seis em competitors.ts, compare com o que está lá e
sinalize qualquer desvio; a correção é uma edição naquele arquivo, não um número no briefing.
Os fatos que importam para este blog, por ferramenta, porque são aqueles em que a Prequel vence: maior resolução e taxa de quadros em cada plano, marca d'água no nível gratuito ou teste, limite de duração da gravação, se a renderização é local ou enviada, licença única ou assinatura, se a câmera é uma faixa separada que pode ser re-enquadrada após a captura.
Stream 2, do que as pessoas reclamam. Reddit através de
firecrawl_search com includeDomains: ["reddit.com"], além de Hacker News,
G2 (as avaliações de duas e três estrelas, onde estão as reclamações específicas) e
X. Para um post de alternativas, registre o suficiente de cada um para desenhar um carta: título
literal, subreddit ou handle, autor, data, pontuação, contagem de comentários, primeiro
parágrafo. [[alternatives-posts]] renderiza estes.
firecrawl_scrape recusa reddit.com completamente, então o título de uma thread, trecho
e URL são tudo o que volta, e isso é suficiente para uma citação. Consultas
que funcionam: "<ferramenta> pricing" reddit, "<ferramenta> alternatives", "<ferramenta> watermark", "<ferramenta> slow", record system audio mac reddit.
Prefira uma queixa genuína a um post de lançamento. Várias threads do Loom nos resultados
de busca são fundadores anunciando sua própria alternativa com um título que parece uma
reclamação. Verifique quotes.json primeiro: uma thread já capturada lá tem uma
captura de tela em public/blog/quotes/ e não precisa de novo trabalho.
Stream 3, o que o blog já diz. Leia posts.ts e os MDXs existentes
para qualquer coisa sobre o tópico. O briefing lista os posts para os quais o novo deve
linkar (cinco ou mais, com o texto âncora), o pilar e qualquer frase em um
post existente que o novo contradiria. Dois posts discordando
sobre o nível gratuito do Loom é pior do que qualquer um estar errado sozinho.
Stream 4, os fatos do macOS. Para um guia, o que QuickTime e Cmd+Shift+5 podem ou não podem fazer no macOS atual, a partir das páginas de suporte da própria Apple, com a URL. Estes mudam por versão e o blog os afirma como fato.
Stream 5, números. Qualquer estatística na qual o post possa se apoiar (tempo de exibição com som desligado, taxas de conclusão de vídeo de demonstração) rastreada até sua fonte primária, com data, e descartada se tiver mais de três anos ou se a trilha terminar em outro blog. Um número que o escritor não pode linkar é um número que o escritor não pode usar.
O que uma fonte precisa atender
- Viva e carregando o conteúdo que o briefing diz. Use
firecrawl_scrape; um 200 que serve "Access is temporarily restricted" não é uma fonte. G2, Capterra e Trustpilot todos respondem assim a uma busca headless e não são utilizáveis aqui. - Página do fornecedor acima de site de avaliação. Página de detalhes acima de resumo. Eles discordam mais frequentemente do que se espera.
- Dada. Preços, estatísticas e comportamento do macOS carregam todos a data verificada.
- Uma citação do Reddit ou HN é a URL da thread mais o subreddit ou handle. Uma paráfrase sem link não é uma citação, e uma captura de tela também não.
- Nada que o post linkará. O blog linka apenas hosts de citação: reddit.com, news.ycombinator.com, x.com, g2.com, e github.com ou producthunt.com para uma figura de escala. URLs de fornecedores vão no briefing para verificação e em nenhum outro lugar.
Fase 4: o briefing
# Briefing de pesquisa: <título de trabalho>
Consulta de pesquisa: <consulta>
Gênero: guia | roundup | comparação | pilar
Pergunta definidora: ## O que é <coisa>? (confirmada única)
Pilar: <slug> | nenhum (este é um pilar)
## Fatos da Prequel usados
<itens, cada um nomeando o arquivo de onde veio>
## Não escreva
<qualquer ponto onde um rival supera a Prequel, para que o escritor evite o assunto>
## Ferramentas
### <ferramenta>
Preço: <cada nível e período de faturamento>. Verificado <data>. <URL do fornecedor>
Fatos: <resolução, fps, marca d'água, limite de duração, local ou upload, licença>
Prequel vence em: <o contraste que esta seção deve carregar>
Reclamações: <título da thread> (r/<sub>) <URL> <- em quotes.json? sim/não
## Fatos do macOS
<itens, cada um com a URL da Apple e a data>
## Números
<estatística> <URL da fonte primária> <data de publicação>
## Posts existentes para linkar
/blog/<slug> "<texto âncora>" (por que se encaixa)
## Contradições
<qualquer coisa que um post existente diz com a qual este discordaria>
## Candidatos a FAQ
<pergunta como alguém digita em uma caixa de busca> (de: URL da thread ou PAA)
## Abordagens
<três a cinco, das lacunas entre o que as pessoas perguntam e o que existe>
Escreva em .context/research/<slug>.md e termine com a única pergunta que o
escritor precisa respondida: qual habilidade assume em seguida, [[guide-posts]] ou
[[comparison-posts]], e se a lista de abordagens precisa ser aparada primeiro.