Habilidade de Painel do GitHub

Crie um painel de análise de repositório do GitHub de tela única no estilo visual do FlowAI / Soft Paper Workspace: tela off-white quente, painéis brancos arredondados, barra lateral esquerda fixa, cartões de KPI compactos, marcadores pastel, tabelas densas e linhas de baixa contraste.

Mapa de Recursos

github-dashboard/
├── SKILL.md
├── example.html                         ← rendered reference dashboard
└── references/
    ├── template.html                    ← live-artifact-compatible HTML template
    ├── example-data.json                ← normalized public GitHub data shape
    ├── artifact-example.json            ← minimal live-artifact create input
    └── provenance-example.json          ← safe source/provenance example

Quando usar esta habilidade

Use esta habilidade quando o usuário solicitar um painel ou relatório sobre um único repositório do GitHub, por exemplo:

• painel de crescimento de repositório
• relatório de saúde de projeto open-source
• análise de estrelas / forks / contribuidores do GitHub
• página de atividade de issues e pull requests
• painel de mantenedor / contribuidor

Se o usuário solicitar atualizações, auditabilidade da origem ou atualizações agendadas, produza o conjunto de artefatos de origem ao vivo (template.html, data.json, artifact.json, provenance.json) e siga o contrato live-artifact. Se ele precisar apenas de um artefato visual, produza um index.html autônomo.

Fluxo de Trabalho

1. Resolver escopo do repositório

   • Analise owner/repo do briefing.
   • Esta habilidade v1 é limitada a um repositório. Se vários repositórios forem solicitados, peça ao usuário para escolher o repositório principal ou crie um painel por repositório.
   • Se o repositório estiver faltando, faça uma pergunta concisa para a URL do GitHub ou owner/repo.

2. Coletar dados públicos do GitHub

   • Prefira o GitHub CLI/API para dados de repositórios públicos quando disponíveis.
   • Estrelas/forks/observadores/issues abertas atuais: GET /repos/{owner}/{repo} (stargazers_count, forks_count, watchers_count, open_issues_count).
   • Contribuidores: pagine GET /repos/{owner}/{repo}/contributors?per_page=100&page=N, ordene por contributions decrescente e pegue os N principais usados pelo painel. Se apenas a página 1 estiver disponível, rotule os totais como estimativas da primeira página.
   • Issues: use a API de Pesquisa do GitHub (repo:{owner}/{repo} is:issue) para contagens totais, ou pagine GET /repos/{owner}/{repo}/issues?state=all e filtre itens com um campo pull_request.
   • Pull requests: use a API de Pesquisa do GitHub (repo:{owner}/{repo} is:pr) para contagens totais, ou pagine GET /repos/{owner}/{repo}/pulls?state=all e conte as páginas através do cabeçalho Link.
   • Atividade recente: combine as issues e pull requests mais recentes, normalize-as em linhas prontas para exibição e limite a lista de pré-visualização a 5–10 itens.
   • Métricas de crescimento/delta: o GitHub REST não expõe deltas completos de estrelas/forks históricos. Use GraphQL, snapshots de eventos de stargazer, a API de Eventos onde disponível, ou marque explicitamente os deltas como estimados/sintéticos em provenance.json.
   • Não armazene tokens de autenticação, envelopes HTTP brutos, cookies, cabeçalhos de limite de taxa ou metadados privados.

3. Normalizar em dados do painel

   • repository necessários: name, fullName, url, description, language, license, created, lastUpdated.
   • metrics necessários: estrelas, forks, contribuidores, issues, pull requests. Armazene totais prontos para exibição mais pequenos deltas ou notas de crescimento.
   • contributors necessários: top 5–8 contribuidores com login, avatar e contributions.
   • recentActivity necessários: linhas prontas para exibição com title, typeText, typeClass, label, labelClass, author, authorAvatar e updated. Não dependa de condicionais de template para alternar entre issues/PRs.
   • Dados de gráfico podem ser sintéticos apenas quando o GitHub não expõe o histórico exato; documente a transformação na proveniência.

4. Aplicar o sistema visual

   • Use os tokens ativos de DESIGN.md quando presentes.
   • Se nenhum sistema de design for fornecido, use os padrões do Soft Paper refletidos em references/template.html: tela #F2F2F0, cartões brancos, bordas #ECECEA, tinta #0A0A0A, tipografia Geist/Inter, barra lateral de 256px, barra superior de 48px e raio de cartão de 16px.
   • Mantenha a cor pequena e semântica: verde para métricas saudáveis, âmbar para aviso, azul para rótulos de recursos/PR, vermelho apenas para defeitos ou risco.

5. Organizar a página

   • Estrutura: barra lateral de 256px + painel principal, ambos brancos, arredondados em 16px, borda de 1px.
   • Barra superior: contexto do repositório à esquerda, atualizações/exportação/ações à direita.

…