Como elaborar um Project Brief profissional com AIOX

Índice

1. Por que um Project Brief importa
2. O framework AIOX em 60 segundos
3. Conheça Atlas — o agente Analyst
4. Pré-requisitos
5. Passo a passo: do comando ao hand-off
6. As 12 seções do brief em detalhe
7. O protocolo 1-9 de elicitação avançada
8. Estudo de caso: UPLink, do zero ao brief final
9. Lições aprendidas e armadilhas comuns
10. O que vem depois do Brief
11. Comandos AIOX relacionados
12. Conclusão
13. Anexo A — Brief completo do UPLink (modelo)
14. Anexo B — Checklist do criador
15. Anexo C — FAQ

---

1. Por que um Project Brief importa

A maioria dos produtos digitais morrem na ambiguidade — não no código. Quando uma equipe começa a construir antes de alinhar problema, público, escopo e premissas, três coisas previsíveis acontecem:

1. Scope creep ("já que estamos aqui, vamos adicionar X").
2. Decisões técnicas mal-fundamentadas ("o backend que escolhemos não escala para o caso real").
3. Discussões circulares ("não foi isso que combinamos").

O Project Brief existe para neutralizar essas três falhas antes que custem semanas. É o documento que responde, com profundidade calibrada e em uma única tela mental:

"O que estamos construindo, para quem, por quê agora, com que restrições, e como sabemos que deu certo?"

Brief não é PRD, nem Architecture, nem One-Pager

Pular direto do "one-pager" para o PRD é a fonte mais comum de retrabalho. O Brief é o filtro estratégico entre intuição e execução.

💡 Insight: No AIOX, o Brief não é apenas um documento — é um artefato de cadeia que alimenta o PRD, que alimenta a Architecture, que alimenta as Stories, que alimentam o código. Quebrar essa cadeia gera fricção em cascata.

---

2. O framework AIOX em 60 segundos

AIOX (AI-Orchestrated System for Full Stack Development) é um meta-framework que orquestra agentes de IA especializados em diferentes papéis de um time de produto:

Cada agente tem comandos próprios (prefixo *), memória dedicada, e autoridade definida (ex: apenas @devops pode dar git push). O ciclo de desenvolvimento padrão é o Story Development Cycle (SDC):

@analyst → @pm → @po → @sm → @dev → @qa → @devops
   Brief    PRD   Validate Story  Code  Review  Ship

📌 Nota: AIOX é story-driven: nada vai para produção sem uma story validada, com critérios de aceitação testáveis. O Brief é o primeiro elo dessa corrente.

---

3. Conheça Atlas — o agente Analyst

Atlas é o @analyst do AIOX. Arquétipo: Decoder ♏ Scorpio. Estilo: analítico, inquisitivo, criativo, facilitador — não dono das decisões, mas dono do rigor com que elas são tomadas.

Quando usar Atlas:

• ✅ Pesquisa de mercado e competitive analysis
• ✅ Facilitação de brainstorming estruturado
• ✅ Criação de Project Brief (este artigo)
• ✅ User research planning, project discovery
• ✅ Geração de prompts para deep research

Quando NÃO usar Atlas:

• ❌ Escrever PRD → use @pm
• ❌ Criar stories → use @sm
• ❌ Decisões técnicas de arquitetura → use @architect

Princípios operacionais do Atlas:

1. Curiosity-Driven Inquiry — Pergunta "por quê" antes de responder "o quê".
2. Objective & Evidence-Based — Distingue fato, inferência e hipótese.
3. Numbered Options Protocol — Decisões via opções numeradas (1-9), nunca yes/no.
4. Detailed Rationale — Toda decisão é acompanhada de justificativa, trade-off e atenção.
5. Action-Oriented Outputs — Deliverables com próximos passos concretos.

---

4. Pré-requisitos

Antes de rodar *create-project-brief, garanta:

Ferramental

• Repositório AIOX inicializado (.aiox-core/ presente)
• Pasta docs/ existe (será criada automaticamente se não)
• Claude Code, Cursor, ou outra IDE compatível com Skills/Agents
• Permissões de escrita em docs/brief.md (output default)

Inputs ideais (não obrigatórios — Atlas constrói do zero se necessário)

• Resultados de brainstorming prévio (formal ou notas)
• Pesquisa de mercado já conduzida (mesmo que parcial)
• Análise competitiva preliminar
• Ideias iniciais documentadas (Notion, Linear, post-it)
• Conversas anteriores com stakeholders

Mindset

• Disponibilidade para 1 a 3 horas de trabalho focado (modo Interactive)
• Abertura para questionamentos não-óbvios (Atlas vai "stress-testar" premissas)
• Capacidade de responder com clareza estratégica — não com "vou decidir depois"

⚠️ Atenção: Se a resposta para "qual o problema que estamos resolvendo?" for "não sei direito ainda", rode *brainstorm primeiro — não force um brief sobre fundamento vazio.

---

5. Passo a passo: do comando ao hand-off

Step 1 — Ativar o agente Analyst

No Claude Code ou IDE compatível:

@analyst

ou via comando equivalente:

/AIOX:agents:analyst

Atlas se apresenta com:

