daiki-beppu/youtube-automation

前後工程

• 前工程: なし
• 後工程: なし
• 委譲先: なし

成果物

• 書き込む: ユーザーが指定したHTML表示層
• 読み込む: 対象実装、URL、スクリーンショット

Hallmark

Esta cópia com escopo de projeto é apenas para desenvolvimento. Preserve os limites de implementação existentes e carregue as regras referenciadas apenas quando relevante.

Uma habilidade de design para assistentes de codificação de IA. Faz com que as IUs que eles geram pareçam feitas, não geradas.

Hallmark é opinativa, curta e propositalmente chata. Ela codifica um conjunto restrito de regras — extraídas do consenso do campo de design anti-slop (habilidade de design de frontend da Anthropic, o cookbook Claude sobre estética de frontend e o movimento 'tátil de rebelião' de 2026) — e se recusa a deixar o modelo cair nos padrões nos quais todos os LLMs foram treinados.

O diferencial: Hallmark insiste em variedade estrutural, não apenas visual. Duas páginas do Hallmark para dois briefs diferentes não devem compartilhar o mesmo ritmo de herói → 3 recursos → CTA → rodapé. Elas devem parecer sites diferentes, não trocas de cores do mesmo modelo. Veja references/structure.md.

Desenvolvido com Together AI.

---

Como usar esta habilidade

O Hallmark tem um comportamento padrão e três verbos explícitos.

Invocação	O que faz
(padrão)	O usuário pediu para você projetar ou construir algo novo. Siga o Fluxo de Design abaixo.
hallmark audit <alvo>	Leia o alvo, pontue-o contra a lista de antipadrões e retorne uma lista priorizada de correções. Não edite.
hallmark redesign <alvo> [--mood <nome>]	Pegue o conteúdo e a intenção do alvo e redesenhe a estrutura visual dentro dos limites de implementação existentes, a menos que o usuário confirme explicitamente uma reconstrução completa. Novo ritmo de seção, novo posicionamento de cabeçalho, nova voz do componente. Preserve rotas existentes, propriedade do componente, intenção da cópia, marca e arquitetura da informação; substitua apenas a camada visual/de interação necessária para o escopo solicitado.
`hallmark study <screenshot	URL>`

Se o usuário digitar algo que não mapeie claramente para audit, redesign ou study, trate como padrão. Se o usuário anexar uma imagem ou colar uma URL sem um prefixo de verbo, pergunte: "Devo study isto (extrair o DNA) ou devo tratar como referência para uma nova construção?"

Trilho de segurança de implementação. Hallmark é uma habilidade de design, não uma licença para destruir uma base de código. Em qualquer projeto existente:

• Nunca exclua arquivos de produção, árvores de rotas, diretórios de componentes ou um site antigo, a menos que o usuário peça explicitamente a exclusão ou aprove um plano em nível de arquivo que liste as exclusões.
• Padrão para edições in-loco dos arquivos nomeados, ou novos componentes/tokens aditivos que são conectados através da rota existente. Se o redesenho exigir a remoção de vários componentes, pare e peça confirmação primeiro.
• Trate PDFs, arquivos README, briefs .md, documentos, transcrições e decks de pitch como material de referência. Não os copie palavra por palavra na página, a menos que o usuário diga explicitamente para usar esse texto textualmente.
• Antes de editar, declare os arquivos exatos que você espera modificar/criar/excluir. Exclusões exigem confirmação explícita.

O fluxo de Design padrão sempre escolhe um tema. Por padrão, ele escolhe um dos 21 temas nomeados — o catálogo — e faz rodízio entre eles de acordo com a regra de diversificação. Há também uma ramificação customizada silenciosa que constrói uma paleta OKLCH única + pareamento de fontes gratuitas para o brief; a rota customizada é acionada apenas quando o brief carrega um sinal de intenção criativa (o usuário nomeia uma cor de marca, nomeia um vibe de múltiplos atributos que o catálogo não pode carregar ou pede explicitamente um tema customizado). Para briefs comuns, o usuário nunca vê as palavras 'catálogo' ou 'customizado' — o catálogo é executado silenciosamente. Veja a Etapa 1 (detecção de sinal) e a Etapa 2.6 (despacho); o protocolo vive em references/custom-theme.md.

---

Disciplinas que valem para todos os verbos

Estas seis disciplinas não são específicas de verbo. Elas se aplicam ao Design padrão, audit, redesign, study e escopo de componente igualmente. Elas ficam ao lado do teste de slop, não dentro de um ramo dele.

1. Autocrítica pré-emissão. Antes de entregar qualquer saída, pontue-a de 1 a 5 em seis eixos — Filosofia, Hierarquia, Execução, Especificidade, Moderação, Variedade. Qualquer coisa < 3 aciona uma passagem de revisão. Carimbe as seis pontuações no topo do artefato (/* Hallmark · pré-emissão crítica: P5 H4 E5 S4 R5 V5 */). Veja references/slop-test.md § Autocrítica pré-emissão.

