Ir para o guia de uso
Dream Looppor achimala

Dream Loop Skill.

Estabeleça primeiro a captura de tela desejada e depois use-a como alvo da implementação.

  • Iteração visual
  • Design de jogos
  • Prototipagem
Revisão da fonte · Dream LoopSKILL.md
Tarefa Iteração visual Produz • Uma imagem-alvo salva que representa a visualização pretendida do jogo ou app. • Trabalho de implementação avaliado em relação a esse alvo visual. • Contexto de iteração local à tarefa, na pasta de trabalho documentada. Antes de começar Exige uma imagem-alvo ou acesso à geração de imagens, caso nenhuma seja fornecida. Os requisitos detalhados de ferramentas dependem do fluxo de trabalho referenciado selecionado e não foram estabelecidos apenas pela entrada.
Resumo editorial · fonte revisada em 2026-10-07 · não é um exemplo gerado

01 Funcionalidades

Construa em direção a um alvo visual concreto

Um processo de implementação orientado por capturas de tela, com modos de fluxo de trabalho separados, preservação da base visual e considerações explícitas sobre orçamento de recursos.

Fluxo de trabalho baseado na fonteNão é um benchmark de execução

A abordagem de trabalho

Dream Loop é um processo de iteração visual para jogos e apps, com ênfase especial em cenas gráficas de alta fidelidade. Seu artefato central é uma imagem-alvo: fornecida pelo usuário ou gerada como uma captura de tela plausível do resultado pretendido. Para um produto existente, a fonte pede uma captura de tela atual como base antes de gerar um refinamento.

O arquivo de entrada direciona a execução para fluxos de trabalho de referência separados, Plus e Pro, e diz explicitamente que eles não são intercambiáveis. A entrada revisada descreve as regras compartilhadas de imagem-alvo e orçamento de tempo, mas não estabelece por si só a mecânica detalhada da iteração. Por isso, esta página não promete uma stack de implementação específica, um benchmark nem um resultado automático com precisão de pixel.

Entregas esperadas

  • Uma imagem-alvo salva que representa a visualização pretendida do jogo ou app.
  • Trabalho de implementação avaliado em relação a esse alvo visual.
  • Contexto de iteração local à tarefa, na pasta de trabalho documentada.
Ver o briefing de exemplo

Do briefing à revisão

  1. 01
    Escolha o modo documentado

    Siga o fluxo de trabalho Plus ou Pro solicitado. Se nenhum for especificado, a fonte seleciona um caminho conforme o nível da assinatura de programação; leia apenas o guia desse caminho.

  2. 02
    Defina o alvo

    Use uma imagem fornecida ou gere uma captura de tela-alvo realista. Se estiver refinando um produto, primeiro capture sua aparência atual.

  3. 03
    Itere dentro do escopo

    Construa em direção ao alvo, verificando qualquer orçamento de tempo informado. Relate o progresso relevante sem disfarçar uma fidelidade inacabada como conclusão.

02 Quando usar

Quando usar

Exige uma imagem-alvo ou acesso à geração de imagens, caso nenhuma seja fornecida. Os requisitos detalhados de ferramentas dependem do fluxo de trabalho referenciado selecionado e não foram estabelecidos apenas pela entrada.

Bom para

  • Protótipos gráficosÚtil quando um alvo visual concreto comunica o resultado pretendido melhor do que adjetivos sozinhos.
  • Refinamento de produto existenteAncora o alvo em uma captura de tela atual para que uma melhoria visual não se torne um redesign sem relação com o produto.

Limites a verificar

  • Capacidade de alvo necessáriaSem geração de imagens, a fonte pede um alvo fornecido ou um serviço de geração de imagens conectado.
  • Iteração potencialmente caraA fonte avisa que um ciclo sem limite definido pode consumir muitos tokens.
  • Guias de fluxo de trabalho adicionais necessáriosAs instruções Plus e Pro ficam em arquivos de referência separados. Leia o guia selecionado para estabelecer suas ferramentas e critérios de conclusão antes de começar.