🔍 Atlas the Decoder ready to investigate! [🟢 Auto]

Role: Insightful Analyst & Strategic Ideation Partner
Branch: master

📊 Project Status: ...

Available Commands:
1. *help — Mostra todos os comandos
2. *brainstorm {topic} — Facilita sessão estruturada
...

Step 2 — Disparar o comando

*create-project-brief

Atlas vai:

1. Carregar o template project-brief-tmpl.yaml (12 seções estruturadas).
2. Verificar inputs disponíveis (research prévia, brainstorms etc.).
3. Perguntar modo de execução.
4. Coletar 3 perguntas-âncora de contexto inicial.

Step 3 — Escolher o modo de execução

💡 Recomendação: Interactive Mode para o primeiro brief de um projeto. YOLO funciona melhor quando você já tem briefs anteriores como ancoragem.

Step 4 — Responder as 3 perguntas-âncora

Atlas faz três perguntas que estabelecem o ponto de partida:

1. Em uma frase: o que é o projeto?
2. Por quê agora? O que motiva começar este projeto neste momento?
3. Quem é o público-alvo (mesmo que ainda hipotético)?

Boas respostas têm 1-3 frases por pergunta. Atlas vai expandir, inferir e estressar essas respostas nas 12 seções seguintes.

Step 5 — Iterar pelas 12 seções

Para cada seção, Atlas:

1. Apresenta um draft proposto baseado no que sabe até o momento.
2. Anota o rationale em uma tabela de decisões (justificativa, trade-off, atenção).
3. Lista as suposições-chave que precisam ser validadas.
4. Apresenta o menu 1-9 (ver Seção 7 deste guia).
5. Espera sua resposta antes de avançar.

Quando você seleciona opção 1 ("Proceed to next section"), Atlas persiste a seção no arquivo docs/brief.md e avança.

Step 6 — Refinar com elicitação avançada (opcional)

Se a seção apresentada não estiver perfeita, escolha opções 2-9 para refinar:

• 2 — Mais especificidade
• 3 — Validar contra produtos similares
• 4 — Stress-test de premissas
• 5 — Explorar abordagens alternativas
• 6 — Trade-offs de recursos
• 7 — Estratégias de mitigação de risco
• 8 — Cortar para MVP mínimo
• 9 — Brainstorm de features criativas

Você também pode digitar feedback livre ("muda o tom para mais conservador", "amplia para mercado europeu", etc.).

Step 7 — Finalização & Change Log

Ao completar as 12 seções, Atlas:

1. Adiciona um Change Log ao final do brief.
2. Atualiza o header com status ✅ Draft finalizado (v1.0.0).
3. Apresenta um resumo da sessão (tabela com decisões-chave de cada seção).
4. Sugere os próximos comandos AIOX.

Step 8 — Hand-off para o próximo agente

O brief termina com uma seção PM Handoff explícita. Você pode:

• Validar com stakeholder (revisar inferências).
• Conduzir research adicional (*create-competitor-analysis, *perform-market-research).
• Resolver questões abertas críticas (priorizando as top 5 das 15 listadas).
• Iniciar PRD com @pm *create-doc prd.

---

6. As 12 seções do brief em detalhe

6.1 Executive Summary

Propósito: Captura a essência do projeto em ~150-250 palavras. Deve ser lida em 60 segundos por um stakeholder externo.

Componentes: Conceito (1-2 frases) · Problema · Público-alvo · Proposta de valor.

Sinais de qualidade:

• Uma única leitura responde "o que é, para quem, e por quê".
• Sem jargão impenetrável.
• Diferenciação clara em uma frase ("X para Y, com Z").

Armadilha: Tentar incluir todo o brief aqui — esta seção é uma sinopse, não um resumo executivo de 2 páginas.

---

6.2 Problem Statement

Propósito: Articular o problema com evidência e urgência.

Componentes: Estado atual · Impacto (quantificado quando possível) · Falhas de soluções existentes · Por quê agora.

Sinais de qualidade:

• Cada dor tem um portador claro (não é genérico).
• O custo da dor está dimensionado (mesmo que como estimativa direcional).
• Soluções existentes são citadas e suas falhas explicadas concretamente.

Armadilha: Confundir "problema do mercado" com "minha vontade de construir algo". Atlas vai sinalizar isso no rationale.

---

6.3 Proposed Solution

Propósito: Descrever a solução em alto nível, com diferenciação clara.

Componentes: Conceito central · Diferenciadores vs concorrentes · Tese de sucesso · Visão de produto.

Sinais de qualidade:

• Tabela comparativa explícita ajuda muito.
• Frase de elevador memorável ("X para Y, com a velocidade do Z").
• Tese de sucesso não é "porque vamos ser melhores" — é estrutural.

Armadilha: Vender features em vez de outcomes. Atlas força foco no valor entregue.

---

6.4 Target Users

Propósito: Definir e caracterizar os usuários com especificidade.

Componentes: Primary segment (obrigatório) · Secondary segment (opcional) · Demografia · Comportamento · Necessidades · Objetivos.

Sinais de qualidade:

• Persona específica ("Lucas, 32, dev SaaS solo em Curitiba") supera persona genérica ("o profissional").
• Comportamentos atuais documentados (canais usados, ferramentas atuais).
• Distinção clara entre primary e secondary.

Armadilha: Atender dois segmentos no MVP sem reconhecer o trade-off. Atlas sinaliza explicitamente quando há tensão estratégica.

---

6.5 Goals & Success Metrics

Propósito: Estabelecer SMART goals e KPIs mensuráveis.

Componentes: Business objectives · User success metrics · KPIs em tabela com targets.

Sinais de qualidade:

• Targets quantificados (não "muitos usuários" — "2.000 MAU em 12 meses").
• Activation Rate = valor entregue (não apenas "criar conta").
• KPIs incluem NFRs técnicas (P95 latency, lighthouse score).

Armadilha: Vanity metrics (downloads, signups) sem proxy de valor. Atlas pressiona por leading indicators de PMF.

---

6.6 MVP Scope

Propósito: Definir o menor produto viável que valida a tese.

Componentes: Core Features (Must Have) · Out of Scope (explícito) · MVP Success Criteria · Kill Criteria (recomendado).

Sinais de qualidade:

• Lista "Out of Scope" tem itens não-óbvios (sinaliza disciplina).
• Success Criteria são mensuráveis em 90 dias.
• Kill Criteria existem ("se MAU < 50 em 90 dias, revisitar positioning").

Armadilha: Inflar o MVP. Atlas pressiona via opção 8 ("Challenge from MVP minimalist view") quando detecta escopo excessivo.

---

6.7 Post-MVP Vision

Propósito: Mostrar opcionalidade sem comprometer prazo.

Componentes: Phase 2 features (3-6 meses) · Long-term vision (12-24 meses) · Expansion opportunities.

Sinais de qualidade:

• Phase 2 é monetização ou redução de fricção — não features especulativas.
• Long-term vision é uma tese estratégica, não uma lista de features.
• Expansion opportunities mostram caminhos de crescimento (geografia, vertical, modalidade).

Armadilha: Vision sprawl. Atlas pode forçar redução para 2-3 pilares-chave.

---

6.8 Technical Considerations

Propósito: Sinalizar direção técnica sem comprometer o @architect.

Componentes: Platform requirements · Technology preferences · Architecture considerations · Security/Compliance.

Sinais de qualidade:

• Marca explicitamente "sugestão, não decisão final".
• NFRs quantificadas (P95 < 1.2s, Lighthouse > 90).
• Compliance (LGPD/GDPR) tratada desde o brief, não como pós-pensamento.

Armadilha: Confundir Brief com Architecture Document. Atlas mantém o nível estratégico e preferencial, não prescritivo.

---

6.9 Constraints & Assumptions

Propósito: Explicitar limites e premissas.

Componentes: Budget · Timeline · Resources · Technical constraints · Key assumptions (em 5 grupos: mercado, comportamento, operacional, estratégico, técnico).

Sinais de qualidade:

• Premissas marcadas como "a validar" (não como verdade).
• Constraints incluem o que não vai ser feito (negative space).
• Trade-offs explícitos (ex: "vendor lock-in moderado vs velocidade indie").

Armadilha: Otimismo de premissas. Atlas força marcação explícita ("hipótese a validar com user research") em premissas frágeis.

---

6.10 Risks & Open Questions

Propósito: Antecipar o que pode dar errado e o que ainda não está decidido.

Componentes: Key Risks (classificados por severidade) · Open Questions (categorizadas) · Areas Needing Further Research.

Sinais de qualidade:

• Riscos classificados (🟥 crítico, 🟧 alto, 🟨 médio, 🟩 baixo) com impacto + probabilidade.
• Open questions organizadas por categoria (estratégicas, produto, técnicas, comerciais).
• Cada questão é respondível em um prazo definido.

Armadilha: Listar riscos sem mitigação ou sinal de prioridade. Atlas pode oferecer opção 7 ("Generate risk mitigation strategies") para aprofundar.

---

6.11 Appendices

Propósito: Documentar fontes, stakeholder input, e research summary.

Componentes: Research Summary · Stakeholder Input · References (concorrentes, ferramentas, comunidades).

Sinais de qualidade:

• Honestidade sobre status de research ("research primária ainda não conduzida" é melhor que research falsa).
• Inferências marcadas como inferências (não fatos).
• References são acionáveis (links concretos).

Armadilha: Inflar appendices com pesquisa "fake" para parecer rigoroso. Atlas registra estado real.

---

6.12 Next Steps

Propósito: Garantir continuidade — o brief não termina como artefato isolado.

Componentes: Immediate Actions (numerada, com prazos) · PM Handoff (instruções explícitas para o próximo agente).

Sinais de qualidade:

• Ações com owner e prazo.
• Handoff cita explicitamente o que não deve ser feito (manter foco no positioning, não permitir scope creep).
• Sugere comandos AIOX concretos para próximos passos.

Armadilha: "Vamos definir depois" — Atlas força clareza sobre qual é o próximo passo concreto.

---

7. O protocolo 1-9 de elicitação avançada

