fix: add encoding="utf-8" to write_text() with ensure_ascii=False in skills_hub

[AlexFucuson9]

Summary

Path.write_text() without encoding= defaults to the platform encoding — cp1252 on Windows, utf-8 on Linux/macOS. Two call sites in skills_hub.py pass ensure_ascii=False to json.dumps() (allowing non-ASCII characters through) but omit encoding="utf-8" on the subsequent write_text(). On Windows, this silently corrupts non-ASCII skill names, descriptions, and metadata into mojibake, which then fails to parse on read.

All other write_text() calls in the codebase already specify encoding="utf-8" (checked: curator.py, curator_backup.py, skill_bundles.py, agent_init.py, skills_sync.py, checkpoint_manager.py).

Changes

Line	Before	After
1055	write_text(json.dumps(data, ensure_ascii=False))	..., encoding="utf-8")
3254	write_text(json.dumps(data, ensure_ascii=False, default=str))	..., encoding="utf-8")

Test Plan

• ruff check tools/skills_hub.py passes
• Cache files with non-ASCII content survive a round-trip on Windows

[alt-glitch]

This was generated by AI during triage.

Related: this narrow fix (2 write_text() callsites in tools/skills_hub.py) is a strict subset of two broader open PRs that already contain these exact hunks byte-for-byte:

• fix(skills): pass encoding="utf-8" on skills-hub file I/O #47489 (earliest, ~15 skills_hub/skills_sync callsites)
• fix(platforms,gateway,tools): add encoding='utf-8' to write_text() calls #54240 (same author, 9 callsites across 6 files)

Not marking duplicate since it's a subset of an open superset rather than a same-scope copy — maintainer may prefer landing one of the broader PRs instead.

[teknium1]

Thanks for isolating a real Windows encoding issue.

Problems

• The changed writers at tools/skills_hub.py:1055 and :3254 now emit UTF-8, but their paired readers at :1045 and :3234 still use read_text() without encoding. The proposed write-only change therefore does not guarantee the advertised round trip on a non-UTF-8 Windows locale.
• The same state path remains in HubLockFile: tools/skills_hub.py:3294 writes ensure_ascii=False JSON, while :3288 reads without an encoding; tools/skills_sync.py:405 also reads that lock file without one.
• The diff adds no regression test. The existing HubLockFile coverage at tests/tools/test_skills_hub.py:1334-1402 does not exercise non-ASCII persistence.

Suggested changes

• Update the paired cache reads, lock-file producer/consumers, and add a non-ASCII round-trip regression test. The verified open #47489 diff already covers these related paths.

Automated hermes-sweeper review.

[teknium1]

Please update the paired read_text() calls too (_read_cache at current main line 1045 and _read_index_cache at line 3234). Writing UTF-8 while reading through the Windows default locale does not preserve the non-ASCII metadata this change is intended to protect.

[AlexFucuson9]

Superseded by #64822 — adds encoding='utf-8' to all paired cache/lock reads in skills_hub and skills_sync.