// the find
iflytek/skillhub
Self-hosted, open-source agent skill registry for enterprises. Publish & version skill packages, govern with RBAC and audit logs, deploy on-premise with Docker or Kubernetes.
SkillHub is a self-hosted registry for AI agent skills — think npm for the prompts, tools, and context files that agent platforms like Claude Code, Cursor, or Codex consume. Built by iFlytek, it adds versioning, RBAC, namespaces, and an audit trail on top of what would otherwise be a folder of markdown files. Aimed at enterprises that want to share agent skills internally without sending them to a public registry.
The multi-agent profile detection in the CLI is genuinely useful: it sniffs the running agent (Claude Code, Cursor, Codex, Windsurf, Gemini CLI, etc.) and installs skills to the correct directory without the user specifying it. The two-tier governance model — team admins gate namespace promotion, platform admins gate global promotion — maps cleanly onto how real enterprise org charts work, not just role checkbox theater. The CI pipeline is thorough: OpenAPI drift detection via a script that boots the backend and regenerates the schema, E2E tests, security scanning, and a smoke-test script you can point at any environment. They also dogfood their own skill format in `.agents/skills/` to document the codebase for AI coding assistants — a small but honest signal that the format is practical.
The quick-start curl-pipe-to-sh pulls from `imageless.oss-cn-beijing.aliyuncs.com`, a Chinese Aliyun CDN. For a product whose entire pitch is on-premise data sovereignty and enterprise trust, this is a hard no for most enterprise security teams before they've read a second line. Spring Boot 3.2.x is pinned in the architecture section and reached end-of-life in November 2024 — there will be CVEs accumulating that aren't getting backported. The 'open standard' framing is undermined by the integration list: AstronClaw, Loomy, and astron-agent are all iFlytek products; OpenClaw is iFlytek-adjacent. Third-party agent platforms have no reason to adopt this over just shipping a folder. The Kubernetes manifests are starter-grade — no resource limits, no HPA, no PodDisruptionBudgets — so 'enterprise Kubernetes deployment' needs significant additional work before it holds up under real operational scrutiny.