O AIOX impõe um padrão importante para workflows com elicit: true: nunca perguntas yes/no, sempre menu numerado de 1-9. Esse design tem três objetivos:

1. Forçar engajamento crítico (yes/no estimula automatismo; menu numerado obriga reflexão).
2. Expor o leque de movimentos possíveis (você não sabia que podia "stress-testar premissas" até ver a opção).
3. Preservar agência do humano (você pode sempre digitar feedback livre).

Estrutura padrão

1. Proceed to next section                          [sempre fixo]
2. Expand section with more specific details         [drill-down]
3. Validate against similar successful products     [benchmarking]
4. Stress test assumptions with edge cases          [critical thinking]
5. Explore alternative solution approaches          [lateral thinking]
6. Analyze resource/constraint trade-offs           [pragmatism]
7. Generate risk mitigation strategies              [risk-thinking]
8. Challenge scope from MVP minimalist view         [reducer]
9. Brainstorm creative feature possibilities        [generativo]

Select 1-9 or just type your question/feedback:

Quando usar cada opção

💡 Padrão observado: Em briefs de qualidade, há 2-4 seções refinadas com opções 2-9 e o resto avança com opção 1. Refinar tudo é over-engineering. Aceitar tudo é negligência.

---

8. Estudo de caso: UPLink, do zero ao brief final

📂 Brief completo: veja [Anexo A](#anexo-a--brief-completo-do UPlink-modelo) ao final deste guia. 📄 Arquivo original: docs/brief.md

8.1 Contexto inicial

Em 18 de maio de 2026, um profissional brasileiro que trabalha com desenvolvimento SaaS e projetos Web ativou o agente Atlas para estruturar a discovery de um novo projeto pessoal: um gerenciador de links inspirado no Linktree, com posicionamento ainda em aberto.

A sessão começou com o comando:

@analyst
*create-project-brief

8.2 As três perguntas-âncora

Atlas fez as três perguntas iniciais. As respostas do criador foram:

1) Em uma frase: o que é o projeto UPLink? O projeto é um aplicativo de gerenciamento de links, baseado no Linktree.

2) Por quê agora? O que motiva começar este projeto neste momento? Um projeto para integrar o portfólio pessoal de um profissional que trabalha com desenvolvimento de SaaS e projetos Web.

3) Quem é o público-alvo (mesmo que ainda hipotético)? Profissionais que desejam inserir links nas bios do Instagram ou como página de um site.

📌 Observação: As três respostas têm menos de 50 palavras combinadas. Atlas extraiu cinco inferências estratégicas delas:

1. Produto: SaaS público (não ferramenta interna).
2. Positioning candidato: nicho técnico (derivado de "portfólio profissional SaaS/Web").
3. Mercado: BR + global remoto (derivado do contexto).
4. Modelo: bootstrap solo (derivado da ausência de menção a time/investidores).
5. Tensão estratégica: positioning dual (técnico + Instagram-first) — sinalizada como risco a resolver.

8.3 Modo escolhido

O criador optou por Interactive Mode — a recomendação default. Isso significou:

• 12 checkpoints com menu 1-9.
• Persistência incremental no docs/brief.md ao aprovar cada seção.
• Rationale detalhado em cada decisão de Atlas.

8.4 Highlights de decisões por seção

8.5 Tempo total de sessão

Aproximadamente 90 minutos (modo Interactive, 12 seções, criador escolhendo opção 1 em todas — sem refinamentos via 2-9). Para refinar 3-4 seções via elicitação avançada, esperar 2-3 horas.

8.6 Outputs gerados

1. docs/brief.md — Brief completo, ~3.500 palavras, versão 1.0.0.
2. Change Log — Registrado no final do arquivo.
3. Próximos comandos sugeridos (no resumo final da sessão):
   • @analyst *create-competitor-analysis — análise dos 7 concorrentes listados.
   • @analyst *perform-market-research — TAM/SAM/SOM.
   • @analyst *research-prompt "..." — deep research em pontos específicos.

8.7 O que ficou explicitamente em aberto

O brief foi finalizado mantendo 15 questões abertas documentadas — não escondidas. Isso é deliberado:

"Um brief honesto sobre o que está em aberto é mais útil que um brief que finge resolver tudo." — princípio operacional do Atlas.

As questões foram categorizadas como estratégicas, produto, técnicas e comerciais. Cinco foram priorizadas como críticas para resolver antes do PRD.

---

9. Lições aprendidas e armadilhas comuns

O que funcionou bem no caso UPLink

1. Inputs mínimos foram suficientes. Três respostas curtas geraram um brief de 3.500 palavras coerente. O criador não precisou "pensar tudo de antemão".
2. Rationale explícito virou ferramenta de aprendizado. Toda decisão foi acompanhada de justificativa — o criador podia entender e contestar a lógica de Atlas.
3. Tensão estratégica foi sinalizada cedo. O positioning dual (técnico + Instagram-first) foi marcado como risco na Seção 1 e seguiu como tema recorrente, em vez de ser "escondido" no documento.
4. Honestidade sobre research pendente. O Appendix A não inventou dados — registrou claramente "research ainda não conduzida".
5. Kill criteria explícito. "Se MAU < 50 em 90 dias, revisitar" é disciplina indie hacker incorporada no brief.

