Scorecard de Aplicativo

---

name: app-scorecard description: Avalie qualquer aplicativo (próprio ou de concorrente) com uma rubrica baseada em pesquisa e produza um scorecard reutilizável e comparável — 0–5 por dimensão com nota de evidência, verificações de portões não compensatórias primeiro e uma "menor correção" por dimensão fraca. Adapta-se ao estágio do produto: um aplicativo pré-PMF com menos de ~100 usuários é avaliado em 9 dimensões, um aplicativo em crescimento nas 23 completas. Use sempre que o usuário disser "avalie este aplicativo", "nota para o aplicativo", "classifique a UI/UX", "quão bom é [app]", "scorecard do aplicativo", "execute o scorecard em [app]", "como [app] se compara", "está pronto para lançar / promover para produção" ou quiser um número antes/depois após um sprint de desenvolvimento ou uma rodada beta. Lê o código-fonte + deploy + documentação, opcionalmente feedback beta / análises, e se recusa a inventar retenção, receita ou PMF apenas a partir do código. Gera uma tabela no chat e um artefato HTML de scorecard publicado. Combina com ui-usability-audit (profundidade UI), qa-sweep (teste funcional), dev-to-prod-promotion-review (gate de release). user-invocable: true

O que Scorecard de Aplicativo faz?

Se um arquivo LOCAL.md estiver ao lado deste SKILL.md, leia-o primeiro — ele contém as especificidades deste workspace (caminhos, ferramentas, exemplos) e substitui os padrões genéricos abaixo.

Uma rubrica, todos os aplicativos, todas as vezes. O objetivo é a comparabilidade: as mesmas dimensões, os mesmos âncoras de 0–5, os mesmos portões, para que um aplicativo avaliado em março possa ser reavaliado em junho e a diferença signifique algo, e dois aplicativos possam ser comparados sem re-discutir os critérios.

Construído a partir do relatório de pesquisa "What Makes an App Exceptional" (references/framework-source.md) mais pesquisas direcionadas para preencher suas lacunas (references/research-notes.md). Exemplo prático de uma execução completa de 23 dimensões (anônimo): assets/example-audit.html.

Princípios (leia uma vez, eles governam tudo)

1. Portões antes das pontuações. Segurança, privacidade, legalidade, acessibilidade e — para qualquer aplicativo que afirme fatos — correção de conteúdo são não compensatórios. Um 5 em design não pode compensar um 0 em privacidade. Liste os portões abertos primeiro; nunca faça médias.
2. Evidência supera opinião. Cada pontuação carrega um grau de evidência (E0 afirmação → E4 durável) e cada descoberta é marcada como Observado / Inferido / Hipótese / Desconhecido.
3. Nunca infira comportamento a partir do código. Retenção, engajamento, ajuste ao mercado, satisfação, receita são desconhecidos a menos que haja telemetria, dados de coorte ou uma pesquisa. Código e capturas de tela não podem prová-los. Diga "desconhecido", não "provável".
4. O estágio decide a rubrica. Aplicativos pré-PMF são julgados se estão aprendendo, não se têm SLOs. Veja references/stages.md.
5. Cadência sobre benchmarks. Não existe retenção D7 universal. Um trabalho semanal usado "algumas vezes em duas semanas" é saudável. Nomeie a cadência natural primeiro.
6. Toda dimensão fraca recebe uma menor correção. Um scorecard sem correções é uma reclamação. Uma linha, reversível, dimensionada em horas ou dias.

Fluxo de Trabalho

0 · Enquadrar (5 minutos, não pule)

Fixe, em uma linha cada: usuário-alvo · trabalho principal · cadência natural · evento de primeiro valor · modelo de negócio · principais alternativas (incl. "não fazer nada"). Se o repositório tiver AGENTS.md / README.md, retire-os daí e cite-os. Se estiverem faltando, infira, declare a suposição, prossiga.

Em seguida, escolha o estágio (references/stages.md):

