TongyiDai/mckinsey-people-brain

Cérebro de RH McKinsey

Consultor de RH MBB recrutado com 200W tokens, 10 anos de experiência, foco em talento, organização e transformação com IA.

Modo Principal de Trabalho

Esta Skill divide a tarefa em duas etapas:

1. Coleta de Fontes Oficiais: Descobrir páginas candidatas nos sites oficiais das consultorias MBB, extrair corpo do texto, título, data, URL final, status e snapshot original.
2. Construção do Banco de Dados do Agente: Para os resultados da coleta, realizar normalização de URLs, deduplicação, controle de qualidade e classificação por tema, gerando saídas em JSON, CSV e SQLite.

A escrita no Feishu é um adaptador de publicação após a construção do banco de dados. É opcional, pode ser reexecutada e lida de volta, mas não deve ser a única fonte de verdade do banco de dados local.

Escopo de Aplicação

Invocar esta Skill quando o usuário solicitar:

• Pesquisar conteúdos sobre gestão de talentos, organização, liderança, habilidades, desempenho, IA e o futuro do trabalho nos sites oficiais das consultorias MBB (McKinsey, BCG, Bain).
• Atualizar uma base de conteúdo MBB existente, identificando novas fontes, fontes atualizadas, restritas, com corpo de texto ausente e fontes duplicadas.
• Construir um banco de dados pesquisável pelo agente a partir de registros que passaram pelo controle de qualidade.
• Com autorização do usuário, escrever incrementalmente registros verificados em uma Base ou Wiki pessoal do Feishu.

As fontes são fixadas aos domínios oficiais: mckinsey.com, bcg.com, bain.com e seus subdomínios regionais oficiais. Resumos de terceiros, páginas de resultados de pesquisa e páginas republicadas podem ser usados apenas como pistas de descoberta, não podendo entrar na tabela final de registro de fontes.

Fase 1: Coleta de Fontes Oficiais

Primeiro, ler a configuração de fontes do projeto e o manifesto anterior. A configuração deve incluir, no mínimo: firm, domínio oficial, palavras-chave de tema, URLs semente, ritmo de coleta e número mínimo de caracteres do corpo do texto.

A prioridade deve ser: sitemap oficial ou índice temático, resultados de busca interna do site oficial, atualização de URLs já registradas. Os resultados da descoberta devem ser primeiro escritos em targets.json, depois cada um deve ser coletado para fetched.json. Cada execução usa um run_id independente, preservando snapshots originais em raw/ e o collect-manifest.json.

Regras de coleta:

• Usar HTTPS, preservar a URL final do redirecionamento, remover parâmetros de rastreamento e fragmentos, gerar um ID estável a partir da URL normalizada.
• Para erros 429, 5xx e de rede, fazer um número limitado de tentativas com backoff; falhas individuais são registradas com status, sem interromper o lote inteiro.
• Respeitar robots, frequência de acesso e limites de login e paywall. Quando encontrar restrições, marcar como restricted, não preencher o corpo do texto com resumos de busca ou conteúdo adivinhado.
• ok significa que o corpo do texto atingiu o limite mínimo e que a fonte, o título e a URL foram validados; no_body, restricted, error devem manter o motivo da falha.
• O script de coleta é responsável apenas por buscar e salvar os dados, não deve escrever diretamente no Feishu durante a coleta.

Se o projeto já tiver um adaptador específico para o site, reutilizá-lo; para novos sites, primeiro criar e testar o adaptador antes de incluí-lo na execução em lote. A validação geral e a construção do banco de dados usam os scripts dentro desta Skill.

Fase 2: Construção do Banco de Dados do Agente

Executar com fetched.json e o histórico opcional base-corpus:

python3 scripts/build_agent_db.py \
  --run-dir data/runs/20260806-01 \
  --base-corpus data/agent-db/records.json \
  --min-body-chars 800

O script executa as seguintes ações:

• Normalizar URLs, remover registros duplicados da mesma fonte.
• Selecionar o registro a manter com base na qualidade do corpo do texto, integridade do título e timestamp de coleta, registrando duplicate_of.
• Validar domínio, firm, status, comprimento do corpo do texto, contagem de caracteres e título.
• Classificar em temas unificados: Estratégia de Talentos, Design Organizacional, IA e o Futuro do Trabalho, Habilidades e Aprendizado, Desempenho e Incentivos, People Analytics, Experiência do Funcionário, Liderança, Planejamento da Força de Trabalho.
• Gerar agent-db/records.json, agent-db/source-register.csv, agent-db/agent-db.sqlite, agent-db/manifest.json.

Controle de qualidade:

python3 scripts/validate_records.py data/runs/20260806-01/fetched.json --min-body-chars 800 --strict

Apenas registros que passarem pelo controle de qualidade são adequados para o conjunto de textos citáveis. Registros restritos e com corpo de texto ausente podem entrar em um conjunto de monitoramento, mas devem manter status e motivo da falha.

Fase 3: Escrita Incremental no Feishu

Antes de escrever, confirmar o profile atual do CLI, identity=user, a Base/Wiki de destino e o mapeamento de campos. O Feishu pessoal e o Feishu corporativo são dois tenants independentes, o perfil padrão não deve ser usado para inferir o destino.

Recomenda-se usar o valor normalizado de source_url como chave de idempotência:

1. Ler os campos da tabela de destino e os registros existentes.
2. Construir um índice URL → record_id.
3. Criar registros para novas URLs, atualizar campos necessários para URLs existentes; para registros restritos, atualizar apenas status e motivo da falha.
4. Após cada lote de escrita, ler de volta imediatamente por URL, verificando título, status, data, tema e link de origem.
5. Se a escrita falhar ou a identidade expirar, parar, preservando os artefatos de construção local e a lista de pendências.

Não submeter ao GitHub o número de linhas da Base, tokens do Wiki, IDs de tenant, URLs internas, tokens de acesso, caminhos pessoais ou snapshots de páginas da web originais.

Contrato de Registro

Os campos mínimos do registro são: id, firm, title, source_url, final_url, published_date, status, failure_reason, body_text, body_chars, tags, themes, fetched_at_utc.

Status permitidos apenas: ok, restricted, no_body, error. Regras detalhadas em references/data-contract.md.

Lista de Verificação de Revisão de Código

• A coleta e a construção do banco de dados podem ser executadas independentemente, e as falhas podem ser localizadas por run_id e URL.
• A reexecução não deve gerar registros duplicados para a mesma URL; as saídas são escritas em arquivos temporários e depois substituídas atomicamente.
• O snapshot original, o resultado limpo e o manifesto devem ser mutuamente rastreáveis.
• Fontes públicas e dados internos são separados; o repositório não deve conter tokens, cookies, caminhos pessoais, identificadores de tenant ou dados reais de negócios.
• Erros HTTP, corpo de texto vazio, mudanças na estrutura do site, chaves duplicadas no banco de dados e falhas de autenticação no Feishu têm resultados claros.
• Os testes cobrem normalização de URL, restrição de domínio, limite de corpo de texto, preferência de deduplicação e status de falha.

Arquivos de Referência

• data-contract.md: Campos de registro, status, controle de qualidade e estrutura de saída.
• source-adapters.md: Descoberta de fontes oficiais MBB e convenções de adaptadores de site.
• feishu-publish.md: Validação de identidade no Feishu, escrita idempotente e requisitos de leitura de volta.
• scripts/validate_records.py: Script independente de validação de qualidade.
• scripts/build_agent_db.py: Script independente de construção de banco de dados.