Changing a skill's visual identity should not require uploading another package. Access changes also need a clear boundary: making a skill public and making it private have different consequences. We ran SkillHub v0.2.23 locally and recorded those paths, plus the invitation history left by a successful team join.
Watch the actual workflow: English short · 中文短视频.
What actually ran
SkillHub is an open-source, self-hosted registry for agent skills. This demonstration used the exact v0.2.23 release commit, 2fe1a44059f51c1fa2e72ea3f1f3d59942e1e8be. We fetched the current source first; the fetched main branch was 19 commits ahead, so we selected the release tag to keep this walkthrough specific to v0.2.23.
The local development sandbox ran the unmodified Java 21 backend, web frontend, PostgreSQL 16.4, Redis 7.2.12, and Cisco AI Skill Scanner 2.1.0. It used the project's documented local development identities and synthetic demonstration data. The screenshots below are landscape crops from the same native product recordings used in the video.
1. Save an avatar without creating another package version
In My Skills, we chose an image, adjusted the native crop, and saved the avatar. The result appeared on the skill detail page. The demonstration skill remained @studio/brand-brief, with display name Release Intelligence and package version v1.0.0. No replacement skill package was uploaded for this change.
The useful distinction is between presentation and installation identity. The avatar and display name help people recognize a skill; its installation coordinate identifies the package. In this run, the avatar update preserved that coordinate and version.
2. Public expansion waits for review; private restriction applies immediately
We requested a change from Private to Public. It remained private while the request waited for review. After the existing scan and administrator review completed, the same skill's page showed Public.
We then tightened the scope back to Private. This restriction took effect immediately, with no new review task and no new package version. The recorded result still showed v1.0.0.
This is an asymmetric boundary: expanding access goes through review; restricting access can take effect immediately. The video uses an explanatory animation between the original operation and the same skill's recorded result.
3. A successful invitation leaves a readable join record
A recipient confirmed the join in the native invitation page. The team gained one new member. Opening invitation history showed Used, the joining identity Local Developer, and the join timestamp. These are fictional local identities, not production users.
The interface states that one new member can use an invitation within its validity window. Our recording demonstrates one successful new-member join and its history. Invitation history records the join; it does not represent current membership. Reopening the link as the same member was idempotent, so we do not present that as a test with a second new recipient.
Repeat the demonstrated workflow
Start with the deployment and user documentation. For the same version-specific walkthrough, select the v0.2.23 release. In a test environment, open My Skills, choose a skill you own, and follow its avatar settings. Check the coordinate and version after saving. For access changes, compare the pending review and approved result; check the restriction after changing back to Private. Invitation history is under team member management.
The result is concrete: a recognizable new avatar while the package version stays put, an explicit boundary for wider access, and a trace of the successful team join.
Source: iflytek/skillhub · v0.2.23 release notes.
Top comments (0)