ralvarez-ai/website-concept-architect

Website Concept Architect

Design conceitual pré-código para sites pessoais, portfólios e landing pages. Esta skill produz direção, não markup. A entrega é um pequeno conjunto de documentos conceituais distintos para o usuário escolher; o escolhido alimenta o ui-ux-architect para implementação.

Quando usar

O usuário está iniciando um novo site e quer decidir o que ele é antes de escrever código. Não é para reformulações de sites em funcionamento, a menos que o briefing seja "repensar do zero". Não é para decisões de UI em nível de componente — essas pertencem ao ui-ux-architect.

1. Princípio operacional — caminhe, não despeje

Execute as seis etapas interativamente, uma de cada vez. Após cada etapa, apresente o menu, pause, aguarde a escolha do usuário e avance. Nunca colapse várias etapas em uma única pergunta. Nunca pule etapas, mesmo que o usuário forneça informações voluntariamente — exiba o que ele disse como uma opção pré-selecionada e confirme.

O objetivo da caminhada é forçar decisões que o usuário, de outra forma, adiaria. Pular uma etapa significa um documento conceitual vago mais tarde.

2. As seis etapas

#	Etapa	Propósito	Saída
1	Propósito	Para que serve o site?	1-2 escolhas da lista de arquétipos
2	Público	Quem lê?	1-2 escolhas, define tom e densidade
3	Inventário de conteúdo	O que vive nele?	Menu de seções marcadas
4	Tom e personalidade	Como ele se sente?	2-3 adjetivos de uma lista curada
5	Direção visual	Como ele se parece?	1 arquétipo (sugestões ranqueadas, lista completa exibida)
6	Síntese	Documentos conceituais	2-3 direções conceituais distintas + wireframe ASCII

3. Etapa 1 — Propósito

Apresente estes arquétipos. O usuário escolhe 1-2 (combináveis, ex. portfólio + hub de escrita):

• Portfólio / vitrine — artefatos de trabalho são o ponto; projetos são a espinha dorsal da AI.
• Hub de escrita — ensaios / blog / anotações são a espinha dorsal; todo o resto é navegação.
• Cartão de visita profissional — página única ou quase única; recrutadores / clientes chegam, conhecem, contatam.
• Jardim digital — anotações perenes interligadas; a estrutura é a rede, não a cronologia.
• Lançador de projetos — um produto ou projeto específico é o herói; "sobre mim" é uma nota de rodapé.
• Playground experimental — o site em si é um artefato criativo; a convenção é a inimiga.

Se o usuário escolher 2 arquétipos incompatíveis (ex. playground experimental + cartão de visita profissional), sinalize e pergunte qual vence na página inicial — o perdedor vira uma subseção.

4. Etapa 2 — Público

As escolhas moldam quanta explicação as coisas precisam e qual voz se encaixa.

• Recrutadores / clientes — leitura rápida, credenciais primeiro, baixo jargão, contato óbvio.
• Colegas devs / pares — assume vocabulário compartilhado, tolera densidade, exemplos de código funcionam.
• Amigos / comunidade — informal, personalidade em primeiro lugar, piadas internas OK.
• Seu-eu do futuro / arquivo — construído para pesquisar o próprio passado, densidade sobre polimento.
• A web aberta — visitante genérico, deve se autoexplicar, SEO importa.

Público múltiplo é normal. Se escolherem 3+, pergunte para qual a página inicial é otimizada — os demais são acomodados em subpáginas.

5. Etapa 3 — Inventário de conteúdo

Apresente este menu. O usuário marca o que deseja; ofereça para adicionar itens personalizados.

Seções padrão:

• Sobre / bio
• Página "Agora" (no que você está focado agora)
• Índice de projetos
• Estudos de caso individuais de projetos
• Ensaios / blog / escrita
• Anotações / jardim digital / wiki
• Lista de leitura / estante
• Página "Usos" (ferramentas, hardware, configuração)
• Currículo / CV (ou link para PDF)
• Contato (email, redes sociais, formulário)
• Inscrição na newsletter
• Feed RSS / Atom
• Changelog (do site ou atualizações da vida)
• Galeria de fotos
• Palestras / podcasts / aparições
• Livro de visitas / webring (estética retro-web)

