feat(skills) add Hypit to the Skill Hub catalog

[QuanCheng-QC]

What

Adds Hypit to the Skill Hub catalog. Hypit is a video authoring toolkit for AI agents,
distributed as an Agent Skill rather than as an agent of its own, so it enters through the
catalog and not the agent registry. The entry points at hypit-ai/hypit, path skills/hypit.

Why that path only works now

The skill used to live at .agents/skills/hypit. _assertSafeSourcePath requires every
segment of a source_path to begin with [A-Za-z0-9], so a dot-prefixed path is rejected
outright and the skill could not be addressed at all. Hypit has since moved it to a dot-free
repository source, which lets us fetch it unchanged.

Four places carry a catalog skill

File	Change
workspace/backend/app/skill_catalog.py	the entry the installer resolves through find_skill
workspace/frontend/components/skills/skills-view.tsx	the Skill Hub grid keeps its own list
workspace/frontend/lib/i18n/messages/{en-US,zh-CN}.ts	the skills.catalog.hypit description

packages/agent-connector/src/skill-catalog.js is the workspace module catalog and is
unrelated — third-party skills do not go there.

Category

ai-ml, following the closest precedent in the file: SenseNova Image Gen is also a generation
skill and is filed there. A category of its own is worth doing once more Hypit skills land; one
entry does not justify a filter tab with a single card in it.

Verification

Installed through the real Skill Hub UI on two platforms, using this exact entry.

Linux. The install lands 56 files in <workingDir>/.claude/skills/hypit,
listInstalledSkills reports it, and uninstall leaves the directory clean — checked for both
claude and codex agent types. A Claude agent then discovered the skill on its own, followed
its environment gate, selected a Distribution, established a project boundary, wrote a runtime
profile and drove the real Hypit CLI. It stopped at credential resolution, which is a Hypit
platform limit rather than an integration failure: packages/credential-store-os throws on
anything that is not darwin or win32, and Hypit's own environment.md lists only macOS 13+ and
Windows 10/11 as supported hosts.

Windows. Same install path, then the step Linux could not reach — HypiHub OAuth completed
and the credential was written to the OS credential store, FFmpeg 9.0.1 went on PATH, and
hypit runtime up began provisioning. The chain works end to end on a supported host.

The backend catalog loads with 67 entries and unique ids; the frontend typechecks
(tsc --noEmit, exit 0).

Merge timing

hypit-ai/hypit is still private and the installer clones over anonymous HTTPS, so an install
fails today for anyone whose git has no read access to it. Hypit expects to open the repository
within days. Until then this entry only works where such access is configured, so it is worth
holding the merge until the repository is public rather than shipping a catalog card that cannot
install.

Follow-ups found while testing

Not fixed here — separate PRs. All are in the install path and all are reproducible:

1. installSkill fetches with execFileSync, freezing the entire daemon event loop for the
   length of the clone (15s in one run). Every other adapter's poll and heartbeat then dies with
   socket hang up at the moment the loop resumes.
2. git clone --sparse fails on older git, which reports cannot change to '<url>' and
   installs nothing. A --no-checkout + sparse-checkout + checkout sequence gives an
   identical result at the same speed and works on every version.
3. installSkill clears its destination with readdir + rmSync, both of which follow symlinks,
   so installing into a repository that symlink-shares its skills directory deletes the real
   source files.
4. Unrelated failures collapse into one line. A mirror rewrite conflict, an old git, a reset
   connection and a missing git on the daemon's PATH all surface as could not fetch skill,
   with git's own stderr swallowed. The health probe has the same shape of problem: a silently
   retried auth failure is reported as "may be waiting for interactive input".
5. Claude's check_ready.creds_file disagrees across the three registry sources #631 now has a live reproduction. A working Windows agent is reported as Not logged in
   because check_ready.creds_file points at ~/.claude/sessions, which is session bookkeeping
   rather than credentials.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
openagents-workspace	Ready	Preview	Sep 4, 2026 11:47am UTC

[zomux]

Approve. Clean four-place catalog entry (backend skill_catalog, frontend grid, en+zh i18n), consistent ids/paths, source_path passes _assertSafeSourcePath, category precedent reasonable, and the verification is unusually strong for a catalog card — real Skill Hub installs on Linux and Windows, end-to-end to a running Hypit CLI on a supported host.

Merge-timing note, decided consciously: hypit-ai/hypit is still private as of merge time (anonymous clone and API both 404), so the Install button will fail with 'could not fetch skill' until Hypit opens the repository. Maintainer chose to merge now rather than gate — the card reaches users only on the next production deploy, and the repo is expected public within days. If the timing inverts (deploy lands first), the failure is cosmetic and self-heals the moment the repo opens; no code change needed.

The five install-path follow-ups documented in the body (event-loop-freezing execFileSync clone, --sparse on old git, symlink-following destination clear, collapsed error reporting, and the #631 live repro) are genuinely valuable — please do file those as separate PRs/issues.