akenoowww/art-direct-imagegen

Art-Direct ImageGen (Direção de Arte para Geração de Imagens)

Crie a ideia visual antes de pedir ao imagegen para renderizá-la. Mantenha o problema preciso e o espaço de solução aberto.

O princípio central é casca radical, semântica conservadora:

• trave conteúdo, função, tarefas do usuário, estados necessários e texto crítico;
• guie a sensação, tensão, hierarquia e uma tese conceitual;
• deixe composição, sistema visual, geometria, nuances de paleta, caráter tipográfico e detalhes de suporte abertos, a menos que o conceito realmente dependa deles.

Não transforme um pedido de criatividade em uma especificação de renderização mais longa.

Mantenha dois artefatos separados durante todo o fluxo de trabalho:

• contrato global: o inventário completo de conteúdo fornecido, funções, ações, estados e texto exato em todo o conjunto de entregáveis;
• briefing de saída atual: apenas o que deve estar visível no ativo ou estado que está sendo gerado agora.

Nunca cole o contrato global em um prompt do imagegen.

Carregar as referências relevantes

• Leia references/concept-planning.md para cada pedido que seja original, estético ou que exija julgamento crítico.
• Leia também references/flow-architecture.md para UI, informações densas, múltiplas telas, modais, gavetas, abas ou estados relacionados.
• Leia references/prompt-compilation.md imediatamente antes de preparar prompts para imagegen.
• Leia references/evaluation.md antes de julgar resultados gerados ou decidir como iterar.

Escolher o fluxo de trabalho

Use o fluxo completo de direção de arte quando o usuário pedir interpretação, originalidade, redesenho conceitual, bom gosto, memorabilidade, uma nova direção visual ou várias saídas conectadas.

Use o skill imagegen do sistema diretamente quando o usuário já tiver fixado o resultado desejado e precisar apenas de execução, como alterar um objeto, preservar tudo exceto uma edição nomeada, extrair um fundo ou renderizar um ativo estritamente especificado.

Se o usuário fornecer uma imagem, rotule seu papel antes de planejar:

• referência funcional/de conteúdo: preserve tarefas, informações, ações e estados, mas não layout ou estilo;
• referência de estilo: tome emprestadas qualidades visuais nomeadas, não conteúdo ou composição;
• alvo de edição: preserve tudo, exceto alterações explicitamente permitidas;
• âncora do sistema visual: mantenha a linguagem estabelecida consistente nas saídas posteriores.

Nunca trate silenciosamente uma referência funcional como um alvo de edição.

Fluxo de trabalho

1. Extrair o contrato global

Separe o pedido em quatro camadas:

• TRAVAR: funções exatas, conteúdo, tarefas do usuário, plataforma, ações necessárias, estados, fatos da marca e texto literal.
• GUIAR: sensação desejada, hierarquia, tensão visual, postura do produto e a qualidade que deve permanecer memorável.
• LIVRE: composição, agrupamento, ritmo espacial, nuances de paleta, caráter tipográfico, linguagem material, fundo, símbolos personalizados e detalhes de suporte.
• PROIBIR: funcionalidade ou texto inventados, affordances enganosos, clichês conhecidos, decoração irrelevante e proibições explícitas do usuário.

Não promova o layout de origem, os limites atuais dos cartões, as formas dos componentes ou os limites da página para TRAVAR a menos que o usuário os exija explicitamente.

Preserve a importância semântica e o significado do fluxo de trabalho, não a hierarquia visual da origem. Registre ações, acionadores, superfícies abertas e estados do sistema separadamente. Nunca infira um estado não suportado, confirmação ou superfície aberta apenas a partir de um rótulo de ação ou acionador.

Para interfaces densas, faça um inventário de cada bloco de conteúdo significativo e estado antes de conceber. O conjunto completo de informações deve sobreviver em todo o conjunto de saída, não em todas as saídas e não necessariamente na primeira tela.

2. Interromper a resposta óbvia

Antes de escolher uma direção visual, nomeie a conclusão previsível mais próxima específica do meio, em particular, e coloque-a em quarentena: uma composição de stock, tratamento de superfície da moda, simbolismo genérico, arquétipo de layout familiar ou um rótulo de estilo colado em uma estrutura inalterada.

Não use uma lista de proibições como substituta para um conceito. Um conceito explica o que organiza o trabalho; proibições apenas removem modos de falha.

3. Divergir por mecanismo

Desenvolva pelo menos três candidatos a conceito semanticamente diferentes para um pedido criativo substancial. Eles devem diferir em lógica organizadora, não apenas em paleta, tipo de letra ou decoração.