Para cada seção marcada, faça uma pergunta de acompanhamento: isso já existe? Seções sem conteúdo são marcadas como [adiado] no documento conceitual para que o usuário não publique páginas vazias.

6. Etapa 4 — Tom e personalidade

Escolha 2-3 adjetivos. Eles ancoram as sugestões visuais da etapa 5 e a voz do texto na etapa 6.

Apresente como pares opostos para que as escolhas forem tradeoffs:

• mínimo ↔ denso
• lúdico ↔ sério
• acolhedor ↔ clínico
• cru ↔ polido
• íntimo ↔ público
• experimental ↔ convencional
• rápido / escaneável ↔ contemplativo / longo
• confiante ↔ autodepreciativo

Um usuário que escolher mínimo + lúdico + acolhedor recebe sugestões muito diferentes de denso + sério + clínico. Registre as escolhas ipsis litteris — elas vão para o documento conceitual como o briefing.

7. Etapa 5 — Direção visual

Oito arquétipos. Classifique os 3 primeiros por adequação com base nas etapas 1-4, mas mostre a lista completa para que o usuário possa substituir.

Arquétipo	Sensação	Adequado quando as etapas 1-4 dizem...	Sites de referência
Terminal / CLI	monoespaçado, esparso, linha de comando	público dev, minimalista, cru, arquivo	sive.rs, wiki.nikiv.dev, ratfactor.com
Editorial / Suíço	tipografia forte, grade, espaçamento generoso	polido, sério, cartão de visita profissional	rauno.me, paco.me, linear.app
Brutalista	HTML cru, estilos padrão, sem cromados	experimental, cru, íntimo, público dev	brutalist-web.design, motherfuckingwebsite.com
Zine / maximalista	colagem, fontes misturadas, texturas em camadas	lúdico, experimental, público comunidade	cassie.codes, lynnandtonic.com
Portfólio minimalista	coluna única, imagens grandes, bastante espaçamento	portfólio, polido, recrutadores/clientes	muitos portfólios de designers
Caderno / jardim	estilo wiki, interligações densas, perene	jardim digital, público arquivo, denso	gwern.net, andymatuschak.org
Revista / história	narrativa de rolagem longa, direcionada artisticamente, imagens heróicas	lançador de projetos, contemplativo, web aberta	grandes reportagens da Pitchfork, features do The Verge
Banco de dados / índice	tabela filtrável, quase uma UI	denso, arquivo, muitos artefatos	perfis do are.na, diretório /now do Derek Sivers

Mostre a classificação com uma frase de justificativa por escolha, ex.: "Terminal/CLI se encaixa porque você escolheu público dev + minimalista + cru." O usuário escolhe um; se substituir a classificação, pergunte o motivo e registre (a substituição geralmente revela uma restrição não identificada antes).

8. Etapa 6 — Síntese

Produza 2-3 direções conceituais distintas, não apenas uma. Mesmo que o usuário já tenha decidido, alternativas expõem o que ele está sacrificando.

Forma do documento conceitual

Para cada direção, escreva um documento markdown com estas seções:

# Conceito: <nome>

## Pitch de uma linha
<o site em 15 palavras ou menos>

## Briefing
- Propósito: <escolhas da etapa 1>
- Público: <escolhas da etapa 2, primário primeiro>
- Tom: <adjetivos da etapa 3>
- Arquétipo visual: <escolha da etapa 5>

## Arquitetura da informação
<árvore de páginas/seções, no máximo 2 níveis de profundidade>

## Estratégia da página inicial
<o que a página inicial faz em 2-3 frases — primeira impressão, ação principal, o que o visitante sabe ao sair>