Armadilhas a evitar

❌ Aceitar tudo via opção 1 mecanicamente. Pelo menos 2-3 seções merecem stress-test via opções 2-9. Brief sem nenhuma iteração é provavelmente raso.

❌ Confundir Brief com PRD. O Brief não define ACs, fluxos detalhados, ou wireframes. Se você está descrevendo botões e cores, está no documento errado.

❌ Inflar Technical Considerations. O Brief sinaliza preferências — o @architect decide. Travar stack no brief gera retrabalho.

❌ Pular Risks & Open Questions. Esta é a seção mais ignorada e a mais valiosa. Brief sem riscos é brief com viés de otimismo.

❌ Brief sem Kill Criteria. Sem critério explícito de "quando admitir que não funcionou", você vai escalar pelo viés de comprometimento.

❌ Ignorar handoff. O brief termina com PM Handoff por design. Pular essa seção quebra a cadeia AIOX.

Quando NÃO usar *create-project-brief

• Bug fix isolado — use @sm *create-story direto.
• Feature incremental em produto existente — use PRD shard ou story enrichment.
• Refatoração técnica pura — use @architect.
• Você ainda não sabe o problema — rode *brainstorm primeiro.

---

10. O que vem depois do Brief

O brief é o input do próximo elo da corrente AIOX. A sequência canônica é:

✅ Brief (você acabou de fazer)
   ↓
🔍 Research pipeline (recomendado antes do PRD)
   ├─ *create-competitor-analysis
   ├─ *perform-market-research
   └─ User interviews (manual)
   ↓
📋 PRD (@pm *create-doc prd)
   ↓
🏗️ Architecture (@architect *create-architecture)
   ↓
🎨 UX Specs (@ux-design-expert)
   ↓
✏️ Stories (@sm *create-story)
   ↓
✅ Validation (@po *validate-story-draft)
   ↓
💻 Implementation (@dev *develop-story)
   ↓
🧪 QA Gate (@qa *qa-gate)
   ↓
🚀 Push & Release (@devops *push)

Caminho mínimo (se você está com pressa)

1. Validar brief com stakeholder (1-2 dias).
2. Resolver as 3 questões abertas mais críticas.
3. Pular research formal e ir para PRD direto (risco maior, mas viável para projetos pessoais ou MVPs muito enxutos).

Caminho completo (recomendado para projetos sérios)

1. Conduzir competitor analysis (3-5 dias).
2. Conduzir market research (3-5 dias).
3. Conduzir 5-10 user interviews (2-3 semanas).
4. Resolver top 5 questões abertas.
5. Iniciar PRD.

---

11. Comandos AIOX relacionados

Todos os comandos requerem o agente correto ativado (@analyst, @pm, etc.) e o prefixo *.

Comandos do @analyst (Atlas)

Comandos relacionados (outros agentes)

---

12. Conclusão

Um Project Brief bem feito economiza semanas de retrabalho e previne discussões circulares sobre escopo. O AIOX entrega isso através de:

1. Template validado (12 seções cobrindo problema → premissas → próximos passos).
2. Agente especializado (Atlas, o @analyst) com princípios operacionais claros.
3. Modo Interativo com checkpoints obrigatórios — você não pode "passar batido" por seções críticas.
4. Protocolo 1-9 que força engajamento crítico em vez de aprovação automática.
5. Rationale explícito em toda decisão — você sempre sabe por quê algo foi proposto.
6. Hand-off rastreável ao próximo agente, mantendo a cadeia coerente.

O caso UPLink demonstra que três respostas curtas ao input inicial podem gerar um documento estratégico denso de 3.500+ palavras, com decisões fundamentadas, riscos mapeados, e próximos passos acionáveis — em ~90 minutos de trabalho focado.

Próximo passo prático

Se você está começando um projeto novo:

@analyst
*create-project-brief

Se você quer ver o resultado final antes de começar:

👉 Veja o Anexo A abaixo.

---

Anexo A — Brief completo do UPLink (modelo)

Este é o brief gerado na sessão de estudo de caso, integralmente reproduzido como modelo de referência. Arquivo original: docs/brief.md

---

Project Brief: UPLink

Status: ✅ Draft finalizado (v1.0.0) Owner: Atlas (@analyst) Última atualização: 2026-05-18 Próximo passo: Validar com stakeholder → conduzir research → handoff para @pm

---

Executive Summary

UPLink é um aplicativo SaaS de gerenciamento de links que permite a profissionais centralizar múltiplos endereços (redes sociais, portfólio, projetos, contatos) em uma única página personalizável, otimizada para ser usada como link na bio do Instagram ou como landing page autônoma. Inspirado em soluções como Linktree e Beacons, mas posicionado para profissionais de tecnologia (desenvolvedores SaaS, criadores web) que precisam exibir portfólio + canais de contato + projetos ativos em um hub coeso, com identidade visual própria.

Problema: Profissionais técnicos hoje espalham sua presença digital entre Instagram, LinkedIn, GitHub, portfólio próprio, contatos comerciais — sem um ponto unificado que seja editável rapidamente, com analytics, e que represente identidade profissional (não apenas creator/influencer).