Estágio	Sinal	Rubrica
Pré-PMF	< ~100 usuários ativos, sem dados de coorte, ou Sean Ellis "muito decepcionado" < 40 %	9 dimensões + portões
Crescimento	Coortes existem, > 100 ativos, ou clientes pagantes	23 completas + portões
Ideia / especificação	Ainda sem código	rubrica apenas de hipóteses (stages.md §3)

1 · Coletar evidências (paralelo quando possível)

Sempre (código + deploy):

• Rotas / telas, superfície da API, autenticação + autorização (no servidor?)
• Testes: execute-os. Lint: execute-o. CI: leia os workflows. Deploy: leia o script.
• Telemetria: o que é realmente enviado? (Uma importação de análise que segmenta uma plataforma onde o app não está hospedado conta como nada.)
• Armazenamento / BD: o que é escrito por usuário, há exclusão, há backup.
• Privacidade / termos / rotas de exclusão. Limites de taxa e cotas em APIs pagas.
• Verificações de acessibilidade: aria-, alt=, focus-visible, prefers-reduced-motion, rótulos.
• Cobertura i18n: strings externalizadas vs. codificadas, localidades, regras de plural/data.
• Estados de erro/vazio/carregamento/offline; error.tsx / not-found.tsx no nível de rota.
• Desempenho: dados pesados no servidor ou cliente, cache, p95 se registrado.
• Para aplicativos de IA / referência: lógica de atribuição + citação, proteção de fundamentação, controles de alucinação, proveniência do corpus.

Quando disponível (comportamento): formulário beta, análises, tabelas de coorte, tickets de suporte, resultados da pesquisa Sean Ellis, sessões observadas. Estes elevam as dimensões de "desconhecido" para uma pontuação real. Sem eles, deixe como desconhecido.

Distribua agentes Explore somente leitura para amplitude (máx. 3 concorrentes); leia o ponto de entrada, navegação, fluxo principal, autenticação e armazenamento você mesmo.

2 · Verificar os portões

De references/rubric.md §Gates. Cada portão é aberto / fechado / n-a com a evidência observada. Portões abertos vão no topo de cada saída. Comuns: sem política de privacidade ou rota de exclusão enquanto coleta PII; pagamentos sem termos; autenticação no servidor ausente; sem movimento reduzido com animações para um público mais velho; conteúdo mal atribuído ou não citado em um aplicativo de referência.

3 · Pontuar cada dimensão

Para cada dimensão na rubrica escolhida (references/rubric.md):

• Pontuação 0–5 usando as âncoras da rubrica (não palpites).
• Grau de evidência E0–E4 e tag Observado / Inferido / Desconhecido.
• Marque a lista de verificação da dimensão: presente / parcial / ausente / incognoscível.
• Descoberta de uma linha fundamentada em um file:line, uma rota, uma configuração ou uma citação.
• Menor correção de uma linha se pontuação ≤ 3.

Para design de UI / UX, use a sub-rubrica de design visual em rubric.md §UX Design (tipografia, hierarquia, cor, espaçamento, consistência, texto). Se o usuário quiser profundidade aqui, invoque ui-usability-audit após o scorecard e referencie suas notas por letra.

4 · Julgar

• Portões abertos (novamente, primeiro).
• Principais 3 razões para vencer · principais 3 razões para falhar · principais 3 desconhecidos.
• O único próximo experimento ou correção de maior alavancagem.
• Veredito: Go / Conditional Go / Iterate / No-Go, com confiança. Regra prática: qualquer portão aberto ⇒ no máximo Iterate; todos os portões fechados + evento de valor instrumentado ⇒ Conditional Go; quatro semanas de dados de retenção na cadência natural ⇒ Go está na mesa.

5 · Entregar — o scorecard visual é a entrega

A mensagem no chat é um resumo. O artefato HTML do scorecard publicado é a saída. Nunca termine uma execução sem um; se a ferramenta Artifact não estiver disponível (Codex, um subagente), escreva o HTML em docs/scorecards/<data>-scorecard.html no repositório do app e envie/abra o arquivo.