Para cada candidato, defina apenas:

1. tese de uma frase;
2. sensação pretendida;
3. principal gesto estrutural ou composicional;
4. como a função/conteúdo exigido vive dentro dele;
5. por que não é um modelo transferível;
6. seu maior risco de usabilidade ou coerência;
7. o que permanece intencionalmente livre para o renderizador.

Não exponha a lista interna completa a menos que a comparação beneficie o usuário. O objetivo é pressão de seleção, não um portfólio.

4. Selecionar dialeticamente

Aplique uma passagem curta de tese/antítese/síntese a cada candidato sério:

• Tese: por que o conceito é memorável e adequado a esta tarefa específica.
• Antítese: como ele pode se tornar decorativo, confuso, derivado ou impossível de implementar.
• Síntese: se a fraqueza pode ser removida sem matar o conceito.

Primeiro, rejeite candidatos que percam conteúdo, função, legibilidade, descobribilidade ou implementabilidade. Entre os sobreviventes, escolha a direção com o ponto de vista mais claro e a maior resistência a transferência. Não faça a média ou mescle todos os candidatos em uma sopa de estilos.

5. Planejar o conjunto de saída

Para um único ativo independente, prossiga para a ficha conceitual.

Para UI densa ou estados conectados:

1. classifique a informação como primária, secundária ou contextual;
2. escolha rolagem, abas, gaveta, modal ou tela separada por significado de interação;
3. mapeie cada item de origem para um destino;
4. defina o manifesto de saída mínimo;
5. garanta que toda superfície oculta tenha um acionador descobrível em um estado anterior;
6. gere cada tela ou estado necessário com uma chamada imagegen separada;
7. use a primeira saída aceita como a âncora do sistema visual para saídas subsequentes.

Não solicite várias telas finais como uma colagem, a menos que o usuário queira explicitamente um quadro de comparação. Consulte references/flow-architecture.md.

Não trate a visibilidade de origem como prioridade semântica. Um formulário completo, proveniência ou histórico detalhado e conteúdo de suporte longo não são primários apenas porque a origem os exibiu ao lado da tarefa central. Mantenha apenas as informações necessárias imediatamente ou comparadas simultaneamente na Saída 1.

Antes da compilação do prompt, marque cada item do inventário como AGORA, EM_OUTRO_LUGAR ou NÃO_SUPORTADO para a saída atual. Não continue enquanto algum item não tiver um destino.

Use NÃO_SUPORTADO apenas para conteúdo, dados, resultados ou comportamento ausentes. Uma nova aba, gaveta, modal, região expansível ou continuação de rolagem apenas para apresentação é arquitetura de informação, não uma função de produto inventada, quando apenas realoca o conteúdo fornecido, não cria novos dados ou resultados e tem um ponto de entrada descobrível. Introduza e renderize esse estado separadamente quando a densidade exigir.

Rejeite o plano de saída antes da geração quando ele combinar uma única viewport, texto primário longo, formulários ou detalhes contextuais completos, tipografia legível e espaço negativo generoso. Divida o conjunto de saída. Um estado descrito como padrão, fechado ou não aberto não deve mostrar simultaneamente o conteúdo interno de suas superfícies fechadas.

Exija várias saídas quando o conteúdo primário longo competir com um formulário independente completo e regiões de suporte detalhadas. Não abra mão disso porque a tela original é grande ou tecnicamente legível.

6. Destilar uma ficha conceitual

Antes de escrever o prompt do renderizador, congele apenas:

• a tese conceitual de uma frase;
• a sensação pretendida e a tensão visual;
• um movimento principal e no máximo dois movimentos de suporte;
• a lista TRAVAR;
• uma lista curta PROIBIR;
• a saída/estado que está sendo renderizado agora.

Se a ficha contiver coordenadas exatas, uma árvore de componentes completa, muitos valores de cor, cada raio de canto ou instruções para cada elemento secundário, provavelmente é uma especificação de layout, não direção de arte. Remova detalhes que não carregam o conceito ou protegem a funcionalidade.

Mantenha o movimento principal no planejamento. Traduza-o um nível acima para o renderizador: descreva a relação organizadora, o resultado perceptual ou a tensão, não sua direção exata, posição, contagem, forma ou topologia, a menos que o usuário tenha fixado essa geometria explicitamente.

7. Compilar prompts por ativo

Prepare um prompt para cada ativo ou estado distinto. Inclua apenas o papel da origem, objetivo da saída atual, intenção conceitual não geométrica, travas da saída atual, latitude criativa e os poucos itens a evitar que importam.

