tjdgus4560/cardnews-maker-skill

Card-News Maker (카드뉴스 메이커)

Transforme um tópico, artigo fonte (URL) ou arquivo de rascunho em um conjunto de imagens 800×800 de card-news polidas. O usuário traz um novo assunto a cada vez; você lê/deriva o conteúdo, estrutura-o em cartões, renderiza-os e, em seguida, executa um loop de auto-revisão e correção antes de entregar.

O visual é fixo (para que cada conjunto pareça uma série), mas o tema de cores se adapta ao assunto a cada vez. O layout, tipografia, espaçamento e o loop de revisão permanecem constantes.

Quando perguntar vs. quando decidir

O usuário explicitamente deseja ser perguntado sobre qualquer coisa genuinamente ambígua em vez de ter você adivinhando. Use AskUserQuestion (ofereça uma opção recomendada primeiro) quando a resposta mudaria significativamente a saída e não for inferível. Caso contrário, decida e declare sua escolha brevemente.

Decida por conta própria (não pergunte):

• Número de cartões — ajuste ao conteúdo, geralmente 8–15 (capa + corpo + encerramento).
• Tema de cores — escolha um que se adeque ao assunto/marca (veja referências).
• Layout por cartão (cartão de corpo padrão vs. cartão de estatística vs. diagrama/lista de verificação).
• Redação em coreano, ênfase em spans, rótulos de kicker.

Pergunte ao usuário (quando não estiver claro):

• Ambiguidade da fonte: apenas um tópico de uma linha sem fonte e o escopo é amplo → pergunte se deve pesquisar na web, ou qual ângulo/profundidade desejam.
• O título da capa quando nenhum título forte único surgir (padrão: proponha um + ofereça uma alternativa melhor, deixe-os escolher).
• Público/tom se o assunto puder seguir vários caminhos (ex.: brief executivo vs. explicação para iniciantes) e isso alterar materialmente o texto.
• Qualquer coisa que o usuário sinalizar como "판단 애매" — apresente como pergunta.

Quando uma preferência recorrente for decidida, está tudo bem anotá-la para que futuras execuções sejam mais suaves — mas nunca bloqueie todo o trabalho em uma pergunta que você pode responder com um padrão sensato.

Fluxo de trabalho

1. Obter o conteúdo

• URL → busque-a (WebFetch) e extraia a tese, pontos-chave, terminologia, números/citações notáveis e as principais conclusões.
• Texto / arquivo de rascunho → leia-o; trate um rascunho fornecido por capítulo como o esqueleto principal. Você pode refiná-lo levemente, mas mantenha a estrutura do usuário.
• Apenas tópico de uma linha → se o escopo for amplo e não houver fonte, pergunte se deve pesquisar na web ou qual ângulo eles desejam antes de inventar conteúdo.

Mantenha-se fiel à fonte. Evite excesso de interpretação. Ao adicionar o ângulo "o que devemos aprender / 시사점", enquadre-o como lições extraídas da fonte, não prescrições pessoais. Reformule quaisquer imperativos "faça X / 하라" em observações ("X é importante", "torna-se mais forte quando X").

2. Planejar o deck

Decida o número de cartões e a função de cada um. Um arco típico: capa → gancho/intro → contexto → conceitos centrais (uma ideia por cartão) → um cartão de estatística ou diagrama onde ajuda na transferência → mensagem de encerramento (+ link da fonte).

Use uma ideia por cartão. Se o corpo de um cartão transbordar, divida-o.

Escolha um tema de cores adequado ao assunto e leia references/design-system.md para os tokens exatos, layout do cartão e padrões de componentes. Leia references/card-patterns.md para variantes de cartão prontas (capa, corpo, estatística, diagrama, lista de verificação, encerramento).

3. Construir o HTML

Use scripts/build.js como ponto de partida — ele já codifica o sistema de layout (CSS base, chip de kicker, título, divisor, corpo com spans de destaque, rodapé, decoração de onda do rio) e gera um arquivo HTML por cartão em cards/. Copie-o para o diretório de trabalho e edite as definições do cartão e as cores do tema para este assunto. Não reescreva o motor de layout do zero.

4. Renderizar para PNG

Execute scripts/render.js (Playwright + Chromium, deviceScaleFactor 2 → PNGs nítidos de 800×800 em out/). Configuração única se o Playwright não estiver instalado: npm install playwright && npx playwright install chromium.

5. Loop de auto-revisão e correção (sempre faça isso)

Isso é obrigatório, não opcional — é o que faz a saída parecer finalizada.

• Leia os PNGs renderizados de volta (ferramenta Read) e inspecione cada cartão.
• Verifique: texto do corpo colidindo com o rodapé, desequilíbrio de espaço vazio, estouro de texto / quebras de linha estranhas, contraste/legibilidade, kicker e rodapé consistentes, números de página e contagem total corretos.
• Corrija problemas em build.js, re-renderize e re-verifique os cartões afetados.
• Entregue apenas quando todo o conjunto estiver limpo. Veja references/review-checklist.md para a lista completa e correções comuns.

6. Entregar

Onde salvar — escolha o local de saída pelo contexto, para que os resultados caiam onde o usuário os procuraria:

1. Se você estiver trabalhando dentro de um projeto/repositório (a sessão tem uma raiz de projeto — ex.: um repositório git, ou o usuário está claramente operando em um diretório de trabalho específico): salve tudo dentro da raiz do projeto, em <raiz-do-projeto>/cardnews/<tópico>/. Coloque os artefatos intermediários também lá (o build.js de trabalho, cards/*.html, out/*.png) para que o deck seja reproduzível e versionável junto com o projeto. Este é o padrão sempre que um contexto de projeto existir.
2. Se não houver contexto de projeto (uma solicitação única e ad-hoc sem repositório de trabalho): salve em um local global apropriado ao SO — <home>/cardnews/<tópico>/ (funciona em Windows, macOS e Linux; evite codificar Downloads).
3. Se o usuário nomear um local, respeite-o em vez das regras acima.

Indique onde salvou os arquivos. A saída padrão é apenas PNG (mais o HTML intermediário ao salvar dentro de um projeto, conforme regra 1). Construa o PDF A4 apenas quando solicitado (ou ofereça-o proativamente) usando scripts/make_pdf.py, que coloca cada cartão em uma página A4 com margem esquerda/direita zero (cartão preenche a largura da página) e margens superior/inferior iguais — leia seu comentário de cabeçalho para o comportamento.

Mantenha os arquivos de trabalho (build.js etc.) em uma pasta do projeto para que o usuário possa ajustar o texto e reexecutar node build.js && node render.js.

Padrões (estilo próprio desta skill)

• Tamanho: 800×800 quadrado, escala de renderização 2×.
• Estrutura por cartão: chip de kicker (número + rótulo) → título → divisor → corpo com spans de destaque seletivos → rodapé unificado (fonte · NN / total).
• Capa e encerramento: gradiente de sangria total no tema de cor, motivo de onda; cartão de encerramento carrega o link da fonte.
• Saída: PNG por padrão; PDF A4 sob solicitação.
• Idioma: texto em coreano (termos técnicos / identificadores permanecem na forma original).

Recursos

• references/design-system.md — temas de cores, tokens CSS, anatomia dos componentes.
• references/card-patterns.md — variantes de cartão prontas para copiar e colar com exemplos.
• references/review-checklist.md — o que verificar e como corrigir cada problema.
• scripts/build.js — construtor de cartões HTML (motor de layout + definições de cartão).
• scripts/render.js — renderizador Playwright HTML→PNG.
• scripts/make_pdf.py — montador de PDF A4 (margem lateral zero, margem superior/inferior).