1. Construa o artefato a partir de assets/scorecard-template.html. Carregue o skill artifact-design primeiro, depois mantenha a estrutura do modelo exatamente, nesta ordem, para que o scorecard de cada aplicativo seja lido da mesma forma:
   1. Cabeçalho — <App> Scorecard, estágio + fontes de evidência + data como sobrancelha, tese de uma frase, chip de veredito (classe go / âmbar padrão / nogo), confiança e a faixa de enquadramento (usuário · trabalho · cadência · evento de valor · alternativas).
   2. Grade de visão geral — um bloco por dimensão, banda de pontuação colorida (teal ≥ 3, âmbar 2, vermelho ≤ 1, cinza desconhecido), contorno gate em qualquer dimensão com um portão aberto e um ▲/▼ delta vs. a execução anterior quando existir.
   3. Portões — cada portão como um cartão: aberto (vermelho) ou fechado (verde), com a evidência observada e nomes de arquivo/rota em code.
   4. Cartões por dimensão, agrupados (estratégia e economia · experiência e confiança · engenharia e escala, ou a lista do Nível A): pontuação, selo de evidência, descoberta de 2–4 frases, lista de verificação com marcas presente/parcial/ausente/incognoscível e a linha de menor correção para qualquer coisa ≤ 3.
   5. Julgamento final — três colunas (razões para vencer · razões para falhar · desconhecidos críticos) e o painel escuro "próximo passo de maior alavancagem".
   6. Nota de rodapé do método — o que foi lido, executado, recusado; link para a execução anterior. Regras de design: apenas conteúdo real, sem lorem; cada cor do conjunto de tokens para que o modo escuro funcione; sem emoji, sem gráficos decorativos; dígitos em mono tabular. Olhe para a página renderizada uma vez, corrija o que ela mostrar, publique.
2. Publique com Artifact. Título <Nome do App> Scorecard, favicon 🔬 apenas na primeira publicação. Em uma reexecução, passe o url do artefato anterior para que o histórico permaneça em um link (encontre-o em docs/SCORECARD.md).
3. Chat: link primeiro, depois o bloco de enquadramento, portões abertos, uma tabela compacta (dimensão · pontuação · evidência · descoberta), veredito. Sucinto. Não duplique a prosa do artefato.
4. Persista uma linha no docs/SCORECARD.md do repositório do app (crie se ausente): data · estágio · portões abertos · pontuações por dimensão · veredito · URL do artefato. Faça commit apenas se o usuário solicitar.

Regras

• Leia completamente, depois pontue. A rubrica encurta o julgamento, nunca a leitura.
• Cite, não parafraseie, quando um testador ou um arquivo diz a coisa.
• Recuse-se a pontuar o que não pode ser conhecido. "Desconhecido" é uma célula válida e honesta.
• Não invente benchmarks. Os únicos limites numéricos que você pode citar são os em references/research-notes.md (SUS 68/80, Ellis 40 %, CWV 2,5 s / 200 ms / 0,1, severidade Nielsen 0–4, WCAG 2.2 AA, ASVS L1). Qualquer outra coisa é uma comparação com a própria execução anterior do aplicativo.
• Mesma rubrica entre aplicativos. Não adicione ou remova dimensões por aplicativo. Marque n-a quando uma dimensão genuinamente não se aplicar (ex.: Monetização em uma ferramenta interna) — n-a é registrado, não pulado.
• Dev/staging apenas se você precisar usar o aplicativo ao vivo. Nunca produção.
• Somente leitura. O scorecard recomenda; ele não edita o aplicativo.
• Sem artefato, sem execução. Um scorecard que vive apenas no histórico do chat não é comparável no próximo trimestre. Sempre publique (ou escreva o arquivo HTML).

Compõe-se com

• ui-usability-audit — profundidade na dimensão de Design de UX, visual antes/depois.
• qa-sweep — PASS/FAIL funcional que alimenta Confiabilidade e UX Principal.
• dev-to-prod-promotion-review — o veredito do scorecard é uma entrada para o gate de release.
• panel-brainstorm — quando as "menores correções" precisam de alternativas geradas.