Criar Post de Blog

Transforme código da sessão atual em um post de blog que pareça ter sido escrito pelo autor: um guia passo a passo de uma função, script, classe ou ferramenta, construído em torno de um exemplo generalizado e um exemplo de uso.

Esta habilidade é executada apenas quando o usuário solicita um post. O momento natural é o final de um turno, quando o código funciona: /make-blog-post, opcionalmente seguido pelo que cobrir, onde o post vai e links ou arquivos de posts anteriores do autor.

Quando Usar Esta Habilidade

• O usuário pede para escrever, rascunhar ou transformar código em um post de blog, artigo, tutorial, guia ou gist.
• O usuário invoca /make-blog-post, com ou sem nomear o assunto, o destino ou amostras de escrita.

Não o use para referência de API, READMEs, changelogs ou notas de lançamento, ou para um post que precise de vários exemplos não relacionados ou um guia com vários arquivos.

Exemplos

/make-blog-post
/make-blog-post the retry helper in src/http.ts
/make-blog-post the slugify function, as a gist
/make-blog-post put it in the blog, match https://example.com/posts/one and https://example.com/posts/two

Fluxo de Trabalho

Trabalhe nas etapas em ordem. Nada é gravado em disco até que o rascunho seja aprovado na etapa 5.

1. Escolher o assunto

• Use o que o usuário nomeou: uma função, arquivo, seleção, trecho ou tópico. Código colado na conversa também está no escopo.
• Caso contrário, pegue o código escrito ou alterado nesta sessão. Quando mais de uma peça se qualifica, liste até três, cada uma com um propósito de uma linha, e pergunte qual delas escrever.
• Verifique se o assunto funciona como um post autônomo. Ele deve:
  • Resolver um problema claro e de propósito geral.
  • Caber em um exemplo autocontido.
  • Não depender de estado, serviços ou configuração específicos do projeto que não possam ser substituídos por um substituto.
  • Não ser trivial. Um wrapper de uma linha ou uma chamada isolada da biblioteca padrão não se qualifica.
• Quando uma verificação falha, diga qual e sugira um ângulo que funcione, como a técnica por trás do código. Prossiga com o assunto original se o usuário ainda o desejar.

2. Resolver o destino

Considere apenas o que o usuário disse, o espaço de trabalho atual e os caminhos que o usuário fornece. Não presuma que nenhuma pasta existe e não percorra diretórios pais ou irmãos procurando por uma.

1. O usuário nomeou um destino (um caminho local, o repositório do espaço de trabalho atual, um local como um gist ou "apenas me mostre"): use-o e não mova o post para outro lugar porque outro local se encaixa melhor nas convenções. Se o usuário nomear outro repositório, peça o caminho de checkout local dele; não o clone nem o modifique remotamente. Um nome parcial como "o blog" se resolve apenas contra o espaço de trabalho atual. Se o espaço de trabalho não for esse blog, peça o caminho.
2. O espaço de trabalho é um blog ou site: pegue a pasta de posts da configuração do próprio gerador e combine a pasta, extensão, nome do arquivo e front matter de um post existente. Veja references/blog-platforms.md para detecção e o contrato de cada gerador.
3. Caso contrário: não escreva nenhum arquivo. Entregue o post no chat e ofereça-se para salvá-lo em um caminho que o usuário nomear.

Um destino padrão ou perfil de voz gravado nas instruções personalizadas do usuário conta como nomeado pelo usuário. Esse é o lugar para um fluxo de trabalho pessoal, como uma pasta onde todos os posts são arquivados.

Ao escrever para um caminho nomeado:

• Crie subpastas ausentes sob uma raiz que exista. Se a própria raiz não existir, peça em vez de construir uma árvore que pode ser um erro de digitação.
• Se o caminho quebrar o contrato do gerador detectado (a pasta errada para a coleção, um prefixo de data ausente), declare em uma linha o que quebraria, ofereça o caminho compatível e pergunte qual usar.
• Se a solicitação entrar em conflito com as convenções do site, diga isso uma vez e, em seguida, siga a solicitação. As regras de segurança e o portão de aprovação ainda se aplicam.

3. Aprender a voz do autor

Um post que soa como documentação genérica não é o post do autor. Antes de rascunhar, colete de três a cinco amostras da própria escrita do autor, destas fontes em ordem:

1. Amostras nomeadas na solicitação: arquivos, pastas, URLs ou texto colado.
2. Um perfil de voz salvo que o usuário aponta, na solicitação ou em suas instruções personalizadas.
3. Quando a etapa 2 resolveu um repositório de blog, os posts mais recentes deste autor em sua pasta de posts.

…