Não cole o raciocínio completo da descoberta, mapa de cobertura, conceitos rejeitados ou lista de travas globais no prompt. Não peça ao renderizador para literalizar cada dica. Coloque apenas texto curto crítico necessário nesta saída no prompt; mantenha texto longo na referência de origem, mapa de cobertura ou camada de implementação. Distribua-o pelas saídas em vez de forçar uma densidade ilegível.

Falhe na compilação do prompt e retorne ao planejamento de saída quando:

• o prompt descrever mais de um estado ou incluir conteúdo EM_OUTRO_LUGAR;
• o prompt disser para preservar cada item fornecido em uma saída em vez de nomear o subconjunto da saída atual;
• o prompt carregar um longo catálogo de rótulos ou regiões de conteúdo que deveriam ter sido distribuídos;
• a latitude criativa for declarada após a composição ou topologia já ter sido fixada;
• uma solicitação de uma única viewport também exigir todo o texto longo, formulários completos e legibilidade espaçosa;
• a lista de evitação se tornar um catálogo genérico de anti-estilos;
• o ativo for chamado de enviável ou pronto para produção em vez de uma direção visual de alta fidelidade.

Use as receitas em references/prompt-compilation.md.

8. Invocar o fluxo de imagem do sistema

Siga o skill imagegen do sistema instalado para escolha de ferramenta, manipulação de imagem de entrada, caminhos de salvamento, transparência e entrega. Use a ferramenta de geração de imagem integrada por padrão.

Para várias saídas distintas, emita uma chamada por ativo ou estado. Após aceitar a primeira saída, forneça-a como referência do sistema visual para saídas posteriores, repetindo invariantes críticas.

9. Criticar a imagem real

Julgue a saída, não a elegância do prompt. Aplique references/evaluation.md.

Use dois tipos de iteração:

• Falha local: faça uma alteração direcionada, reafirme invariantes e preserve o conceito aceito.
• Falha estrutural ou genérica: retorne à ramificação de conceitos ou arquitetura de saída. Não acrescente mais adjetivos, proibições, coordenadas, referências de estilo, regiões nomeadas ou topologia a um conceito falho.

Mantenha a liberdade criativa monotônica entre as repetições estruturais: um novo prompt de renderizador não deve prescrever mais layout, geometria, orientação, contagem, camadas ou posicionamento do que o prompt falho. Mude o conceito semântico. Se o mesmo conceito produzir um resultado transferível ou genérico duas vezes, descarte-o e selecione um candidato diferente de outro mecanismo de divergência.

Nunca resgate um conceito ilegível detalhando seu wireframe. Se o conceito se tornar visível apenas após planos, zonas, porções expostas, conectores ou ordem espacial exatos serem prescritos, o conceito é inadequado para este fluxo de trabalho. A precisão é permitida apenas para uma edição local após o sistema visual já ter passado pelo portão criativo.

Pare quando a saída for funcionalmente verdadeira, conceitualmente legível, coerente, distinta e utilizável para o fim pretendido. Relate o conceito selecionado, as saídas geradas e o conjunto final de prompts conforme exigido pelo fluxo de trabalho de imagem do sistema.

Barreiras de proteção não negociáveis

• Nunca confunda detalhe com criatividade.
• Nunca deixe o primeiro conceito plausível vencer sem oposição.
• Nunca chame trocas de paleta ou trocas de rótulo de estilo de conceitos independentes.
• Para saídas interativas, nunca esconda informações primárias apenas para fazer uma tela parecer mais limpa.
• Nunca invente conteúdo, métricas, estados ou controles para preencher uma composição.
• Nunca torne cada elemento incomum; concentre a originalidade em um movimento decisivo em nível de sistema.
• Para saídas interativas densas, nunca force todas as informações em uma única viewport apenas porque a origem usou uma página.
• Nunca mostre o conteúdo de uma superfície fechada em um estado padrão ou não aberto.
• Nunca deixe um prompt de renderizador carregar o inventário completo de conteúdo global.
• Nunca classifique todo bloco de origem visível como primário sem provar dependência simultânea de tarefa.
• Nunca chame realocação apenas de apresentação de uma função inventada.
• Nunca reivindique liberdade criativa após prescrever a composição completa.
• Nunca faça uma repetição estrutural mais geometricamente específica do que o prompt falho.
• Nunca mantenha o mesmo conceito após duas falhas estruturais genéricas.
• Trate as imagens de UI geradas como direção visual, não como prova de implementação, até que sejam construídas e testadas.
• Para saídas bitmap com texto, nunca prometa texto longo perfeito. Divida o conteúdo, verifique rótulos críticos e preserve o texto exato em artefatos de implementação quando a fidelidade for importante.