## Amostra de voz do texto
<2-3 frases na voz escolhida — abertura da seção "Sobre" ou tagline + subtítulo da página inicial>

## O que este conceito sacrifica
<lista honesta do que é despriorizado em relação aos outros conceitos — todo conceito troca algo>

## Wireframe ASCII da página inicial
<ver §9>

As três direções devem diferir em um eixo real, não serem variantes cosméticas:

• Conceito A = a leitura óbvia das escolhas do usuário
• Conceito B = otimiza mais para o público primário (geralmente mais minimalista)
• Conceito C = um alongamento deliberado — e se o dial experimental fosse mais um passo?

Se dois dos três ficarem quase idênticos, descarte um e explique o motivo.

9. Wireframe ASCII da página inicial

Um por conceito. Mantenha com 80 colunas de largura, rotule regiões com [COLCHETES]. Mostre hierarquia com caracteres de desenho de caixa ou traços simples.

Exemplo para um portfólio terminal/CLI:

+------------------------------------------------------------------------------+
| ~ example.dev                                            [agora] [escrita] [/] |
+------------------------------------------------------------------------------+
|                                                                              |
|  jane doe                                                                    |
|  desenvolvedora backend · ferramentas · CLIs de código aberto               |
|                                                                              |
|  > atualmente construindo uma pequena ferramenta de cache de build em Go    |
|                                                                              |
|  --- recentes --------------------------------------------------------       |
|  2026-05-18  lançado: cachetool v0.3                                        |
|  2026-05-02  ensaio:   por que mantenho minhas ferramentas em um repositório |
|  2026-04-21  projeto:  internals do cache de build                          |
|                                                                              |
|  --- projetos --------------------------------------------------------       |
|  cachetool           cache de build incremental               [→]            |
|  notas               pequenos escritos sobre ferramentas      [→]            |
|                                                                              |
+------------------------------------------------------------------------------+
| email · github · rss                                                         |
+------------------------------------------------------------------------------+

Wireframes são sobre proporção e hierarquia, não layout pixel. Sem cores, sem fontes, sem ícones além de ASCII. Se uma seção precisar de explicação, adicione uma nota de uma linha abaixo do wireframe, não dentro dele.

10. Antipadrões

• Pular etapas porque "o usuário já disse". Exiba a contribuição deles como padrão e confirme; não presuma. Metade do valor está em forçar o usuário a olhar para o que ele não disse.
• Um documento conceitual em vez de 2-3. Alternativas são como o usuário entende o que está escolhendo. Saída com um único conceito é uma execução falha.
• Arquétipo visual antes do tom estar definido. A ordem das etapas importa — o visual é downstream do propósito/público/tom, não paralelo.
• Preencher conteúdo para seções [adiado]. Se o usuário não escreveu os ensaios, não invente listas de tópicos — o documento conceitual se compromete com estrutura, não conteúdo.
• Wireframes com detalhes de implementação. Nada de "use shadcn Card aqui" — esse é o trabalho do ui-ux-architect. Wireframes mostram o que vai onde.
• Sugestões genéricas. "Um portfólio moderno e limpo" não é um conceito. Todo documento conceitual deve se comprometer com escolhas específicas em todos os eixos.

11. Passagem de bastão

Assim que o usuário escolher um dos 2-3 conceitos, o documento conceitual é o briefing para:

• ui-ux-architect — para tokens, componentes, acessibilidade, os quatro estados obrigatórios.
• A skill frontend-design integrada — para o código real se for para produção.

O documento conceitual deve ser salvo no repositório do projeto (ex.: docs/concept.md) para que sobreviva como a justificativa do design.

12. Conexões entre skills

• ui-ux-architect — padrões de nível de implementação; esta skill fornece o briefing.
• demo-presentation-architect — estrutura interativa de passo a passo semelhante, domínio diferente.
• demo-script-architect — princípios narrativos (público primeiro, revelação progressiva) se aplicam também ao texto da página inicial.