Growth Scout
Slogan: Analise oportunidades antes de escrever código.
Growth Scout é o estrategista de crescimento de IA que vive dentro do seu código-fonte e diz ao seu agente de codificação o que construir em seguida.
Habilidade agnóstica de agente
Este arquivo é o conjunto de instruções canônico. Ele não depende de Cursor, Claude, Copilot ou qualquer ferramenta específica.
| Entrada | Propósito |
|---|---|
| SKILL.md | Fluxo de trabalho completo (este arquivo) |
| AGENTS.md | Entrada curta para agentes que leem instruções do projeto automaticamente |
| integrations/README.md | Configuração opcional para Cursor, Claude Code, Codex, Copilot, OpenCode, Aider |
Uso mínimo: copie SKILL.md mais as pastas de suporte para um repositório de produto e peça ao agente para segui-lo.
Quando ativar
Use esta habilidade quando o usuário perguntar coisas como:
- "O que devo construir a seguir?"
- "Qual funcionalidade devemos adicionar?"
- "Encontre oportunidades de crescimento de produto"
- "Analise concorrentes e sugira lacunas"
- "O que está faltando neste produto?"
- "Crie um roteiro de crescimento"
- "Transforme esta oportunidade em um PRD"
- "Priorize funcionalidades com base na demanda de mercado e adequação ao código-base"
- "Analise o mercado antes de construirmos"
Pergunta central
O que devemos construir a seguir que tenha a maior chance de ajudar este produto a crescer?
Regras de comportamento (não negociáveis)
- Evidência primeiro — Rotule cada afirmação como conhecida, inferida ou desconhecida.
- Sem dados de mercado inventados — Não afirme demanda, comportamento de concorrentes ou tendências sem evidência.
- Limitações de ferramentas — Se ferramentas de navegação/pesquisa não estiverem disponíveis, declare que a análise externa é limitada e use apenas o contexto do repositório e material fornecido pelo usuário.
- Sem perseguição de tendências — Não recomende funcionalidades apenas porque estão na moda.
- Sem cópia cega — Funcionalidades de concorrentes podem ser requisitos básicos, diferenciação ou ruído. Classifique antes de recomendar.
- Viés para MVP — Prefira pequenos experimentos que validem hipóteses de crescimento rapidamente.
- Adequação ao código-base — Prefira recomendações que a arquitetura atual possa suportar.
- Lacunas de contexto — Sinalize quando o produto não tem contexto suficiente para recomendar com confiança.
- Evidência desatualizada — Sinalize fontes antigas ou ausentes; recomende atualização ou validação.
- Sempre inclua — Uma métrica de sucesso para cada recomendação e uma seção Por que não construir isso para as principais escolhas.
Modos de saída
Escolha o modo que corresponde à solicitação. Use os modelos em templates/:
| Modo | Modelo | Quando usar |
|---|---|---|
| Varredura de Produto | templates/product-map-template.md | Primeira passagem em um repositório desconhecido |
| Relatório de Lacunas Concorrenciais | templates/competitor-matrix-template.md | Usuário nomeia concorrentes ou pede lacunas |
| Relatório de Sinais de Mercado | templates/evidence-ledger-template.md | Usuário quer validação de demanda/tendência |
| Relatório de Oportunidades de Crescimento | templates/opportunity-report-template.md | Padrão para "o que construir a seguir" |
| Roteiro Priorizado | templates/opportunity-report-template.md | Sequenciamento de vários trimestres |
| PRD de Crescimento | templates/growth-prd-template.md | Usuário escolhe uma funcionalidade para especificar |
| Desdobramento em Issues do GitHub | templates/github-issues-template.md | Usuário quer tarefas de execução |
| Plano de Validação | references/validation-experiments.md | Evidência fraca ou apostas de alto risco |
Veja exemplos reais em examples/.
Fluxo de trabalho
Acompanhe o progresso com esta lista de verificação:
Progresso do Growth Scout:
- [ ] Fase 1: Entender o produto
- [ ] Fase 2: Mapear capacidades atuais
- [ ] Fase 3: Analisar sinais externos
- [ ] Fase 4: Identificar oportunidades
- [ ] Fase 5: Pontuar oportunidades
- [ ] Fase 6: Recomendar próximas funcionalidades
- [ ] Fase 7: Artefatos de execução (se solicitado)
Fase 1: Entender o produto
Leia o contexto disponível nesta ordem:
- README, docs, changelog, issues/PRs
- Manifestos de pacotes (
package.json,pyproject.toml,Cargo.toml, etc.) - Rotas, páginas, endpoints de API, comandos CLI
- Esquema de banco de dados, migrações, modelos
- Testes (qual comportamento é garantido)
- Config, exemplos de env, arquivos de deploy
- Auth, faturamento, analytics, integrações
Extraia e registre:
| Campo | Status (conhecida/inferida/desconhecida) |
|---|---|
| Categoria do produto | |
| Usuário-alvo | |
| Fluxo de trabalho principal | |
| Funcionalidades atuais | |
| Modelo de monetização | |
| Estágio de maturidade (ideia/MVP/crescimento/maduro) | |
| Restrições (equipe, stack, conformidade) |
Saída: Mapa do produto usando templates/product-map-template.md.
Orientacão aprofundada: references/codebase-product-mapping.md.
Fase 2: Mapear capacidades atuais
Construa um inventário de funcionalidades:
- Entregue — Na UI, API, ou docs conforme disponível hoje
- Parcial — Rotas esboçadas, flags de funcionalidade, comentários TODO, esquema não utilizado
- Requisitos básicos ausentes — Esperado para esta categoria, mas ausente
- Fundações técnicas — Auth, pagamentos, notificações, jobs, analytics, i18n, etc.
Anote o que o código-base já torna barato construir.
Fase 3: Analisar sinais externos
Pesquise quando as ferramentas permitirem. Fontes e classificações de força: references/market-signal-sources.md.
Se o usuário nomear um segmento vertical, consulte references/industry-packs/<vertical>.md (ex.: b2b-saas, developer-tools, consumer-mobile).
Se a navegação ao vivo não estiver disponível: use apenas o contexto do repositório e links/docs fornecidos pelo usuário. Marque todas as afirmações externas como inferidas ou desconhecidas. Recomende validação antes de construir.
Nunca invente evidências de concorrentes.
Sinais de demanda de itens de trabalho (MCP, peça primeiro): Quando o MCP estiver conectado e o usuário quiser evidências de demanda do rastreador de issues:
- Chame
preview_work_item_mineprimeiro — mostre um resumo do escopo ao usuário (apenas metadados/contagem). - Aguarde aprovação explícita ("Sim, prossiga"), um caminho de arquivo (
.growth-scout/work-items.json) ou pule. - Só então chame
mine_work_item_signalscompreview_id+confirmed: true. - Nunca detecte automaticamente o provedor do git remoto sem confirmação do usuário.
- Se o usuário recusar → use apenas evidência manual; limite Força da Demanda conforme a rubrica.
- Nunca faça mineração durante a instalação de bootstrap (
install-growth-scout.mjs).
Veja integrations/mcp.md para o fluxo completo de "peça primeiro".
Para pesquisa de concorrentes, organize os achados em:
| Categoria | Significado |
|---|---|
| Requisitos básicos | Usuários esperam; a ausência prejudica conversão/retenção |
| Diferenciação | Lacuna significativa que você poderia dominar |
| Fraquezas do concorrente | Pontos problemáticos que usuários reclamam em outros lugares |
| Copiar-perigoso | Parece bom em uma matriz, mas errado para seu posicionamento |
| Ignorar/ruído | Hype, apenas enterprise, ou irrelevante para seu ICP |
Método: references/competitor-analysis.md.
Mantenha um registro de evidências: templates/evidence-ledger-template.md.
Fase 4: Identificar oportunidades
Gere funcionalidades candidatas em alavancas de crescimento. Taxonomia: references/growth-taxonomy.md.
| Alavanca | Exemplos de tipos de oportunidade |
|---|---|
| Aquisição | Páginas SEO, marketplace de integrações, gancho de plano gratuito |
| Ativação | Checklist de onboarding, modelos, atalhos de time-to-value |
| Retenção | Notificações, estado salvo, loops de hábito |
| Receita | Limites de uso, faturamento por assento, tiers premium |
| Indicação | Créditos de convite, espaços de trabalho compartilhados |
| Expansão | Funcionalidades de equipe, API, controles de admin |
| Confiança | SSO, logs de auditoria, página de status, exportação |
| Diferenciação | Fluxo de trabalho único, foco vertical |
| Requisitos básicos | Capacidade básica ausente |
| Eficiência operacional | Ferramentas de admin, desvio de suporte |
Almeje de 8 a 15 ideias brutas antes de pontuar. Mescle duplicatas.
Fase 5: Pontuar oportunidades
Use o modelo de Pontuação de Oportunidade de Crescimento. Rubrica completa: references/opportunity-scoring.md. Faixas de recomendação (Construir agora, Validar primeiro, Estacionar, Ignorar): veja a tabela Limiares de recomendação naquele arquivo.
Pontuação de Oportunidade de Crescimento =
Força da Demanda
+ Gap Concorrencial
+ Adequação Estratégica
+ Alavancagem de Crescimento
+ Impacto em Receita/Retenção
+ Viabilidade no Código-base
+ Vantagem de Tempo para Aprender
- Complexidade de Implementação
- Risco de Produto
- Carga de Manutenção
Pontue cada fator de 1 a 5, a menos que o usuário especifique o contrário.
| Fator | Definição |
|---|---|
| Força da Demanda | Evidência de que usuários querem isso |
| Gap Concorrencial | Concorrentes não têm, fazem mal, ou usuários esperam |
| Adequação Estratégica | Corresponde ao posicionamento e ICP |
| Alavancagem de Crescimento | Melhora aquisição, ativação, retenção, receita, indicação ou expansão |
| Impacto em Receita/Retenção | Impacto provável nos negócios |
| Viabilidade no Código-base | Arquitetura atual suporta |
| Vantagem de Tempo para Aprender | Velocidade para validar a hipótese |
| Complexidade de Implementação | Custo de engenharia (subtrair) |
| Risco de Produto | Confusão de UX, aumento de escopo, distração (subtrair) |
| Carga de Manutenção | Custo de longo prazo (subtrair) |
Quando a evidência é fraca, limite Força da Demanda a 2 e recomende validar primeiro.
Fase 6: Recomendar próximas funcionalidades
Gere de 3 a 7 oportunidades classificadas. Para cada uma, inclua:
- Nome da funcionalidade
- Alavanca de crescimento
- Problema
- Usuário-alvo
- Evidência (com confiança)
- Insight do concorrente
- Por que agora
- Escopo MVP
- Adequação ao código-base
- Esforço estimado (P/M/G)
- Riscos
- Métrica de sucesso
- Validação sugerida
- Recomendação: Construir agora | Validar primeiro | Estacionar | Ignorar
Seções obrigatórias no relatório:
- Resumo executivo (principal escolha + vice-campeã)
- Tabela de oportunidades classificadas com pontuações
- Detalhamento das pontuações das 3 principais
- Resumo de evidências (conhecida vs inferida vs desconhecida)
- Por que não construir isso para as 2 a 3 principais recomendações
- Plano de validação para qualquer coisa que não seja "Construir agora"
Modelo: templates/opportunity-report-template.md.
Modo de repositório grande
Use esta sequência de várias rodadas quando o código-base for grande demais para ser lido em uma única passagem (monorepos, >~50k LOC, ou limites de contexto). Não tente todas as fases em uma única rodada.
| Rodada | Escopo | Saída |
|---|---|---|
| 1 | Fases 1–2 apenas | Varredura de Produto + mapa de capacidades (templates/product-map-template.md). Sem pontuação ainda. |
| 2 | Fase 3 + Fase 4 (leve) | Resumo de sinais externos + lista longa de oportunidades (8 a 15 títulos com declarações de problema de uma linha). Sem tabelas completas de GOS. |
| 3 | Fases 5–6 (top 5) | Pontuação GOS completa e classificação apenas para os 5 principais itens da lista longa. |
| 4 | Fase 7 sob demanda | Mergulho profundo apenas no #1; PRD / issues do GitHub apenas se o usuário solicitar. |
Entre rodadas, mantenha o mapa do produto e a lista longa como contexto. Sinalize como desconhecido onde o repositório não foi relido. Recomende executar node scripts/repo-inventory.mjs no repositório do produto quando a Fase 1 precisar de um esqueleto rápido (a ferramenta acompanha o pacote Growth Scout).
Fase 7: Transformar oportunidade selecionada em artefatos de execução
Quando o usuário selecionar uma funcionalidade, produza conforme solicitado:
| Artefato | Modelo / referência |
|---|---|
| PRD de Crescimento | templates/growth-prd-template.md |
| Desdobramento em issues do GitHub | templates/github-issues-template.md |
| Plano de implementação técnica | Em linha no PRD ou seção separada referenciando padrões do repositório |
| Plano de teste | Critérios de aceitação + áreas de regressão |
| Checklist de lançamento | Seção de plano de rollout no PRD |
| Plano de métricas | Métricas de sucesso + nomes de eventos se existirem analytics |
| Experimento de validação | references/validation-experiments.md |
Exemplo de PRD: examples/example-growth-prd.md.
Referência rápida
| Tópico | Arquivo |
|---|---|
| Alavancas de crescimento | references/growth-taxonomy.md |
| Rubrica de pontuação | references/opportunity-scoring.md |
| Método de concorrentes | references/competitor-analysis.md |
| Fontes de sinal | references/market-signal-sources.md |
| Pacotes de indústria | references/industry-packs/ (b2b-saas, developer-tools, consumer-mobile) |
| Mapeamento de código-base | references/codebase-product-mapping.md |
| Opções de validação | references/validation-experiments.md |
| MCP scout opcional | integrations/mcp.md — ferramentas de concorrente + itens de trabalho (mcp/growth-scout-mcp/) |
| Exemplo de varredura de produto | examples/example-product-scan.md |
| Exemplo de relatório de oportunidade | examples/example-opportunity-report.md |
Execução mínima viável (com limite de tempo)
Se o usuário quiser uma resposta rápida:
- Leia rapidamente README + rotas + arquivo de pacote (equivalente a 5 min)
- Liste as 5 principais funcionalidades existentes + 3 lacunas óbvias
- Pontue de 3 a 5 ideias com desconhecidos explícitos
- Recomende um Construir agora e um Validar primeiro
Ainda inclua métricas de sucesso e rótulos de evidência.