Traga estas entradas

  • Briefing do jogo ou appDescreva a visualização real e o que ela deve fazer.
  • Imagem atual ou alvoForneça a base de um produto existente ou um alvo, quando disponível.
  • Modo e orçamentoInforme o fluxo de trabalho solicitado e quaisquer restrições de tempo ou recursos.

03 Decisões importantes

Decisões que importam

  1. Uma captura de tela é uma restrição compartilhada

    Um alvo concreto reduz a ambiguidade sobre composição, iluminação ou qualidade gráfica.

  2. Não é arte conceitual

    A fonte pede um alvo de implementação realista, e não uma imagem evocativa que não poderia plausivelmente ser o app.

  3. Preserve a base

    O refinamento parte do que já existe, reduzindo desvios visuais acidentais.

04 Exemplo de briefing

Experimente um briefing focado

O briefing de exemplo abaixo não foi testado. Verifique a configuração da skill antes de usá-lo.

Revise a configuração

Instale a Skill completa, incluindo as referências do fluxo de trabalho escolhido. Não trate o arquivo de entrada curto como um runtime autônomo.

Arquivo-fonte original
https://github.com/achimala/dream-loop/blob/9bddb901f7d071cfefdd21e264267c757177a9df/SKILL.md

Exige uma imagem-alvo ou acesso à geração de imagens, caso nenhuma seja fornecida. Os requisitos detalhados de ferramentas dependem do fluxo de trabalho referenciado selecionado e não foram estabelecidos apenas pela entrada.

Comece com uma entrega

Adapte o escopo, o material de origem e as restrições deste briefing antes de executar a skill.

Briefing de exemplo
Use dream-loop para melhorar a fidelidade gráfica desta cena de navegador existente. Capture a visualização atual, crie uma captura de tela-alvo realista que preserve o layout e o conceito de interação e confirme o fluxo de trabalho de referência Plus ou Pro aplicável. Mantenha o trabalho local e relate com honestidade as lacunas visuais restantes no limite de tempo informado.

Inspecione o resultado

Compare a saída real com estes critérios observáveis.

  • O alvo é armazenado e está claramente ligado à visualização do produto solicitada.
  • As melhorias em produtos existentes preservam as restrições da base fornecida.
  • A conclusão relatada reflete uma comparação visual real, e não apenas uma compilação bem-sucedida.

OpenDesign oferece um espaço de trabalho de design local para agentes de programação. Esta listagem não significa que a skill esteja incluída no pacote nem que suas ferramentas externas, credenciais e dependências de software estejam incluídas.

05 Fonte e licença

Fonte e licença

Esta página descreve a revisão fixada da fonte vinculada abaixo. O comportamento e os requisitos upstream podem mudar.

Proprietário da fonte
achimala
Arquivo da skill
SKILL.md
Licença
MIT
Versão revisada
2026-10-07 · 9bddb901f7d0
Resumo editorial da fonte
Um processo de implementação orientado por capturas de tela, com modos de fluxo de trabalho separados, preservação da base visual e considerações explícitas sobre orçamento de recursos.

Resumo original de OpenDesign, com base na fonte vinculada. As estrelas do repositório são um sinal de popularidade datado, não uso da skill nem nota de qualidade.

06 Perguntas antes de começar

Perguntas antes de começar

Ela precisa gerar uma imagem-alvo?

Não. A fonte permite um alvo fornecido pelo usuário; a geração é necessária quando não há alvo disponível.

O alvo deve ser arte conceitual?

Não. A fonte pede especificamente uma captura de tela-alvo realista, que a implementação possa tentar reproduzir.

O arquivo de entrada define um único ciclo universal?

Não. Ele escolhe entre fluxos de trabalho de referência Plus e Pro separados, então esses detalhes precisam ser revisados para o ambiente de execução escolhido.

OpenDesign

Abra espaço para a próxima iteração de design.

Mantenha seu briefing, o material de origem e o trabalho de design juntos em um espaço de trabalho local. Verifique a configuração da própria skill antes de adicioná-la ao seu fluxo de trabalho.

Arquivo-fonte original
https://github.com/achimala/dream-loop/blob/9bddb901f7d071cfefdd21e264267c757177a9df/SKILL.md