106.9K+Baixar
Ir para o guia de uso
Design Flowpor julianoczkowski

Design Flow Skill.

Conduza um projeto de design por fases explícitas e artefatos salvos.

  • Fluxo de design
  • Revisão
Baixar OpenDesignVer guia de uso
Análise da fonte · design-flowSKILL.md
Tarefa Conduza um projeto de design por fases explícitas e artefatos salvos. Entregáveis Briefing, arquitetura da informação e artefatos de tokens específicos da funcionalidade, conforme necessário. Antes de começar O orquestrador depende das skills indicadas e de suas instruções completas.
Resumo editorial · fonte revisada em 2026-11-02 · não é um exemplo gerado

01 Funcionalidades

Conduza um projeto de design por fases explícitas e artefatos salvos

Siga uma sequência guiada de perguntas de design e arquitetura da informação até tokens, tarefas e implementação, com revisão solicitada separadamente.

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

A abordagem de trabalho

Design Flow coordena as skills complementares de design em uma sequência definida. Começa com perguntas de esclarecimento, registra um briefing, desenvolve a arquitetura da informação, estabelece tokens e transforma o briefing em tarefas implementáveis. A implementação de frontend segue essa lista. Cada etapa tem uma saída explícita e uma transição que o designer confirma.

A fonte trata o fluxo como retomável. Os artefatos de cada funcionalidade ficam juntos em uma pasta .design, permitindo continuar a partir da próxima etapa incompleta. A revisão de design é uma etapa separada, solicitada depois que algo foi construído; concluir a sequência, por si só, não comprova aprovação em revisão visual.

Entregas esperadas

  • Briefing, arquitetura da informação e artefatos de tokens específicos da funcionalidade, conforme necessário.
  • Um checklist ordenado em TASKS.md seguido durante a implementação de frontend.
  • Componentes e páginas construídos na fase de implementação, com artefatos de planejamento salvos para permitir a retomada.
Ver o briefing de exemplo

Do briefing à revisão

  1. 01
    Escolha as fases necessárias

    Explique a sequência completa e identifique etapas que podem ser puladas. Tokens existentes ou um escopo de componente único podem eliminar trabalho desnecessário.

  2. 02
    Esclareça e salve a intenção de design

    Execute integralmente as skills complementares relevantes, preservando o briefing e a arquitetura da informação na mesma pasta da funcionalidade. Confirme cada fase antes de continuar.

  3. 03
    Transforme a intenção em implementação

    Gere ou amplie tokens, crie a lista de tarefas e execute suas partes implementáveis. Marque tarefas concluídas, com confirmação entre elas.

  4. 04
    Revise quando solicitado

    Execute a skill separada design-review somente depois de existir uma interface implementada e de a revisão ser solicitada. Suas capturas e descobertas devem ficar junto dos demais artefatos da funcionalidade.

02 Quando usar

Quando usar

O orquestrador depende das skills indicadas e de suas instruções completas.

Bom encaixe

  • Planejamento de uma nova funcionalidadeUm designer precisa de um caminho guiado da ideia inicial à implementação.
  • Projetos interrompidosOs artefatos salvos da funcionalidade permitem retomar o fluxo mantendo as decisões anteriores.

Limites a verificar

  • Skills complementares necessáriasO orquestrador depende das skills indicadas e de suas instruções completas.
  • Transições explícitasA fonte espera confirmação entre fases, em vez da execução silenciosa de toda a sequência.
  • Revisão separadaA revisão não é automática e exige código implementado para examinar.

Traga estas entradas

  • Intenção do projetoDescreva a funcionalidade, o objetivo do usuário e as decisões existentes.
  • Repositório atualForneça componentes, tokens e artefatos da funcionalidade já existentes.
  • Preferência de fluxoIdentifique etapas já concluídas ou deliberadamente puladas.

03 Decisões importantes

Decisões importantes

  1. Decisões conectadas

    O briefing orienta arquitetura, tokens e tarefas de implementação.

  2. Artefatos com escopo próprio

    Pastas separadas por funcionalidade impedem que projetos sem relação sobrescrevam uns aos outros.

  3. Retomada clara

    Os artefatos existentes mostram de onde continuar após uma pausa.

04 Exemplo de briefing

Experimente um briefing específico

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

Confira a fonte e a configuração

Descreva a funcionalidade, o objetivo do usuário e as decisões existentes.

Arquivo-fonte original
https://github.com/julianoczkowski/designer-skills/blob/c259656c76d9758d7ead46b0d2f125cbe84f8665/design-flow/SKILL.md

A referência abaixo abre as instruções originais. Confira a configuração do repositório antes de usá-las; não é um comando de instalação.

Comece com um entregável

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

Briefing de exemplo
Use design-flow para uma nova página de atividade da equipe neste repositório. Primeiro inspecione as pastas de funcionalidades existentes em .design e nossos tokens atuais. Explique a sequência de fases e recomende quais etapas podemos pular com base no que já existe. Mantenha briefing, arquitetura e tarefas juntos em uma única pasta da funcionalidade. Confirme cada transição antes de prosseguir e preserve as decisões aceitas nas etapas seguintes. Durante a implementação, siga o checklist de tarefas. Deixe a revisão de design como uma etapa separada e claramente identificada, a menos que eu a solicite explicitamente durante o fluxo.

Inspecione o resultado

Compare o resultado real com estes critérios observáveis.

  • O artefato de cada fase reflete as decisões da etapa anterior.
  • Fases concluídas e puladas são distinguíveis na entrega.
  • A revisão não é apresentada como aprovada apenas porque a implementação terminou.

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 nem que suas ferramentas externas, credenciais e dependências de software estejam incluídas.

Baixar OpenDesignLer o guia rápido

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.

Responsável pela fonte
julianoczkowski
Repositório
julianoczkowski/designer-skills
Arquivo da skill
SKILL.md
Licença
Apache-2.0
Versão revisada
2026-11-02 · c259656c76d9
Resumo editorial da fonte
Conduza um projeto de design por fases explícitas e artefatos salvos.

Resumo original de OpenDesign, baseado 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

Todo projeto precisa executar todas as fases?

Não. A fonte permite explicitamente pular fases desnecessárias, como arquitetura da informação para um único componente.

Onde os artefatos são armazenados?

Eles ficam agrupados em .design/<feature-slug>/ para que cada funcionalidade tenha seu próprio registro.

O fluxo executa a revisão de design automaticamente?

Não. A revisão é solicitada separadamente depois de componentes ou páginas terem sido construídos.

OpenDesign

Mantenha o briefing e o trabalho de design juntos.

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.

Baixar OpenDesignExplorar skills de design
Arquivo-fonte original
https://github.com/julianoczkowski/designer-skills/blob/c259656c76d9758d7ead46b0d2f125cbe84f8665/design-flow/SKILL.md