McKinsey People Brain

What does McKinsey People Brain do?

An MBB HR consultant recruited with 200W tokens, 10 years of experience, focusing on talent, organization, and AI transformation.

Core Workflow

This skill breaks down the task into two steps:

1. Official Source Collection: Discover candidate pages on MBB official websites, then scrape the body, title, date, final URL, status, and raw snapshot.
2. Agent Database Construction: Normalize URLs, deduplicate, apply quality gates, and categorize the scraped results, outputting JSON, CSV, and SQLite.

Feishu write-back is a publishing adapter that runs after database construction. It is optional, re-runnable, and readable, and must not become the sole source of truth for the local database.

Scope

Call this skill when the user requests:

• Searching for content on MBB (McKinsey, BCG, Bain) official websites related to talent management, organization, leadership, skills, performance, AI, and the future of work.
• Updating an existing MBB content library by identifying new, updated, restricted, missing-body, and duplicate sources.
• Building a structured agent-searchable database from records that have passed quality gates.
• With user authorization, incrementally writing verified records back to a personal Feishu Base or Wiki.

The source scope is fixed to official domains: mckinsey.com, bcg.com, bain.com, and their official regional subdomains. Third-party summaries, search result pages, and reposted pages can only serve as discovery clues; they must not enter the final source registry.

Phase 1: Collecting Official Sources

First, read the project source configuration and the last manifest. The configuration must include: firm, official domain, topic keywords, seed URLs, crawl cadence, and minimum body character count.

Priority order is: official sitemap or topic index, official on-site search results, and refresh of already registered URLs. Write discovery results into targets.json first, then scrape each target into fetched.json. Each run uses a unique run_id, preserving raw snapshots in raw/ and a collect-manifest.json.

Scraping rules:

• Use HTTPS, retain the final redirect URL, remove tracking parameters and fragments, and generate a stable ID from the normalized URL.
• Perform limited retries with backoff for 429, 5xx, and network errors; log failures per item without interrupting the entire batch.
• Respect robots.txt, crawl rate, login and paywall boundaries. Mark restricted pages as restricted; do not fill in body text from search snippets or guessed content.
• ok means the body meets the threshold and the source domain, title, and URL all pass validation; no_body, restricted, and error must retain the failure reason.
• The collection script is responsible only for scraping and writing to disk; do not write to Feishu during the scraping phase.

If a project already has a site-specific adapter, reuse it; for new sites, first write and test the adapter, then include it in batch runs. Use the scripts within this skill for general validation and database construction.

Phase 2: Building the Agent Database

Run the following command after merging fetched.json with an optional historical 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

The script performs the following actions:

• Normalize URLs, removing duplicate records from the same source.
• Select the best record based on body quality, title completeness, and fetch time, recording duplicate_of.
• Validate domain, firm, status, body length, character count, and title.
• Classify into unified themes: Talent Strategy, Organization Design, AI & Future of Work, Skills & Learning, Performance & Rewards, People Analytics, Employee Experience, Leadership, and Workforce Planning.
• Output agent-db/records.json, agent-db/source-register.csv, agent-db/agent-db.sqlite, and agent-db/manifest.json.

Quality gates:

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

Only records that pass the quality gates are suitable for inclusion in the citable body set. Restricted and missing-body records can enter the monitoring set but must include status and failure reason.

Phase 3: Feishu Incremental Write-Back

Before writing back, confirm the current CLI profile, identity=user, the target Base/Wiki, and the field mapping. A personal Feishu and a corporate Feishu are separate tenants; do not infer the target from the default profile.

Use the normalized value of source_url as the idempotency key recommended:

1. Read the target table fields and existing records.
2. Build a URL → record_id index.
3. Create records for new URLs, update necessary fields for existing URLs, and update only status and failure reason for restricted records.
4. After each batch write, immediately read back by URL, verifying title, status, date, theme, and source link.
5. Stop on write failures or session expiry, preserving the local build artifacts and the pending write list.

Do not commit Base row counts, Wiki tokens, tenant IDs, internal URLs, access tokens, personal paths, or raw webpage snapshots to GitHub.

Record Contract

Minimum record fields: id, firm, title, source_url, final_url, published_date, status, failure_reason, body_text, body_chars, tags, themes, fetched_at_utc.

Allowed statuses: ok, restricted, no_body, error. Detailed rules are in references/data-contract.md.

Code Review Checklist

• Collection and database construction can run independently; failures can be traced to run_id and URL.
• Re-running does not create duplicate records for the same URL; output is written to temporary files before atomic replacement.
• Raw snapshots, cleaned results, and manifest are mutually traceable.
• Public sources and internal data are separated; the repository contains no tokens, cookies, personal paths, tenant identifiers, or real business data.
• Clear outcomes for HTTP errors, empty bodies, site structure changes, database duplicate keys, and Feishu authentication failures.
• Tests cover URL normalization, domain restriction, body threshold, deduplication priority, and failure status.

Reference Files

• data-contract.md: Record fields, statuses, quality gates, and output structure.
• source-adapters.md: MBB official source discovery and site adapter conventions.
• feishu-publish.md: Feishu identity validation, idempotent write-back, and read-back requirements.
• scripts/validate_records.py: Standalone quality validation script.
• scripts/build_agent_db.py: Standalone database construction script.