2. Cópia honesta — sem conteúdo fabricado. Se o usuário não forneceu uma métrica, não invente uma. Layouts liderados por estatísticas, linhas de comparação e barras de prova devem usar números reais, um espaço reservado (— mais um bloco cinza rotulado 'métrica a confirmar') ou uma macroestrutura diferente. '+47% de conversão', 'confiado por mais de 50.000 equipes' e '10x mais rápido' são slop no momento em que são inventados. Mesma regra para depoimentos, logotipos e contagens de estudos de caso. Veja references/anti-patterns.md § Métricas inventadas e porta de teste slop 46.

3. Tokens bloqueados — sem improvisação no meio da renderização. Uma vez que um tema é selecionado na Etapa 2.6, toda cor e toda declaração font-family no artefato deve referenciar um token nomeado (var(--color-accent), font-family: var(--font-display)). Valores OKLCH / hex / rgb() inline, ou uma declaração font-family: 'Some Font' que ignore o bloco de token, não são permitidos. Se um valor for necessário que não exista como token, eleve-o ao bloco de token como uma nova variável nomeada e depois faça referência a ele. Veja references/anti-patterns.md § Impovização de tokens no meio da renderização e porta de teste slop 48.

4. Cromo de navegador redesenhado proibido. Hallmark não deve construir manualmente barras de navegador falsas (pílula de URL + pontos de semáforo), molduras de telefone falsas, janelas de bloco de código falsas (barra de título mock + pontos envolvendo um <pre>) ou cromo de IDE falso — o ambiente do usuário já fornece cromo real. Use capturas de tela reais envoltas em um <figure> (com no máximo uma borda fina) ou omita o cromo e deixe o conteúdo se sustentar sozinho. Veja references/anti-patterns.md § Cromo de UI redesenhado e porta de teste slop 47.

5. Responsividade móvel — cada emissão verificada em 320 / 375 / 414 / 768 px. A saída do Hallmark deve renderizar perfeitamente em todas as quatro larguras. Os itens não negociáveis: sem rolagem horizontal + raiz overflow-x: clip tanto em html quanto em body, nunca hidden (porta 34); sem texto clicável de duas linhas — botões, links de navegação primária, links de rodapé, breadcrumbs, CTAs (porta 49); trilhas de grade que contêm imagens usam minmax(0, 1fr), nunca 1fr simples (porta 50); cabeçalhos de exibição quebram palavras longas via overflow-wrap: anywhere; min-width: 0 (porta 51); cabeçalhos de seção colapsam para uma coluna no celular em todas as variantes de tema (porta 52); padrões de guia de rádio não saltam na rolagem (porta 53). Veja references/responsive.md § Móvel — não negociável. Este é um piso duro, não uma lista de desejos.

6. Pureza tipográfica — sem cabeçalhos em itálico. Cabeçalhos e texto de exibição são sempre romanos (font-style: normal). Uma palavra de ênfase em itálico dentro de um cabeçalho reto (Construído para <em>pensar</em>) é um dos sinais de IA mais confiáveis; o mesmo vale para uma face de exibição totalmente em itálico em cabeçalhos. Carregue ênfase com peso, cor de destaque ou um sublinhado desenhado. Itálico sobrevive apenas como ênfase de corpo de texto dentro de parágrafos corridos. Veja references/anti-patterns.md § Cabeçalhos em itálico e porta de teste slop 38a.

---

Quando o brief é um componente, não uma página

Antes de entrar no fluxo de Design completo, verifique o escopo. Se algum destes for acionado, execute o fluxo de Escopo de Componente — a maioria das solicitações de desenvolvimento do dia a dia são em forma de componente, não de página, e o aparato de nível de página (macroestrutura, enriquecimento de herói, arquétipo de rodapé, memória de projeto) está errado para elas.

Sinais de escopo de componente:

• O brief nomeia um único elemento de UI: um botão · uma entrada · um cartão · um modal · um dropdown · uma dica de ferramenta · um select · uma caixa de seleção · um interruptor · uma guia · um chip · um emblema · um banner · um snackbar · um popover · um slider · um seletor de data · um avatar.
• O brief é curto (≤ 30 palavras) e se refere a um elemento.
• O arquivo alvo é um único componente (ex.: ./Button.tsx, ./components/Input.css, app/components/Card.vue).
• O usuário explicitamente diz 'só o X', 'apenas o Y', 'este único elemento', 'um único ___'.

Se dois sinais forem acionados, roteie componente. Se apenas o fluxo de página for acionado (brief de várias seções, 'construa-me uma landing page'), permaneça no fluxo de Design.

O que o Escopo de Componente mantém do fluxo de página

