Beautiful Article
Background and Principles
Quanto mais complexo o conteúdo gerado por IA, mais importante é o meio de saída. O valor do HTML está em aumentar simultaneamente a densidade da informação, clareza visual, facilidade de compartilhamento e capacidade interativa: tabelas, SVG, CSS, trechos de código, controles ajustáveis, botões de copiar e exportar permitem que o leitor não apenas "leia", mas também compare, localize, ajuste, revise e continue usando. O objetivo do Beautiful Article é transformar materiais de texto chatos, lineares e difíceis de digerir em artigos de página única com uma experiência visual mais bonita, um ritmo de leitura mais claro e que também são mais fáceis de revisar e compartilhar.
Limites (Primeiro, Decida se Deve Entrar nesta Skill)
- O produto final principal é um único artigo HTML, não uma aplicação web.
- O artigo pode ter uma camada
Rawlivre (qualquer HTML/CSS/JS/React: interação, layout, animação, pequenos widgets, diagramas SVG/canvas sob demanda), mas deve servir à leitura, explicação, argumentação, ritmo ou estética. - Não gera: painéis de administração, formulários, áreas de trabalho de arrastar e soltar, dashboards completos, protótipos de produtos ou aplicações web genéricas.
- A densidade da informação é confirmada pelo usuário; por padrão, mantém 100% da informação, gerando artigos web extensos.
Se o usuário quer uma aplicação em vez de um artigo, pare e esclareça, não entre nesta Skill.
Visão Geral do Fluxo de Trabalho
Fase 0 Intake Decida se entra nesta Skill + tipo de artigo preliminar
▼
Fase 1 Source → Markdown URL/PDF/DOCX/MD/Texto → source.md + extraction-notes.md
└ Agente principal verifica internamente uma lista de 5 itens (somente fontes complexas/de baixa confiança sobem para SubAgente)
▼
Fase 2 Editorial Planning Um plan.md (Brief / Outline / Theme / Assets - quatro seções)
└ Agente principal verifica internamente (sem SubAgente, sem arquivos de revisão)
▼
Fase 3 Plan Checkpoint ★Checkpoint 1 deve parar. Confirme 5 itens um por um: Tipo de artigo (com % de retenção padrão) / Tema / Layout / Modo de imagem / Capa
▼
Fase 4 First Spread Primeira tela + primeira seção + um bloco visual representativo (andaime criado aqui)
└ SubAgente Revisor do First Spread (escreve review/first-spread-review.md)
└ ★Checkpoint 2 deve parar. Confirme 2 itens um por um: Conclusão da revisão / Modo de desenvolvimento A ou B
▼
Fase 5 Full Article Build Gere o artigo web completo (padrão: Agente único; para muito longo, pode isolar por Seção)
└ SubAgente Revisor de Seção (retorna pass/fail em mensagem, sem escrever arquivo de revisão)
▼
Fase 6 Final Review Revisão final sob três perspectivas: Editorial / Visual / Técnica (escreve review/final-review.md)
▼
Fase 7 Repair Reparo em fatias mínimas; só escreve repair-log.md se houver reparo
▼
Fase 8 Delivery ★Checkpoint 3 deve parar. Confirme a decisão de entrega um por um → Entregue article.html + breve nota editorial
Estrutura do Workspace (criada pelo andaime; estes arquivos são a memória de longo prazo da Skill, não confie apenas no contexto do chat para lembrar decisões):
<workspace>/
source/ original.* source.md source.<lang>.md (se precisar traduzir) extraction-notes.md
plan/ plan.md # Arquivo de planejamento único: quatro seções Brief / Outline / Theme / Assets
article/ Cover.tsx(padrão) Article.tsx sections/ raw-blocks/ assets/ article.html (produto)
review/ first-spread-review.md final-review.md # Apenas estes dois são produtos regulares
source-review.md (somente para fontes complexas) repair-log.md (somente se houver reparo)
index.html package.json vite.config.ts tsconfig*.json (Ferramentas de construção)
Protocolo de Qualidade Rígido (Presente em Toda a Skill)
O método de verificação de qualidade varia conforme o nó – nem toda verificação precisa de um SubAgente, nem toda verificação precisa de um arquivo. Abrir SubAgente ou escrever arquivos desnecessariamente é o principal problema de desempenho. Siga estritamente a tabela abaixo:
| Nó | Método de Verificação | Produto | Por quê? |
|---|---|---|---|
| Fase 1 Source (padrão) | Agente principal verifica internamente lista de 5 itens | Nenhum arquivo | Agente principal vai ler source.md de qualquer forma |
| Fase 1 Source (somente fontes complexas/baixa confiança) | SubAgente Revisor de Fonte (compara diff com original.*) | review/source-review.md | Perda silenciosa só é detectada por diff |
| Fase 2 Plan / Antes do Checkpoint 1 | Agente principal verifica internamente (proibido abrir SubAgente) | Nenhum arquivo | Plan é decisão textual com 200-400 linhas, contexto ainda está quente; SubAgente iniciar frio é mais lento |
| Fase 4 First Spread / Antes do Checkpoint 2 | SubAgente Revisor do First Spread | review/first-spread-review.md | Primeira tela define o tom; um par de olhos independente é mais estável |
| Fase 5 Cada Seção | SubAgente Revisor de Seção | Retorna pass/fail + pontos de reparo em mensagem (não escreve arquivo) | Um artigo pode ter 5-15 seções; N arquivos de revisão ninguém relê |
| Fase 6 Revisão Final / Antes do Checkpoint 3 | SubAgente Revisor Editorial + Visual + Técnico | review/final-review.md | Parte do entregável; vale a pena arquivar |
Regras de Ferro:
- Checkpoint do Plano (Fase 2 → Checkpoint 1) é estritamente proibido abrir SubAgente para verificação de qualidade. Após escrever
plan.md, o Agente principal localmente verifica a lista de 5 itens (veja a seção de autoverificação do Plano emreferences/review-checklist.md), modificaplan/plan.mdconforme a conclusão, não escreva nenhum arquivo de revisão, e então entre no Checkpoint 1. - First Spread / Final devem usar SubAgente (o valor do SubAgente nesses dois nós supera o custo); somente se o ambiente do SubAgente não for detectado é que o Agente principal assume, e deve anotar "Ambiente sem SubAgente, Agente principal assumindo" no início do arquivo.
- Revisor de Seção usa SubAgente, mas o valor de retorno é uma mensagem (pass / fail + pontos de reparo); ao receber fail, o Agente principal corrige diretamente, não peça ao SubAgente para escrever arquivos
review/section-NN-review.md. - Ao obter qualquer resultado de verificação de qualidade – primeiro corrija a saída conforme os itens de fail, depois reporte "pronto + conclusão da autoverificação + o que foi alterado". Relatar a conclusão bruta sem corrigir = violação.
- Regra de Ferro para Coleta de Decisões · Proibido escolher silenciosamente pelo usuário: Em cada Checkpoint (1 / 2 / 3), todos os itens de decisão que precisam de confirmação do usuário devem ser listados individualmente + aguardar resposta do usuário. O Agente pode recomendar ("Eu recomendo X, porque …"), mas não pode dizer "já defini X para você; me diga se não estiver certo" – isso equivale a roubar a oportunidade de escolha.
- Prioritário: Se o ambiente tiver a ferramenta
AskQuestion, cada item de decisão como uma pergunta independente (uma chamada pode passar várias perguntas), permitindo que o usuário confirme item por item usando cartões de seleção. - Caso contrário: Pare e liste todas as perguntas numeradas na mensagem (cada pergunta em um parágrafo próprio, escreva claramente o item recomendado + motivo + alternativas), diga explicitamente "Estou aguardando suas respostas uma a uma para continuar", não faça nenhum trabalho subsequente.
- Nunca: Empacote várias decisões em uma única pergunta "Tudo OK com minha recomendação?" sim/não; nem siga para o próximo passo por padrão após "uma frase de recomendação".
- Prioritário: Se o ambiente tiver a ferramenta
As listas de verificação e modelos de prompt do SubAgente para cada nó estão em references/review-checklist.md.
Guia de Leitura de Arquivos por Fase (Carregamento Progressivo, Não Leia Tudo de Uma Vez)
| Fase | Leitura Obrigatória | Consulta sob Demanda |
|---|---|---|
| Fase 0 Intake | references/harness.md | —— |
| Fase 1 Source→MD | references/source-to-markdown.md | scripts/source-to-markdown-markitdown.py · scripts/source-to-markdown.py |
| Fase 2 Planning | references/article-types.md · references/information-density.md · references/plan-template.md · references/theme-selection.md · references/layout.md · references/asset-policy.md · references/cover.md (ideias de composição de capa) | references/article-types/<type>.md · theme-profiles/*.md |
| Fase 4 First Spread / Fase 5 Build (revisitar a cada seção) | references/section-build.md · references/component-policy.md · references/raw-policy.md · Tema selecionado theme-profiles/<id>.md · Capa: references/cover.md | references/scaffold.md (uma vez ao criar o projeto) · references/html-output.md |
| Fase 6/7 Review & Repair | references/review-checklist.md · references/repair-policy.md | —— |
| Fase 8 Delivery | references/html-output.md | references/pdf-output.md (apenas se o usuário escolher exportação PDF) |
Em sessões longas, o agente tende a esquecer princípios – A Fase 5 repetirá a implementação de N Seções. Antes de cada início, releia
component-policy.md+raw-policy.md+ o tema atualtheme-profiles/<id>.md.
Fase 0 – Intake
Decida se entra nesta Skill, forneça o tipo de artigo preliminar e o modo de saída (padrão: HTML único).
| O que o usuário fornece | O que fazer |
|---|---|
| Um ou mais materiais (URL/PDF/DOCX/MD/texto/captura de tela) | Entre na Fase 1 |
| Apenas diz "Me ajude a fazer um artigo X" sem material | Pergunte de volta: Peça o material ou um esboço. A Skill não inventa conteúdo do nada para o usuário |
| Claramente quer uma aplicação / ferramenta / dashboard | Pare e esclareça, não entre nesta Skill |
Capturar idioma alvo: Registre desde o início o idioma do artigo final desejado pelo usuário (por exemplo, se o usuário mencionar "em português" / "faça em inglês", etc.).
- Usuário especificou o idioma → Anote na seção Brief de
plan/plan.mdcomo "Idioma alvo". Se o idioma for diferente do idioma do material de origem, a Fase 1 precisa primeiro produzir uma tradução idiomática do texto fonte, e o trabalho subsequente será baseado nessa tradução (veja Fase 1). - Usuário não especificou → Por padrão, o idioma do artigo final segue o idioma do material de origem, sem tradução.
Autoverificação: O usuário quer um artigo ou uma aplicação web? Precisa de informação completa? Precisa pedir mais material primeiro? O usuário especificou o idioma final? É o mesmo do idioma de origem?
Fase 1 – Source → Markdown
Unifique qualquer entrada em source/source.md. Escreva incertezas em source/extraction-notes.md. Regras e processamento de vários tipos de entrada estão em references/source-to-markdown.md; você pode usar o caminho principal MarkItDown ou scripts fallback leves para extração de PDF/DOCX/HTML.
Após o salvamento, o Agente principal faz uma autoverificação interna (a lista de 5 itens em references/source-to-markdown.md), corrige conforme a conclusão e então entra na Fase 2; somente quando extraction-notes.md marcar baixa confiança/fonte complexa, ele sobe para um SubAgente Revisor de Fonte independente que faz uma verificação estilo diff contra original.* (escrevendo review/source-review.md).
Processamento de Idioma (logo após a extração): Determine o idioma de source.md.
- Usuário não especificou o idioma alvo, ou o idioma alvo é o mesmo da fonte → Não traduza; o trabalho subsequente é baseado diretamente em
source.md; o idioma do artigo final = idioma da fonte. - Usuário especificou o idioma alvo e é diferente da fonte → Primeiro produza uma tradução idiomática
source/source.<lang>.md(por exemplo,source.zh.md/source.en.md), como a base factual para a Fase 2+ subsequente; o texto originalsource.mdé mantido para referência. Requisitos de tradução: Use o idioma alvo de forma idiomática, remova o tom de tradução (reorganize as frases conforme os hábitos de expressão do idioma alvo, não traduza palavra por palavra, não deixe ordem de palavras estrangeira rígida / empilhamento passivo / pontuação estrangeira), mantenha a precisão de termos/números/códigos/fórmulas/citações, mantenha a estrutura e a proporção de informação inalteradas. Escreva as notas de tradução emextraction-notes.md.
Fase 2 – Editorial Planning
Forme um plano editorial; não escreva HTML diretamente. Produza apenas um plan/plan.md (quatro seções: Brief / Outline / Theme / Assets). O modelo está em references/plan-template.md:
- Brief: Público-alvo / Tipo de artigo / Proporção de retenção de informação / Deve reter / Pode cortar / Tom / Ideia principal / Objetivo de leitura / Idioma alvo / Largura do layout / TOC / Estratégia de imagens.
- Outline: Hero / Lead / Summary / Lista de Seções / Quais informações reter em cada seção / Cada seção precisa de Raw·Table·CodeBlock·Formula·Image / Modo de conclusão.
- Theme: Tema selecionado + motivo + explicação de conflitos (veja
references/theme-selection.md). - Assets: Estratégia de imagens e plano imagem por imagem (veja
references/asset-policy.md; no modonone, esta seção pode ter apenas uma frase).
O roteamento do tipo de artigo está em references/article-types.md; densidade de informação e proporção de componentes estão em references/information-density.md.
Método de Autoverificação · Restrição Forte: Após escrever plan/plan.md, o Agente principal internamente verifica contra a lista de 5 itens de autoverificação do Plano (veja a seção de autoverificação do Plano em references/review-checklist.md), modifica plan/plan.md conforme a conclusão, e então entra diretamente no Checkpoint 1. É proibido abrir SubAgente. É proibido escrever review/plan-review.md.
Fase 3 – Plan Checkpoint (★Nó Duro · Checkpoint 1, Deve Parar)
Regra de Ferro: Proibido escolher silenciosamente pelo usuário. Cada item de decisão deve ser listado individualmente e aguardar resposta do usuário individualmente.
Pode recomendar ("Eu recomendo X, porque …"), não pode dizer "já defini X para você; me diga se não estiver certo" – o último equivale a passar o valor padrão e roubar a oportunidade de escolha.
Método de Coleta (escolha um conforme o ambiente):
- Prioritário: Use a ferramenta
AskQuestion: Passe cada item como uma pergunta independente (uma chamada pode enviar várias perguntas), o usuário confirma item por item usando cartões de seleção. - Sem ferramenta
AskQuestion: Pare e liste cada pergunta numerada na mensagem + cada uma em um parágrafo próprio + escreva claramente o item recomendado + motivo + alternativas, diga explicitamente "Estou aguardando suas respostas uma a uma para continuar", não faça nenhum trabalho subsequente.
Independentemente do método: Cada decisão independente corresponde a uma pergunta independente. Não empacote como "Tudo OK?" sim/não.
Os 5 itens que devem ser confirmados individualmente (nenhum pode faltar):
| # | Item de Decisão | Opções (Rótulos Semânticos · Inclui % de Retenção de Informação Padrão) | Notas |
|---|---|---|---|
| 1 | Tipo de Artigo (proporção de retenção de informação incluída) | Texto longo completo / Arquivo longform · ~100% / Relatório de pesquisa / Análise formal full-report · ~80% / Passos de tutorial / Guia de início tutorial · ~90% / Conceito / Explicação de sistema explainer · ~80% / Diálogo / Entrevista / Podcast dialogue · ~80% / PR / Plano / Revisão de incidente review · ~70% / Opinião / Comentário / Narrativa essay · ~70% / Aprendizagem interativa / Entender um conceito brincando interactive-explainer · ~25% extrato original + 75% reconstrução IA / Resumo de decisão / Para quem está ocupado briefing · ~50% / Foco em imagem e texto / Divulgação e exibição visual-essay · ~40% | IA recomenda um e escreve uma frase de motivo. A proporção já está vinculada à opção de tipo, não é uma pergunta separada (caso contrário, surgiriam combinações falsas como longform + 20%). Se o usuário quiser desviar do padrão, use uma frase de texto livre para substituir ("Quero longform + 60%"), veja "Como desviar do padrão" abaixo |
| 2 | Tema | tufte / press / outros temas registrados (leia theme-profiles/index.json) | IA recomenda um e escreve uma frase de motivo |
| 3 | Largura do Layout | narrow / regular / wide / full | IA recomenda um; padrão regular |
| 4 | Modo de Imagem (obrigatório · não permitido "aprovação por padrão") | none / user-assets / placeholders / ai-generated | Uma frase: "Apenas decide se usa Image externa; Raw não é afetado" |
| 5 | Capa (imagem de título estilo capa de livro 3:4, acima do TOC + corpo) | Ligada (padrão) / Desligada | IA recomenda "Ligada" e dá uma frase de ideia de composição (qual visual principal + qual modelo de capa A/B/C/D/E). briefing / dialogue pode recomendar "Desligada". Detalhes em references/cover.md |
TOC padrão ligado: Como tem apenas um interruptor + quase todos os artigos devem ter, pode ser mencionado de passagem na mensagem de abertura do Plan Checkpoint como "TOC ligado por padrão; me diga se quiser desligar". Não precisa ser uma pergunta separada.
Itens que já têm valor padrão e não precisam ser perguntados separadamente (ainda assim, devem ser mencionados na mensagem de abertura "se quiser mudar, me avise", dando ao usuário a chance de mudar de ideia, não podem ser completamente escondidos):
- Idioma do artigo final: segue o idioma da fonte (a menos que o usuário já tenha especificado / a tradução já tenha sido concluída anteriormente).
- Se é permitido editar, cortar, reorganizar, alterar o tom: permitido por padrão (executado conforme a proporção de retenção de informação acima).
- Se quer ver uma amostra da primeira tela primeiro: por padrão, será feito primeiro (esta é a Fase 4).
- TOC: ligado por padrão.
Se o usuário disser "Você decide" para o tema → Use sua primeira recomendação, mas ainda a coloque lado a lado com outras candidatas na opção, marcando "Padrão · Recomendado pela IA", deixando espaço para mudar de ideia. Não pode pular a pergunta do tema diretamente.
Como desviar da proporção de retenção de informação "padrão": Cada tipo de artigo vem com uma proporção de retenção recomendada (veja a tabela acima). Na grande maioria dos casos, o padrão é suficiente. Se o usuário quiser refinar (por exemplo, "longform mas com apenas 60%" → um texto longo profundamente editado), peça ao usuário para escrever uma frase no texto livre após a mensagem de abertura "Quero + %" para substituir. Ao receber a substituição, a IA deve anotar no plan/plan.md na seção Brief tanto "tipo / retenção padrão / usuário substituiu para X%" e lembrar o usuário de que esta é uma "combinação não padrão" – essas combinações exigem que o Agente principal ajuste manualmente a proporção texto/visual ao escrever cada seção.
Modelo de Mensagem de Abertura do Plan Checkpoint (envie uma breve explicação antes de coletar as decisões):
plan/plan.md já foi escrito (autoverificação aprovada). Vou confirmar 5 itens com você, um por um: Tipo de artigo / Tema / Largura do layout / Modo de imagem / Capa.
Minhas recomendações estão aqui para referência (não vou escolher por você):
- Tipo: <X> (com retenção padrão de informação <Y%>. Motivo: …)
- Tema: <theme> (Motivo: …)
- Largura do layout: <width> (Motivo: …)
- Modo de imagem: <estratégia> (Motivo: …)
- Capa: Ligada / Desligada (Motivo: …; se Ligada, ideia de composição: …)
Coisas que seguem o padrão, mas você pode mudar: Idioma segue o idioma da fonte; edição, corte e reorganização permitidos; TOC ligado; a seguir farei uma amostra da primeira tela.
Se a proporção de retenção de informação precisar desviar do padrão do tipo, responda abaixo diretamente com a porcentagem específica (por exemplo, "longform mas com apenas 60%").
Vou confirmar cada item abaixo.
Após enviar esta mensagem de abertura, imediatamente use o AskQuestion para enviar 5 perguntas (ou, em um ambiente sem ferramentas, liste 5 perguntas numeradas e pare para aguardar resposta). Somente depois de receber respostas para todos os 5 itens você pode prosseguir para a Fase 4; se o usuário fornecer uma "proporção de retenção não padrão" no texto livre, primeiro confirme que a IA a registrou em plan/plan.md antes de prosseguir para a Fase 4.
Fase 4 – First Spread ("Aprovação do Primeiro Capítulo" da Versão Artigo)
Primeiro, faça "Capa (se ligada) + primeira tela + primeira seção + um bloco visual representativo". O andaime cria o workspace aqui:
# Padrão: capa ligada
bash <caminho-para-beautiful-article>/scripts/scaffold.sh ./meu-artigo --theme=<id>
# Checkpoint 1: usuário escolheu "Capa · Desligada"
bash <caminho-para-beautiful-article>/scripts/scaffold.sh ./meu-artigo --theme=<id> --no-cover
bash <caminho-para-beautiful-article>/scripts/scaffold.sh --list-themes
Ele cria um workspace Vite + React + TS (instala a versão mais recente publicada do reacticle do npm) + diretórios de memória source/ plan/ review/ + assembler article/Article.tsx + um componente de seção de exemplo (+ article/Cover.tsx padrão, a menos que --no-cover). Detalhes em references/scaffold.md.
A primeira tela (Hero / Lead) é escrita no assembler article/Article.tsx; a primeira Seção deve ser escrita como um componente independente article/sections/01-*.tsx (este é o ponto de ancoragem de código para paralelismo posterior, veja references/section-build.md). Capa (se ligada): Substitua <CoverPlaceholder /> em article/Cover.tsx por uma composição gráfica personalizada conforme o tema e o tema principal do artigo. A estrutura externa (container 3:4 + quebra de página para impressão) não deve ser alterada. Diretrizes de design de capa em references/cover.md. Visualize com npm run dev. Isso determina o estilo do título / tamanho da fonte / densidade do conteúdo / estilo Raw / modo de imagem / adequação do tema.
Após a conclusão da primeira Seção, crie um SubAgente Revisor do First Spread conforme o Protocolo de Qualidade Rígido, escreva review/first-spread-review.md (inclui 5 itens de autoverificação da Capa, veja references/cover.md), corrija e então entre no Checkpoint 2.
Checkpoint 2 · First Spread (★Nó Duro, Deve Parar)
Permita que o usuário aprove a primeira tela + a primeira seção, e selecione o modo de desenvolvimento subsequente. As regras de ferro para coleta de decisões do Checkpoint 1 se aplicam aqui: Dois itens confirmados independentemente, proibido empacotar; priorize AskQuestion; se não houver ferramenta, liste numerado e pare para aguardar resposta.
Primeiro, envie uma breve mensagem:
Primeira tela + primeira seção prontas. Use `npm run dev` para visualizar em localhost.
Conclusão da verificação de qualidade em review/first-spread-review.md (já corrigido conforme itens de fail; liste o que foi alterado).
Peço que confirme duas coisas independentemente: 1) Conclusão da revisão 2) Modo de desenvolvimento subsequente.
Em seguida, use o AskQuestion para enviar duas perguntas independentes (ou liste duas perguntas numeradas e pare para aguardar resposta):
- Conclusão da Revisão – Opções:
Aprovado · Ir para geração completa/Modificação local · Vou dizer onde alterar em outra mensagem/Tema ou layout inadequados · Voltar ao Checkpoint 1. - Modo de Desenvolvimento Subsequente – Opções:
A · Agente único sequencial (padrão · mais estável · estilo mais uniforme)/B · Multi-agente paralelo (mais rápido · pequenas diferenças de estilo).
Não empacote essas duas coisas como "Aprovado + A, OK?" – O usuário pode querer "Aprovado na revisão mas quero usar B" ou vice-versa. Depois de receber respostas para ambas as perguntas, prossiga para a Fase 5.
Fase 5 – Full Article Build
Gere o artigo completo conforme o modo de desenvolvimento selecionado no Checkpoint 2. Detalhes em references/section-build.md + references/component-policy.md + references/raw-policy.md.
Regra de Ferro · Cada Seção deve ser um arquivo de componente independente (article/sections/NN-*.tsx). É estritamente proibido escrever várias seções diretamente em um único componente. article/Article.tsx é apenas um assembler: importa e ordena as Seções, de propriedade do Agente principal. Grandes blocos Raw também devem ser isolados em article/raw-blocks/NN-*.tsx. O isolamento em nível de arquivo é um pré-requisito para o paralelismo multi-agente.
Modos de Desenvolvimento (selecionados no Checkpoint 2):
- A · Agente único sequencial (padrão): O Agente principal escreve cada
sections/NN-*.tsxsequencialmente. Mais estável, estilo mais uniforme. - B · Multi-agente paralelo: Cada subagente possui um arquivo
sections/NN-*.tsxe desenvolve em paralelo; o Agente principal é responsável pela mesclagem e estabilidade – mantém os imports e a ordem emArticle.tsx, executanpm run typecheck/build, garante a consistência do tema e do estilo, resolve conflitos. O modelo de prompt do subagente está emreferences/section-build.md.
Outros princípios: O corpo do texto é o principal; todos os Raw usam tokens de tema --ra-*, estilos selvagens proibidos; 100% de retenção de informação prioriza estrutura de texto longo, com Raw/imagens como aprimoramento; baixa densidade de informação pode aumentar a proporção de blocos visuais, mas ainda deve ser no formato de artigo.
Após a conclusão de cada Seção, deve seguir o Protocolo de Qualidade Rígido e usar o SubAgente Revisor de Seção: A tarefa do outline foi concluída? A proporção de retenção de informação está correta? Há continuidade com as seções anteriores e posteriores? Há uso excessivo de componentes? Há corpo de texto suficiente? Raw e imagens têm um propósito claro? A numeração da seção está consistente?
O SubAgente retorna pass/fail + pontos de reparo em mensagem (pass: uma linha de OK; fail: liste os pontos de reparo). Não escreva arquivos review/section-NN-review.md. Após receber itens de fail, o Agente principal corrige diretamente o arquivo da seção correspondente e então reporta a entrega desta seção.
Fase 6 – Final Review (Revisão Final de Três Perspectivas)
Revise das perspectivas do leitor / tema / técnica, produzindo review/final-review.md + lista de reparos. A lista de verificação completa está em references/review-checklist.md. Recomenda-se três Revisores (pelo menos um SubAgente independente se não houver Times):
- Revisor Editorial: Qualidade do artigo, seleção de informação, estrutura.
- Revisor Visual: Tema, Raw, Imagens, versão mobile.
- Revisor Técnico: Build, console, código/fórmulas, acessibilidade.
Linhas vermelhas centrais: Ainda é um artigo (não uma aplicação) · A proporção de retenção de informação está de acordo com o plano · Informações que devem ser retidas não foram perdidas · A atmosfera do tema é consistente · Raw não tem estilos selvagens · Sem cheiro forte de IA · Legível em desktop + mobile · HTML pode ser construído, aberto e compartilhado.
Fase 7 – Repair (Fatias Mínimas)
Repare na menor unidade possível. Regras em references/repair-policy.md. Proibido: Reescrever o artigo inteiro ao corrigir um único ponto / Alterar a estrutura do artigo já confirmada para reparar o visual / Deletar informações que o usuário especificou para reter para comprimir a informação. Só escreva review/repair-log.md se houver reparo (se não houver reparo / passar de primeira, não escreva).
Checkpoint 3 · Final (★Confirmação de Entrega)
Após a revisão final e correção, pare e peça ao usuário para confirmar a decisão de entrega independentemente (não pule dizendo "Vou exportar HTML, está tudo bem assim"). Priorize AskQuestion; se não houver ferramenta, liste as perguntas numeradas na mensagem, pare e aguarde resposta.
- Decisão de Entrega – Opções:
Aprovado · Exportar HTML para entrega/Aprovado · Exportar HTML + PDF simultaneamente/Ainda há reparos locais · Vou listar especificamente o que consertar/Pausar · Quero dar uma olhada novamente.
Há apenas esta decisão, mas ainda pare ativamente e pergunte, não siga silenciosamente para a exportação HTML padrão.
Fase 8 – Delivery
Construa e entregue (comandos em references/html-output.md):
article/article.html(página única autocontida, CSS + JS embutidos, pode ser aberta offline) – Entregável principal.- Opcional
article/article.pdf: Gere apenas se o usuário escolheu "Aprovado · Exportar HTML + PDF simultaneamente" no Checkpoint 3. Comando:
O script detecta o sistema… (truncado)bash <caminho-para-beautiful-article>/scripts/html-to-pdf.sh