Público-alvo: Profissionais que trabalham com desenvolvimento SaaS e projetos Web, criadores técnicos, freelancers, e usuários gerais do Instagram que querem uma página de bio editorial.

Proposta de valor: Hub único, customizável e profissional, que serve tanto como link na bio quanto como página standalone de portfólio — com edição rápida, analytics e identidade visual personalizada.

---

Problem Statement

Estado atual & pontos de dor: Profissionais que precisam direcionar tráfego de redes sociais (em especial Instagram, que permite apenas 1 link na bio) enfrentam um problema operacional clássico: a internet é multi-destino, mas a bio é mono-link. Hoje, eles dependem de soluções genéricas (Linktree, Beacons, Lnk.bio), páginas estáticas próprias (Carrd, HTML manual), ou não usam nada — perdendo conversão e profissionalismo.

Para o profissional técnico (dev SaaS, criador web), a dor é mais aguda: ele tem múltiplos artefatos vivos (repos no GitHub, projetos em produção, portfólio Behance/Dribbble, blog técnico, perfis de freelance, contatos comerciais) que mudam frequentemente.

Impacto: conversão perdida (30-50% drop-off em redirects intermediários — hipótese a validar), identidade fragmentada, custo de oportunidade por falta de analytics centralizados.

Por que soluções existentes falham: Linktree/Beacons otimizadas para creators; Carrd sem analytics; GitHub Pages voltadas a recruiters tech, não para bio de Instagram.

Urgência: Mercado creator economy + freelancers técnicos em crescimento; Instagram continua central para personal branding técnico; janela competitiva aberta no nicho técnico.

---

Proposed Solution

Conceito central: UPLink é uma plataforma SaaS de hubs de link profissionais. Cada usuário cria uma página única (ex: UPlink.app/joaodev) — otimizada para link na bio do Instagram, mas funcional como portfolio standalone.

Três pilares:

1. Editor opinionado para profissionais técnicos — project cards, GitHub embeds, service offerings, contact strip.
2. Identidade visual customizável sem sacrificar velocidade — 80% do resultado profissional em 5 minutos.
3. Analytics acionáveis — "seus posts no Instagram convertem 3x mais que LinkedIn na sua bio".

Diferenciadores vs concorrentes:

Por que vai dar certo: Nicho mal-atendido + CAC baixo no nicho + diferenciação opinionada.

Visão de produto: "Um Linktree para devs, com a velocidade do Carrd, a inteligência analítica do Plausible, e a opinião de design de um sistema moderno (shadcn/ui-grade)."

---

Target Users

Primary — Profissional Técnico Solo (Dev SaaS / Criador Web):

• 25-40 anos · Brasil + remoto global · Renda USD 3-10k/mês.
• Mantém presença em 3-4 plataformas (GitHub, LinkedIn, Twitter/X, Instagram, portfólio próprio).
• Necessidades: hub unificado, edição rápida, analytics que informem decisão, URL profissional curta, integrações nativas (GitHub, Cal.com, Stripe).
• Objetivo: ser encontrado por clientes/recruiters; construir personal brand técnica.

Secondary — Usuário Geral Profissionalizante (Instagram-First):

• 20-45 anos · Brasil first · Renda BRL 2-15k/mês.
• Diversa: fotógrafos, coaches, consultores, profissionais liberais.
• Usa Instagram como canal principal; precisa direcionar para múltiplos destinos.
• Sensível a preço; valoriza simplicidade + aparência profissional.

---

Goals & Success Metrics

Business Objectives: 500 MAU em 6 meses · USD 1.5k MRR em 9 meses · 1 menção orgânica relevante em 90 dias · CAC < USD 5 · operação solo até USD 5k MRR.

User Success Metrics: Tempo até primeira publish < 5 min · Edições 2+/mês · 3+ blocos por usuário ativo · NPS > 40 · 60% de uso mensal do dashboard de analytics.

KPIs (12 meses):

---

MVP Scope

Core Features: Auth (magic-link + GitHub OAuth) · Username único + URL pública · Editor visual single-page · 6 blocos essenciais (Link Card, Project Card, GitHub Embed, Social Strip, Contact Block, Heading/Divider) · 3 temas opinionados (Dark Minimal, Light Editorial, Brutalist) · Customização de tema · Analytics MVP · Publish/unpublish · SEO básico · Free tier completo.

Out of Scope (MVP): Domínio custom (Pro), brand removal (Pro), multi-página, multi-user, e-commerce blocks, email capture, A/B testing, templates marketplace, AI features, i18n completo, mobile nativo.

MVP Success Criteria (90 dias): Activation ≥ 60% · MAU ≥ 100 · WAU/MAU ≥ 25% · Retention D30 ≥ 30% · NPS ≥ 30 · P95 < 1.2s · zero downtime > 30min.

Kill Criteria: MAU < 50 OR Activation < 30% em 90 dias → revisitar positioning.

---

Post-MVP Vision

