mrgnhnt96/beedle

O que beedle faz?

Construa páginas de marketing que mecanismos de busca e rastreadores de IA possam ler, que um estranho entenda em dez segundos, e que reivindiquem apenas o que pode ser comprovado. Menos é mais: cada seção precisa merecer seu lugar. Cada rodada termina com uma revisão independente.

Lições: antes do passo 1, leia o design/LESSONS.md do projeto se ele tiver um e siga tudo sobre seu site de marketing. Essas são as correções do proprietário.

1. Leia o projeto

Descubra o que já existe antes de perguntar qualquer coisa: a stack e o host, qualquer site atual, o nome real do produto, repositório, listagens em lojas, preços, capturas de tela, tokens de design ou tema, analytics, e docs/marketing/page-brief.md.

Construa na stack que o projeto já usa. Para um novo site, siga reference/seo.md ("Escolhendo uma stack"). Conteúdo de marketing nunca é Flutter web ou renderizado no cliente, porque os rastreadores podem nunca vê-lo.

Use o tema do projeto se ele tiver um (design/THEME.md, *.tokens.json). Se não tiver, porte os tokens do aplicativo. Se também não houver aplicativo para portar, escreva o único arquivo pequeno em reference/small-theme.md, porque uma página não precisa de um sistema de design. Recorra à habilidade ultrahand:theme apenas quando o usuário pedir um tema, ou quando vários sites ou um aplicativo precisarem compartilhá-lo.

2. Escolha o tipo e o estado de lançamento

Leia reference/page-types.md. Escolha um tipo e um estado (pré-lançamento ou ativo), e anote as páginas de suporte que o site precisa.

3. Escreva o brief

Salve docs/marketing/page-brief.md no projeto, usando este modelo. É o contrato que o revisor verifica em relação à página, e o ponto de partida da próxima sessão.

# Brief da página

- Tipo e estado:
- Público-alvo: (quem, e o que já sabem)
- O único trabalho da página:
- CTA principal: (palavras exatas e destino)
- Ação secundária: (uma, mais leve, ou "nenhuma")
- Frases de busca: (3-5 coisas que este público realmente digita)
- Objeções: (as razões reais pelas quais alguém iria embora)
- Analytics e cookies: (o que carrega, ou "nenhum")

## Afirmações

| Afirmação na página | Evidência |
| --- | --- |
| <cada número, citação, comparação, "primeiro", "mais rápido", ...> | <arquivo, link ou medição, com data> |
| <uma descrição simples do que é ou faz> | <arquivo ou link, ou `README only` se for só isso> |

## Aguardando uma pessoa

- <quem: o que devem fazer, ou "nada">

Pergunte ao usuário apenas o que o projeto não pode responder, geralmente o público-alvo e a prova. Nunca invente provas. Um depoimento faltando é uma seção faltando, não um espaço reservado para preencher. Use sentinels que falham ruidosamente, como APP_STORE_ID_TODO, em vez de valores falsos plausíveis.

Quando o README é tudo que você tem, você ainda pode construir a página. Ela pode dizer claramente o que o produto é e faz: marque essas linhas como README only. Não pode provar números, datas, versões, licença, preço, segurança, privacidade ou disponibilidade; então procure uma fonte primária para cada um: o código, um arquivo LICENSE, uma página de lançamento, uma listagem de registro ou loja, uma medição, ou a palavra datada do proprietário. Cite essa fonte. Se não houver uma, deixe a afirmação de fora da página.

Qualquer coisa que apenas uma pessoa pode fornecer vai para Aguardando uma pessoa assim que você souber dela: uma captura de tela real, um domínio, um preço a confirmar. Fica lá até que eles tenham feito.

4. Escreva as palavras primeiro

Siga reference/message.md. Escreva o texto antes de qualquer layout. Comece a partir dos cinco blocos ali. Adicione uma seção apenas quando puder nomear a objeção que ela responde, e registre essa objeção no brief.

5. Construa

Siga reference/seo.md para o que vai na página e ao lado dela. Use capturas de tela reais do produto ou filmagens, e nunca rotule uma recriação como captura de tela. Uma captura do aplicativo real executando dados de exemplo é real: diga que é um exemplo na página, e diga como você a fez na tabela de afirmações. Sem nada real para mostrar, deixe a imagem de fora, ou deixe um sentinel se o tipo de página precisar de uma. Evite os indicadores de design listados na referência de mensagem, pois eles fazem uma página parecer gerada antes de qualquer um a ler.

6. Autoverificação

Construa o site e execute a auditoria na saída construída, depois corrija todos os erros que puder:

beedle audit --dir <site construído>

Adicione --exclude docs para cada seção que não é marketing (repetível). Se beedle não estiver no PATH, diga ao usuário que a auditoria não foi executada e que INSTALL.md diz como adicioná-lo.

Um erro que apenas uma pessoa pode resolver permanece, como um sentinel DOMAIN_TODO para um domínio que ninguém comprou. Nunca troque por um valor falso para obter uma execução limpa. Certifique-se de que esteja em Aguardando uma pessoa, então prossiga para a revisão.

7. Revise a rodada

Cada rodada termina com uma revisão por um revisor novo em sua própria sessão, antes de você dizer ao usuário que a página está pronta. Uma rodada é a primeira construção e cada prompt posterior que altera a página, portanto uma alteração de uma linha no texto também é revisada. Pule apenas quando o usuário disser para pular nesta rodada, e diga que você pulou.

Inicie você mesmo, sem ser solicitado. Você não pode revisar sua própria página de forma justa: você vê o que pretendia construir. Siga review/round.md. Resumindo, escreva o brief, execute beedle review --brief <brief> --add-dir <projeto> em segundo plano, depois aja com base nas descobertas. Não publique, implante ou considere a página pronta antes disso.

8. Relate

Diga o que você construiu, o tipo e estado, o veredito, e o que a revisão encontrou, corrigiu e deixou em aberto, com seu custo.

Se o veredito for Não pode ser enviado até que uma pessoa aja, comece com isso: a página não está pronta, quem deve fazer o quê, e o que a próxima rodada verificará quando eles tiverem feito. Nunca suavize para "quase pronto".

Sempre liste o que resta para o proprietário após o lançamento: verificação do Search Console e do Bing Webmaster, e o Teste de Resultados Rich na página implantada.

Não implante a menos que o usuário peça.

9. Aprenda

Quando o proprietário corrigir o resultado ou declarar uma preferência duradoura, adicione uma linha ao design/LESSONS.md do projeto (crie-o se necessário). Se a correção mostrar que estas regras estão erradas para todos os projetos, corrija a regra aqui também.