hackathon: escopo muito amplo/genérico (7 skills administrativas) vs. concorrentes com um workflow único e afiado #13

Contexto

O kickoff do hackathon (transcrição Plow Hackathon Kickoff - 2026_09_09, ~00:12:50) é explícito sobre o critério usado na fase de julgamento humano, após o corte pelo leaderboard:

"you're not creating an agent that everyone is building. So you're not building just a calendar managing... is this different? Is this solving a real problem? Is this not just someone building an agent that is gaming the system to get top one?"

O próprio HACKATHON_COMPLIANCE.md já presente neste repositório registra esse risco, citando a pesquisa CBL que fundamentou o projeto:

"The supplied research explicitly warns that broad integrations such as universal email, Figma API/MCP, and App Store deployment can become too complex for a short hackathon... the repository should converge on one concrete workflow first."

Apesar desse alerta já documentado internamente, o agente hoje expõe publicamente 7 skills administrativas genéricas em paralelo (pesquisa de mercado, documentos, Figma, GitHub ops, e-mail, organização de arquivos, automação), sem que nenhuma delas seja destacada como o workflow principal/diferencial do projeto. O README atual apresenta as 7 como uma tabela de capacidades equivalentes, sem hierarquia.

Comparando com a proposta de valor dos 3 primeiros colocados do leaderboard — cada um resume seu agente em uma única frase muito específica, de ponta a ponta:

• Founder Agent: "Sentry issue → investigação → PR testado e revisável" — um workflow fim-a-fim com evidência quantificada (410 testes, 86 arquivos, PR #47 real).
• Zoen: "texte uma ideia → aplicativo funcional (código + vídeo do produto pronto)".
• Prucê: "vida acadêmica caótica → loops abertos priorizados, seguidos até o fechamento real".

Nenhum desses três se apresenta como um "assistente administrativo geral" — todos têm um workflow único, nomeável em uma frase, com resultado tangível. O nosso agente, em contraste, se posiciona como uma plataforma de 7 capacidades — o padrão que o próprio kickoff cita como o que tende a não se diferenciar na avaliação humana.

Isso é uma questão estrutural de posicionamento de produto para a submissão do hackathon, não um bug de código — por isso está sendo aberta como issue própria, separada das issues técnicas de reporter de uso e casos de uso publicados.

Proposta

1. Escolher, junto com o Rodrigo, UM workflow fim-a-fim como "carro-chefe" da submissão do hackathon. Candidato natural pelo uso real já registrado: o pipeline de pesquisa de mercado/netnografia (web-research) → dossiê estruturado em Markdown com fontes, que é a skill com mais evidência de uso real e maturidade até o momento (ver os dossiês Netnografia-Artist-Alleys-Feiras.md, Netnografia-Apple-Lineup-2026.md já produzidos).
2. Reescrever a descrição pública do agente no Agent Index (aiworthusing.com/agent-index/product-developer-assistant) para comunicar esse workflow específico em uma frase objetiva, no padrão dos concorrentes, em vez da lista atual de 7 capacidades.
3. Reestruturar a seção de topo do README para apresentar esse workflow principal primeiro, com as demais 6 skills reposicionadas como "capacidades adicionais" — não removidas, apenas despriorizadas visualmente.
4. Usar esse workflow único como o caso de uso central do vídeo demo e do docs/USE_CASES.md (ver issue de casos de uso).

Critério de aceite

• A descrição pública do agente (Agent Index + primeira dobra do README) comunica um problema específico e concreto resolvido de ponta a ponta em uma frase, no mesmo padrão dos 3 primeiros colocados do leaderboard.
• As demais skills continuam documentadas e funcionais, porém claramente subordinadas ao workflow principal na apresentação do projeto.
• O vídeo demo e o primeiro caso de uso do docs/USE_CASES.md demonstram esse workflow escolhido.