• Etapa 0 · Varredura pré-voo — mesma. Leia tokens existentes, fontes, framework, postura de microinteração. Um botão em um projeto Tailwind com corpo Geist deve adotar esses tokens, não inventar novos.
• Etapa 1 · Detecção de gênero — mesma. Editorial / minimalista moderno / atmosférico / lúdico. O componente herda o gênero de seu entorno (padrão silencioso para editorial quando desconhecido).
• Etapa 2.6 · Rota de tema — mesma. Se um tokens.css ou design.md existir, o componente usa esses tokens. Caso contrário, pergunta 'há um sistema a seguir, ou devo escolher um?' — padronizando para catálogo se o usuário ficar em silêncio.
• Disciplina de 2+1 fontes — mesma.
• Disciplina de estado — MAIS RIGOROSA. Cada componente interativo DEVE enviar código para todos os 8 estados: padrão · hover · :focus-visible · :active · desabilitado · carregando · erro · sucesso. A lista de verificação de 8 estados em interaction-and-states.md é obrigatória, não consultiva.
• Teste de slop — subconjunto apenas universal. Execute os portões visual / microinteração / contraste (portões 40–41) / acessibilidade / tipografia. Pule os portões de diversificação (nenhuma entrada .hallmark/log.json — componentes não fazem rodízio) e pule os portões de segurança de layout que assumem uma página completa.

O que o Escopo de Componente pula

• Etapa 2 · Escolha de macroestrutura. Componentes não têm macroestruturas. Declare isso explicitamente: 'Escopo de componente: pulando macroestrutura.'
• Escolhas de arquétipo de navegação e rodapé. N1a–N13 e Ft1–Ft8 são apenas de escopo de página. Um componente é um elemento; não tem navegação, nem rodapé. Pule ambos.
• Padrões de polimento de herói (HP1–HP4). Apenas escopo de página. Um botão ou cartão não tem herói.
• Etapa 4 · Enriquecimento. Nenhuma ilustração de herói, nenhum vídeo de demonstração, nenhum fundo abstrato. O componente É o artefato.
• Etapa 5 · Pré-visualização de várias seções. Substituída pelo wrapper de demonstração de 8 estados (abaixo).
• Anexo de memória de projeto. Nenhuma entrada .hallmark/log.json para execuções de componente. A regra de diversificação não se aplica.

O que o Escopo de Componente emite

Dois arquivos, lado a lado:

1. O artefato do componente — um único arquivo autocontido que corresponde às convenções do projeto:

   • React / Vue / Svelte: Button.tsx / Button.vue / Button.svelte
   • Web vanilla: button.css + button.html
   • Tailwind: um .tsx com cadeias className E um tokens.css se estiver faltando
   • O componente consome tokens Hallmark pelo nome (var(--color-accent)), nunca incorpora valores OKLCH inline.

2. Um wrapper de demonstração de 8 estados — <ComponentName>.preview.html (ou .preview.tsx). Uma pequena página independente que renderiza o componente em todos os 8 estados empilhados verticalmente, cada um rotulado. O usuário a abre uma vez, vê o componente funcionando, depois a exclui. O wrapper não faz parte do código de produção. Formato:

   ┌──── Button — 8 estados ────────────────────────┐
   │                                                │
   │ padrão       [ Clique em mim              ]    │
   │ hover         [ Clique em mim              ]    │  ← .is-hover força o estilo :hover
   │ foco          [ Clique em mim              ]    │  ← .is-focus força :focus-visible
   │ ativo         [ Clique em mim              ]    │  ← .is-active força :active
   │ desabilitado  [ Clique em mim              ]    │  ← atributo disabled
   │ carregando    [ ⌛ Trabalhando…            ]    │  ← data-state='loading'
   │ erro          [ ⚠ Tente novamente         ]    │  ← data-state='error'
   │ sucesso       [ ✓ Salvo                   ]    │  ← data-state='success'
   │                                                │
   └────────────────────────────────────────────────┘
   

   Cada linha rotulada usa uma classe (ex.: .is-hover) que o CSS do componente almeja além da pseudo-classe real, para que todos os 8 estados sejam renderizados de uma vez na página de demonstração. Exemplo:

   .btn:hover, .btn.is-hover { background: var(--color-paper-3); }
   .btn:focus-visible, .btn.is-focus { outline: 2px solid var(--color-focus); }
   .btn:active, .btn.is-active { transform: translateY(1px); }
   

Formato de carimbo para saída de componente

Componentes carimbam de forma diferente das páginas:

/* Hallmark · componente: <tipo> · gênero: <gênero> · tema: <nome do tema> */

Exemplo:

/* Hallmark · componente: botão · gênero: editorial · tema: Hawthorne */

---

Fluxo de Design (invocação padrão)

(O fluxo de Design detalhado é omitido aqui para brevidade da tradução, mas deve ser preservado no SKILL.md completo se presente; esta tradução mantém a estrutura indicada e a intenção do fluxo.)