fix: make the skills installer work on a clean Mac, add community skills and selection flags

[DevOpsAIguru123]

Why

The install command in the README fails on a clean Mac:

$ /usr/bin/python3 scripts/install_skills.py --agent claude-code --source all --dry-run
Reading the catalog needs PyYAML. Either 'pip install pyyaml' or pass --source owner/repo

install.sh requires python3, macOS's /usr/bin/python3 has no PyYAML, and --source all is the one path that reads the catalog. Anyone following the documented instructions on a stock interpreter hit this.

Two related problems turned up while fixing it: community skills were unreachable by any command, and one official source was undocumented.

What changed

The PyYAML failure. Adds data/catalog.json, a generated stdlib-readable projection of the skill entries in data/repos.yaml, read in preference to the YAML. PyYAML is now only a fallback. All 12 install/ scripts fetch it alongside repos.yaml — that is the step that gets the fix to users. scripts/sync_catalog_json.py regenerates it and CI checks it, mirroring the existing sync_readme_counts.py pattern.

Community skills were uninstallable. CATALOG_CATEGORY was a single hardcoded string, so the three community-agent-skills entries could not be selected by any command.

Selection flags. Picking a whole set previously required knowing that --source doubles as a keyword argument:

Flag	Installs
--official	361 skills
--community	26 skills
--all	387 skills

The flags compose, so --official --community equals --all. --source owner/repo still works for a single repo. Note --source all remains a published alias for official and so, unlike the --all flag, excludes community skills — both catalog docs call that out. Combining --source with a selection flag is rejected rather than silently resolved.

TLS from a virtualenv. A python.org build looks for a cert.pem inside its own framework directory that does not exist until Install Certificates.command has been run, and a venv created from one inherits that empty store, failing every download with CERTIFICATE_VERIFY_FAILED. _ssl_context now tries certifi, then the interpreter's own store, then the CA bundle the OS ships. An empty store is detectable via get_ca_certs() with no network call, so the healthy path is unchanged.

Docs. harness/harness-skills had no section at all despite being one of five official sources. Every count in the catalog doc was stale — Google 72→80, Microsoft 191→188, Azure 33→32, Azure DevOps 6→7, Google cloud filter 59→67, analytics 2→3, Microsoft core skills 13→11. All re-measured and verified against live downloads. Adds docs/community-skills-catalog.md.

Verification

Run on macOS 26.2 (arm64).

• The failing command above now resolves 361 skills on /usr/bin/python3.
• Clean-Mac simulation — stripped environment, no virtualenv, PyYAML confirmed absent — installs 26 real skill folders.
• The genuine install.sh run end to end against a local HTTP server (since these changes are not on main yet): fetches all three files including catalog.json, installs 26 skills, idempotent on re-run.
• All six agent installers resolve to their correct skills directories; install/all hits all five.
• All 20 documented commands checked against live downloads; every stated count matches.
• An interpreter whose default context loads 0 certs went from failing outright to installing 26 skills, picking up 128 certs from /etc/ssl/cert.pem.
• Tests 45 → 60. New regression tests were mutation-checked: disabling the catalog.json branch fails three of them, disabling the empty-store check fails the TLS fallback test.

Not verified

• Windows. PowerShell is not installed on the test machine, so install.ps1 has had static checks only (same three fetches, @args splat intact). It is unaffected by the TLS change, since Invoke-WebRequest uses the OS trust store.
• Linux. Should behave identically, but untested here. The Debian, RHEL and SUSE CA bundle paths are included on that basis.
• Skill counts in the docs are point-in-time; upstream repos change.