Phase 2 (3-6 meses pós-MVP): Plano Pro (paywall com domínio custom, brand removal, analytics avançado, blocos premium, verified badge) · Multi-página por conta · Templates marketplace curado · GitHub avançado · Integrações com Read.cv/Polywork/dev.to · Onboarding guiado · i18n (PT/EN/ES).

Long-term Vision (12-24 meses): UPLink como hub canônico de identidade profissional técnica — 5 pilares: identidade unificada, network effect via diretório opt-in, camada de transação (Stripe Connect), API & extensibilidade, mobile/edge global.

Expansion: Agências B2B small · Educadores técnicos · Open-source maintainers · LATAM e Europa indie · Self-hosted/open-core · potencial aquisição.

---

Technical Considerations

⚠️ Sugestões iniciais — decisões finais com @architect.

Platform: Web (desktop + mobile responsive) · PWA-friendly · sem app nativo no MVP · navegadores evergreen.

Performance Requirements: P95 page-load < 1.2s · P95 TTFB < 300ms · Edit-to-publish < 2s · Lighthouse mobile > 90.

Stack sugerido:

• Frontend: Next.js 14+ (App Router) ou Remix · TypeScript · shadcn/ui + Tailwind · dnd-kit.
• Backend: API Routes (Next.js) · tRPC ou REST com Zod.
• Database: PostgreSQL (Supabase ou Neon) · Prisma ou Drizzle · Redis (Upstash).
• Hosting: Vercel · Cloudflare (DNS/CDN) · R2 ou S3 · Resend · Plausible/PostHog.

Architecture: Monolito modular no MVP · feature-based organization · ISR para páginas públicas.

Security/Compliance: OWASP Top 10 baseline · LGPD/GDPR-ready · magic-link auth segura · defesa contra abuso (rate-limit, captcha invisível, validação anti-phishing) · moderação de slugs reservados · backups diários com PITR.

---

Constraints & Assumptions

Constraints:

• Budget: ≤ USD 100/mês infra · ≤ USD 50/mês marketing pago durante MVP.
• Timeline: 10-14 semanas, dedicação parcial 15-25h/sem · marcos semanais explícitos.
• Resources: 1 dev full-stack solo · sem designer, QA, DevOps, PM dedicados.
• Technical: Stack indie-friendly · sem suporte legacy · sem multi-region · sem app nativo · sem IA generativa pesada · limites no free tier (50 blocos, 5MB uploads, 100 clicks/dia inicial).

Key Assumptions (em 5 grupos):

• Mercado: TAM ≥ 5k profissionais técnicos · willingness USD 5-9/mês.
• Comportamento: devs usam Instagram com frequência · activation 60% atingível · word-of-mouth técnico entrega volume.
• Operacional: solo dev viável até USD 5k MRR · infra escala linearmente · beta privado valida.
• Estratégico: Linktree não pivota para tech em 12 meses · APIs estáveis · regulação estável.
• Técnico: ISR + edge entregam P95 < 1.2s · GitHub API pública suficiente · magic-link sem fricção excessiva.

---

Risks & Open Questions

Riscos críticos (🟥): TAM real do nicho · willingness-to-pay mais baixa · Linktree/Beacons reagem ao positioning.

Riscos altos (🟧): Solo dev burnout · abuso de plataforma (phishing/spam) · custo de infra em viralização.

Riscos médios (🟨): Dependência de APIs de terceiros · compliance LGPD/GDPR mal-implementada · conflito de positioning dual.

Riscos baixos (🟩): Domínio UPlink.app indisponível · Instagram liberar múltiplos links na bio.

Open Questions (15 categorizadas):

• Estratégicas: foco único vs dual, free tier restritivo vs generoso, paywall ativo no MVP, open-source/self-hosted.
• Produto: 2 blocos prioritários, GitHub sync real-time vs manual, onboarding obrigatório, múltiplas páginas por conta no MVP.
• Técnicas: Next.js vs Remix vs SvelteKit, Supabase vs Neon, JSONB vs tabelas por tipo, moderação de URLs.
• Comerciais: ordem de canais de lançamento, modelo de pricing final, política de suporte.

Areas needing further research: User interviews · competitor analysis profunda · market research quantitativa · POC técnico ISR · análise legal/compliance · benchmark pricing indie SaaS · estudo de canais de aquisição.

---

Appendices

A. Research Summary: ⚠️ Research primária ainda não conduzida — inferências baseadas em conhecimento de mercado. Pendente antes do PRD: *perform-market-research, *create-competitor-analysis, user interviews, deep research, benchmark de pricing.

Hipóteses-chave que dependem de research: TAM ≥ 5k · willingness USD 5-9 · Linktree não pivota · Activation 60% atingível · word-of-mouth entrega · conversão 3%.

B. Stakeholder Input: Criador/owner do projeto (profissional SaaS/Web). Input direto: 3 respostas iniciais. Inferências do Atlas (a validar): positioning nicho técnico, operação solo bootstrap, mercado BR + global remoto.

C. References: Concorrentes (Linktree, Beacons, Bento, Carrd, About.me, Lnk.bio, Read.cv) · UX (shadcn/ui, Plausible, Cal.com, Vercel) · Frameworks (Next.js, Supabase, Cloudflare, Resend, Drizzle, Prisma) · Comunidades (Product Hunt, Hacker News, dev.to, Hashnode, r/indiehackers, r/SaaS, Indie Hackers).

