Habilidade de Tópico Vago para Esboço de Artigo

Transforme um tópico amplo ou mal formado em um esboço de artigo distinto e pesquisável, sem redigir o artigo para o usuário. Comece pelo trabalho existente e pela base de conhecimento do usuário, identifique perguntas recorrentes em comunidades relevantes, selecione uma pergunta focada do leitor e crie um arcabouço de pesquisa seção por seção.

Quando Usar

Use quando o usuário:

dá um tópico vago e quer ajuda para transformá-lo em um artigo;
pede perguntas de pesquisa, um esboço ou um ponto de vista;
quer escrever manualmente e refinar o trabalho posteriormente com o agente;
pede para conectar um novo tópico a páginas wiki, projetos ou trabalhos de implementação existentes.

Não usar para:

escrever o artigo finalizado imediatamente;
brainstorming genérico sem pesquisa ou trabalho com fontes;
editar um rascunho existente onde a tese e a estrutura já estão claras.

Modelo Mental Central

Use esta sequência:

Tópico vago
  ↓
Trabalho e conhecimento existentes
  ↓
Perguntas externas recorrentes
  ↓
Problema focado do leitor
  ↓
Tese distintiva
  ↓
Mecanismo ou objeto de design concreto
  ↓
Afirmações das seções e perguntas de pesquisa
  ↓
Contra-argumentos e lacunas de evidência
  ↓
Esboço reutilizável no workspace solicitado

O objetivo não é prever o futuro ou resumir um campo. O objetivo é encontrar a interseção mais forte entre:

o que o usuário realmente construiu, observou ou pensou;
o que um leitor técnico específico precisa entender ou decidir;
o que os profissionais atuais estão debatendo ativamente;
o que pode ser apoiado por fontes primárias e exemplos concretos.

Use a sequência de esboço de [[outlining-an-article|Esboçando um Artigo]]:

tópico → despejo cerebral → agrupar → moldar → uma frase por seção → rascunho

Para um artigo técnico do Substack, adicione a camada de pesquisa antes de rascunhar:

tópico → trabalho existente → perguntas recorrentes → ângulo focado
→ despejo cerebral → agrupar → formato da história → afirmações das seções → pesquisa → rascunho

Procedimento

1. Defina a restrição de escrita

Antes de pesquisar, estabeleça:

leitor pretendido;
tipo de artigo: ensaio técnico, guia de campo, nota de arquitetura, argumento contrário ou estudo de caso;
se o usuário quer um esboço ou prosa finalizada;
onde o esboço deve ser salvo;
o contexto de projeto, implementação ou wiki do usuário.

Padrão: público técnico, pesquisa e redação manuais, apenas esboço e depois refinamento.

Verificação de conclusão: escreva uma frase descrevendo o leitor e o trabalho do artigo.

2. Inspecione primeiro o trabalho existente do usuário

Leia os arquivos referenciados completamente o suficiente para identificar:

teses explícitas;
jornadas ou exemplos concretos;
limites de arquitetura;
casos de falha;
critérios de avaliação;
trade-offs;
perguntas não resolvidas;
linguagem que o usuário já usa.

Se o usuário referenciar uma wiki ou pasta, pesquise conceitos sobrepostos antes de inventar um novo enquadramento. Leia as páginas de conceito, fonte, tema, nota e projeto mais relevantes.

Prefira ideias fundamentadas no trabalho do próprio usuário. Uma implementação concreta, uma avaliação falha, uma decisão de design ou um trade-off não resolvido geralmente é mais valioso do que uma afirmação genérica de tendência.

Verificação de conclusão: liste 3 a 8 princípios reutilizáveis do material do usuário.

3. Pesquise perguntas recorrentes de profissionais

Use pesquisa na web para discussões atuais em comunidades de engenharia e fontes técnicas primárias. Pesquise em várias superfícies quando apropriado:

repositórios de protocolo e issues/discussões do GitHub;
exemplos de implementação oficiais;
blogs e documentação de engenharia;
Reddit ou outras comunidades de profissionais;
fóruns técnicos ou material de conferências.

Pesquise por perguntas, não apenas nomes de tópicos. Exemplos:

[tópico] autoridade issue GitHub
[tópico] problema de implementação
[tópico] discussão de engenharia falha
[tópico] limitações de protocolo
[tópico] lições de produção

Registre perguntas recorrentes sob categorias como:

identidade e autoridade;
estado e transações;
interoperabilidade;
dados e limites de contexto;
segurança e abuso;
avaliação e observabilidade;
produto e modelo operacional.

Não afirme popularidade estatística a menos que um conjunto de dados sistemático a suporte. Use redação como "perguntas recorrentes nas discussões amostradas" quando a pesquisa for qualitativa.

Verificação de conclusão: produza de 10 a 25 perguntas recorrentes agrupadas por tema, com fontes representativas.

4. Selecione a melhor pergunta do artigo

Pontue as perguntas candidatas em relação a:

Teste	Pergunta
Valor para o leitor	Ajuda um leitor específico a tomar uma decisão de design ou produto?
Autoridade do usuário	O usuário tem trabalho de primeira mão ou uma visão desenvolvida aqui?
Evidência	A afirmação pode ser apoiada por fontes primárias e exemplos?
Especificidade	É mais restrito que o tópico geral?
Originalidade	Cria um ponto de vista em vez de uma pesquisa geral?
Durabilidade	Permanecerá útil após o hype atual passar?
Potencial de série	Pode levar a artigos de acompanhamento?

Selecione uma pergunta principal e, no máximo, duas alternativas. Explique por que a vencedora é mais forte.

Formato de boa pergunta:

Como [construtor específico] deve projetar [sistema específico] quando [nova condição]?

Evite:

Como [grande tecnologia] mudará [setor inteiro]?

Verificação de conclusão: declare a pergunta do leitor selecionada e por que ela vence.

5. Derive a tese do trabalho do usuário

Use este modelo:

A visão comum é:
O trabalho do usuário sugere:
Essa visão está incompleta porque:
O modelo mais útil é:
A consequência prática para os construtores é:
A objeção mais forte é:

A tese deve ser uma afirmação argumentável, não um rótulo de tópico.

Exemplos de transformações úteis:

"Comércio eletrônico agentivo" → "O agente mercante é um sistema de resolução de resultados limitado, não um chatbot."
"Agentes empresariais" → "A unidade governada é o sistema de ação, não o modelo."
"Memória de agente" → "Memória é uma superfície de controle na camada de aplicação, não apenas um recurso do modelo."

Verificação de conclusão: escreva uma tese de uma frase e uma explicação de 30 segundos.

6. Nomeie ou defina um mecanismo concreto

Dê ao artigo um objeto de design que torne a tese útil. Exemplos:

contrato de jornada;
limite de autoridade;
arnês de avaliação;
orçamento de contexto;
superfície de capacidade;
rastro de decisão;
livro de resultados;
laço de intervenção.

Não invente jargão meramente para parecer original. Pesquise se o termo já existe, identifique terminologia adjacente e rotule-o como termo de trabalho, se necessário.

Verificação de conclusão: defina o mecanismo em 1 a 3 frases e mostre um pequeno exemplo.

7. Molde o artigo como uma história

Não crie um catálogo de tópicos. Dê ao leitor um motivo para continuar de uma seção para a próxima.

Use este fluxo de história padrão:

Problema ou cenário de abertura — mostre uma situação concreta antes de explicar o tópico.
Tensão — revele por que a solução óbvia falha ou é incompleta.
Tese — declare a afirmação principal claramente.
Mecanismo — introduza o modelo, arquitetura ou objeto de design que explica o problema.
Aplicação — percorra como o mecanismo muda a prática.
Salvaguardas ou trade-offs — mostre o que pode dar errado e onde os limites pertencem.
Evidência e avaliação — explique como um construtor saberia que a abordagem funciona.
Implicação — mostre o que muda para o trabalho ou setor do leitor.
Final aberto — termine com uma pergunta ou tensão não resolvida, não um resumo.

Para cada seção, escreva uma frase antes de escrever parágrafos:

Seção:
Afirmação que esta seção faz:
Exemplo ou evidência:
Pergunta que o leitor agora tem:
Como a próxima seção a responde:

A próxima seção geralmente deve responder a uma pergunta criada pela seção anterior. Remova seções que não avançam a história.

Verificação de conclusão: o esboço pode ser lido de cima para baixo como uma cadeia de perguntas e respostas, não apenas uma lista de temas.

8. Despejo cerebral, agrupamento e redução

Antes de finalizar o esboço:

Despejo cerebral de toda ideia, exemplo, fonte, objeção e observação pessoal relevantes.
Pesquise material existente na wiki, notas, destaques e arquivos de projeto.
Agrupe ideias relacionadas e remova material que não suporta o ângulo selecionado.
Escolha um formato do fluxo de história acima ou outra estrutura apropriada.
Escreva uma frase por seção e verifique as transições.
Mantenha ideias não resolvidas em uma lista estacionada em vez de forçá-las no artigo.

Não vá diretamente do tópico para a prosa. O esboço é a ponte entre o pensamento bruto e o rascunho.

Verificação de conclusão: toda ideia retida pertence a uma seção, e cada seção tem uma afirmação principal.

9. Adicione perguntas de pesquisa e lacunas de evidência

Para cada seção retida, forneça:

perguntas de pesquisa que o usuário deve responder;
evidência a ser encontrada;
contra-argumento provável;
o que mudaria a tese;
um exemplo concreto, diagrama ou caso.

Não escreva perguntas que são meramente interessantes. Cada pergunta deve ajudar a estabelecer, desafiar ou qualificar a afirmação da seção.

Verificação de conclusão: cada seção tem de 2 a 5 perguntas de pesquisa respondíveis e pelo menos um alvo de evidência.

10. Adicione contra-argumentos e lacunas de evidência

Não produza uma narrativa de tendência unilateral. Adicione de 4 a 8 objeções sérias. Para cada uma, crie:

Afirmação:
Evidência a favor:
Evidência contra:
O que mudaria minha opinião:
Implicação para a tese:

Rotule afirmações como fato, previsão, interpretação ou opinião. Identifique quais afirmações precisam de evidência primária antes da publicação.

Verificação de conclusão: liste a afirmação não suportada mais fraca do artigo e a fonte necessária para testá-la.

11. Crie o artefato do esboço

Se o usuário pedir um arquivo, crie-o no local solicitado. Para rascunhos do Substack, use:

substack/drafts/<título-descritivo>.md

Use frontmatter:

---
type: substack-draft
created: YYYY-MM-DD
updated: YYYY-MM-DD
status: outline
working_title: "..."
---

O arquivo deve conter a tese de trabalho, leitor, pergunta selecionada, disciplina de pesquisa, esboço de seção, perguntas, contra-argumentos e lista de fontes. Não escreva prosa de artigo finalizada, a menos que explicitamente solicitado.

Não atualize wiki/index.md ou wiki/log.md para um rascunho do Substack, a menos que o usuário peça explicitamente. Não modifique raw/.

Verificação de conclusão: o arquivo existe, contém o esboço completo e diz claramente ao usuário o que pesquisar em seguida.

12. Relate o resultado

Dê um breve relatório contendo:

o enquadramento selecionado;
por que foi selecionado;
a sobreposição mais forte com o trabalho existente do usuário;
onde o esboço foi salvo;
o que o usuário deve pesquisar e escrever em seguida;
qualquer limitação na pesquisa, especialmente se "mais comum" foi inferido de uma amostra qualitativa.

Disciplina de Pesquisa e Fontes

Use documentação técnica primária para alegações de protocolo e implementação.
Use discussões da comunidade para descobrir perguntas e modos de falha, não como evidência inquestionável de comportamento em todo o mercado.
Separe capacidade de protocolo, comportamento de implementação, confiança do usuário e adoção de mercado.
Prefira exemplos concretos, rastros, casos de avaliação e relatórios de falha a previsões genéricas.
Cite alegações factuais derivadas da internet na resposta final quando a pesquisa na web foi usada.
Não apresente resultados de pesquisa qualitativa como estatisticamente representativos.

Modos de Falha Comuns

Começar pelo tópico da indústria em vez da evidência mais forte do usuário.
Produzir um resumo de protocolo sem um argumento.
Tratar um agente como a unidade de análise quando a unidade real é uma jornada, fluxo de trabalho ou sistema de ação.
Escrever o artigo antes de definir a pergunta do leitor.
Confundir uma capacidade de modelo com uma garantia de produção.
Tratar uma API ou protocolo como prova de interoperabilidade segura.
Fazer perguntas de pesquisa que não podem mudar a conclusão do artigo.
Esconder incerteza por trás de frases como "o mercado está se movendo em direção a".
Criar terminologia impressionante sem verificar a literatura adjacente.
Rascunhar prosa polida quando o usuário pediu para pesquisar e escrever manualmente.

Lista de Verificação

Antes de finalizar:

aman-sharma-nine/agent-skills

O que é agent-skills?

Perguntar na sua IA favorita

Documentação