---

Next Steps

Immediate Actions (8 ações com prazos):

1. Validar inferências com stakeholder (1-2 dias).
2. Conduzir competitor analysis com @analyst (3-5 dias).
3. Conduzir market research com @analyst (3-5 dias).
4. Conduzir 5-10 user interviews (2-3 semanas).
5. Verificar disponibilidade de domínio UPlink.app (15 min).
6. Resolver top 5 questões abertas críticas.
7. Handoff para @pm para criação do PRD.
8. (Opcional, paralelo) POC técnico do editor + ISR rendering.

PM Handoff: Validar inferências · priorizar research dependencies · resolver questões abertas críticas · manter foco no nicho técnico · disciplina sobre MVP scope · kill criteria explícito no PRD.

Cadência sugerida: confirmar brief → research → decisões críticas → iniciar PRD via *create-doc prd.

---

Change Log

---

Anexo B — Checklist do criador

Use este checklist antes de invocar *create-project-brief e durante a sessão.

Pré-sessão

• Tenho clareza sobre o problema a ser resolvido (mesmo que ainda hipotético)?
• Sei quem é o público-alvo (mesmo que generalista)?
• Existe motivação concreta para começar agora (não daqui a 6 meses)?
• Tenho 90 minutos disponíveis sem interrupção?
• Repositório AIOX está inicializado e docs/ existe (ou pode ser criado)?

Durante a sessão

• Respondi as 3 perguntas-âncora com 1-3 frases cada?
• Escolhi modo Interactive (default recomendado)?
• Em pelo menos 2-3 seções, usei opções 2-9 para refinar?
• Validei premissas-chave (Risks & Open Questions)?
• Defini um kill criteria explícito no MVP Scope?
• Marquei premissas frágeis como "a validar"?
• Aceitei explicitamente o handoff ao próximo agente?

Pós-sessão

• Revisei o docs/brief.md gerado de ponta a ponta?
• Validei inferências do Atlas com stakeholders reais?
• Priorizei top 5 questões abertas críticas?
• Planejei a research adicional necessária antes do PRD?
• Comuniquei status do brief ao time (se houver)?

---

Anexo C — FAQ

O que acontece se eu sair no meio da sessão?

O brief é persistido incrementalmente a cada seção aprovada (opção 1). Você pode sair a qualquer momento e retomar — o docs/brief.md reflete o estado até a última seção persistida. Para continuar, basta ativar @analyst novamente e pedir para retomar a partir da próxima seção.

Posso usar *create-project-brief em um projeto existente (brownfield)?

Tecnicamente sim, mas o uso ideal é greenfield. Para projetos legados, use:

• *brainstorm se está repensando direção estratégica.
• @architect com o workflow Brownfield Discovery se precisa de assessment técnico.
• O brief pode então ser elaborado para uma iniciativa específica dentro do projeto (não para o projeto inteiro).

Como Atlas decide o que inferir e o que perguntar?

Atlas opera por três regras:

1. Inferência conservadora: Se há ambiguidade alta, prefere registrar como "a validar" em vez de inventar.
2. Sinalização explícita: Toda inferência aparece na seção Appendices/Stakeholder Input como "inferência do Atlas".
3. Stress-test via opções 2-9: Sempre oferece caminhos de refinamento — você decide o nível de profundidade.

O brief é versionado?

Sim, via Change Log no final do documento. Cada revisão substantiva gera uma nova versão (1.0.0 → 1.1.0 para refinamentos; 2.0.0 para mudança de positioning). O git commit complementa a rastreabilidade.

Posso modificar o template project-brief-tmpl.yaml?

O template fica em .aiox-core/product/templates/project-brief-tmpl.yaml (camada L2 — Framework Templates). Por convenção do AIOX, templates do framework são extend-only — modificações sobrescrevem boas práticas validadas. Para customização, prefira criar um template derivado em .aiox-core/data/templates/ (camada L3).

Quanto tempo demora um brief no modo YOLO vs Interactive?

O brief é suficiente para começar a codar?

Não. O brief é input do PRD, não substituto. Pular do brief direto para código é receita para retrabalho. A sequência mínima é:

Brief → PRD → Architecture (high-level) → Stories → Código

Em projetos muito enxutos (solo dev, prova de conceito), pode-se acelerar combinando PRD + Architecture em um documento mais leve, mas as acceptance criteria explícitas das stories são não-negociáveis para qualquer código que vai a produção.

E se eu discordar do que Atlas propõe?

Use opções 4 (stress-test), 5 (alternativas), ou digite feedback livre no menu 1-9. Atlas é facilitador, não decisor. Você sempre tem agência. Se discorda fundamentalmente da direção, considere rodar *brainstorm para repensar antes de continuar o brief.

---

🔍 — Atlas, investigando a verdade

Se este guia te ajudou, considere compartilhar e/ou contribuir com melhorias via PR no repositório AIOX.

---

Tags: aiox · project-brief · product-discovery · analyst-agent · methodology · case-study · biolink · saas · link-in-bio