Resource Hub

https://app.example.com is an example address. Replace it with the actual address of your environment, retaining the route path and query parameters.

1. Configuration Goal

Use Resource Hub to create and maintain Skill, Work, and Connector resources in one place, organize resource files, save drafts, sync from Git, publish versions, and prepare resources for publication to Explore.

Resources in Resource Hub are managed as Named Draft → validation → Immutable Version. A published version is a fixed snapshot; later editing or Git synchronization does not modify a published version in place.

2. Configuration Entry

Configuration entry: Resources → Resource Hub

app.example.com is an example domain. During actual operation, replace it with the AOS Work access domain for the customer environment. Keep the route path /admin/resource-hub unchanged.

The Resource Hub list provides:

• New Resource: Create a resource;
• Search resources: Search the current Resource Hub list;
• Type: Filter by resource type;
• Source: Filter by resource source;
• List fields: Resource, Description, Type, Source, Latest Version, and Updated.

3. Pre-configuration Checklist

Before starting, confirm:

1. The current administrator has permission to view Resource Hub, create resources, edit drafts, sync from Git, and publish versions;
2. The resource type is confirmed: Skill, Work, or Connector;
3. The resource name, draft name, and description are confirmed;
4. If creating from Git, the corresponding repository connection is complete according to 06 Git Repository Configuration, and its Access scope matches the resource type;
5. If uploading locally, the resource folder or ZIP is ready;
6. Resource files contain no passwords, Tokens, API Keys, Access Tokens, private keys, or other sensitive values.

4. Resource Hub List

After opening Resource Hub, you can view resource name, description, type, source, latest version, and update time in the list.

4.1 Search and Filter

1. Enter a resource name or keyword in Search resources to search the current Resource Hub list;
2. Click Type to filter by Skill, Work, or Connector;
3. Click Source to filter by resource source;
4. Click a target resource row to open its details page.

Clicking a list row opens the same Resource Hub details page for settings, drafts, files, and versions. It does not open a right-side drawer.

5. Create a Resource

Click New Resource to open the creation dialog. Select Type and Source first, then fill in the resource information for the selected source.

5.1 Common Fields

After completing the fields, click Create to create the resource. Click Cancel to abandon the creation.

5.2 Create from Git

After selecting Git repository as the Source:

1. In Select a Git repository, select a Git repository whose type matches Type and whose connection test succeeded;
2. The system reads the repository's default branch and displays the source Commit and file preview;
3. Fill in Name, Draft name, and Description;
4. Confirm the preview content and source Commit;
5. Click Create to create the resource and its first Named Draft.

Resource Hub displays only repository connections matching the current resource type. The repository connection itself is not maintained on this page. To add or modify a connection, return to System → Git repositories.

5.3 Create from Local Upload

After selecting the local-upload source:

1. Upload a resource folder or ZIP;
2. Fill in Name, Draft name, and Description;
3. Wait for the system to parse the files and complete the basic structure check;
4. Review the file preview and confirm the resource directory and file contents;
5. Click Create to create the resource and its first Named Draft.

A local upload creates an editable draft and does not directly create a published version.

5.4 Start from Blank

After choosing to start from blank:

1. Select Type;
2. Fill in Name, Draft name, and Description;
3. Click Create;
4. Continue editing the resource content from the generated minimal file structure.

The system generates the minimal entry file for the resource type:

Blank creation generates only an editable draft. File maintenance and publication validation are still required before a version can be created.

6. Resource Details and Resource Settings

The resource details page consists of a global sidebar, a middle resource bar, and a right content area. The middle resource bar provides:

• Back to Resource Hub: Return to the resource list;
• Drafts & versions: View drafts and published versions;
• Resource Settings: Maintain basic resource information;
• Git Settings: View the repository binding and sync from Git;
• Draft or version selector;
• File tree for the current draft or version.

Maintain the following fields in Resource Settings:

Click Save settings after changing the name or description. Resource Settings does not edit files, publish versions, or sync from Git.

7. Drafts & versions and File Maintenance

In Drafts & versions, switch between Drafts and Versions to view the resource's Named Drafts and published versions. Version cards display information such as Version, Time, and Published by. Example version numbers represent existing records in the current interface and are not fixed values for new versions.

The draft selector is used only to switch between the current resource's Named Drafts and published versions. It does not display Git branches, tags, or commit lists. Creating a draft, syncing from Git, and creating a draft from a version each produces a new draft without overwriting existing drafts or published versions.

7.1 Edit Drafts and User-side Publication Policy

Distinguish the following two layers of behavior:

• Preview / Source, file-tree operations, and Save let an administrator edit the current resource draft;
• Publish policy defines, after the resource is published and mounted on the end-user side, how users and Agents access and modify a file or folder and how it is handled when the version is updated.

When editing a Named Draft:

1. Select a file or folder in the file tree;
2. Use Preview / Source to switch between preview and source editing modes;
3. Edit the content in source mode and click Save;
4. Create, upload, rename, delete, or move files or folders as needed;
5. Select the file or folder whose user-side behavior needs to be controlled and open Publish policy;
6. Configure Access and Updates separately in the publication policy, then save the draft and publish the version.

The required entry file for Skill, Work, and Connector is SKILL.md. This file can be edited but cannot be deleted from the file tree.

7.2 Access: Control Whether End Users Can Modify Content

Access controls whether users and Agents can modify a file or folder after the resource is published and mounted on the end-user side. All paths are readable by default. This setting controls whether writing is allowed; it does not control whether the administrator can edit the draft.

After selecting a file or folder, open Publish policy and select an Access option:

Configuration steps:

1. Select the target file or folder in the file tree;
2. Open Publish policy and enter Access;
3. Select Read-only or Writable according to whether the user side should be allowed to modify the path;
4. Click Save at the top of the editor to save the draft;
5. After publishing the version, the user side follows the access policy in that version.

Files and folders save their own Access states. A parent folder's access state is not automatically applied to child nodes. To control a specific file, select and configure that file directly. The access policy in a published version is read-only; to adjust it, first use Create Draft from Version to create a new draft.

7.3 Updates: Control Whether User-side Files Are Kept During Version Updates

Updates controls how existing content at the same path on the end-user side is handled when a new resource version is published and updated there. This setting distinguishes files maintained uniformly by the resource version from files that allow users to retain personalized content.

After selecting a file or folder, open Publish policy and select an Updates option:

Configuration steps:

1. Select the file or folder whose update behavior needs to be defined;
2. Open Publish policy and enter Updates;
3. Select Overwrite when the new version should be authoritative, or Keep when user-side changes should be retained;
4. Click Save at the top of the editor to save the draft;
5. After publishing a new version, update the user-side resource according to that version's update policy.

Keep affects only later updates after the resource's initial installation and applies only to the explicitly configured file or folder node:

• When new-version content and user-side content exist at the same path, retain the user-side content;
• Keep is stored separately for files and folders and is not automatically applied from a parent folder to child nodes. Configure the specific file directly when necessary;
• When the new version deletes the target path, a retained user-side copy is not deleted;
• Keep and Writable can be used together: the former controls whether content is retained during updates, while the latter controls whether the user side can modify it;
• Keep in the file tree means that retention has been explicitly configured for the current node, and the published version will make that rule permanent.

For example, files holding user preferences or memory should generally use Writable and Keep according to the actual product design, allowing users to modify and retain them after resource-version updates. Static rule files may use Read-only and Overwrite. These combinations illustrate configuration approaches; confirm the actual choice based on the file's purpose.

After creating a Named Draft, a Git-sync draft, or a draft from Create Draft from Version, check the Access and Updates settings for each file and folder before publishing. These policies are not automatically inherited from parent folders or other nodes. If a retained path does not exist in the new file tree before publication, repair the path or remove the rule first.

8. Git Settings

Open Git Settings for a resource to view its Git repository binding and sync. The page includes:

• Bind repository: Bind a matching Git repository;
• Unbind: Remove the current binding;
• Sync from Git: Generate a new resource draft from the bound repository;
• Binding status: Display the current binding status;
• Git repository, Default branch, and Repository URL;
• Resource key, Resource path, and Last synced commit;
• Manage Git repositories: Open the Git repository connection management page.

8.1 Bind a Repository

1. Click Bind repository in Git Settings;
2. Select a Git repository connection matching the current Resource Type;
3. Confirm the repository, default branch, resource key, and resource path;
4. Save the binding;
5. Return to the page and verify Binding status.

Authentication credentials for the repository connection are managed centrally on the Git repositories page. Plaintext credentials are not stored in resource files or versions.

8.2 Sync from Git

1. Click Sync from Git in Git Settings;
2. Review the latest available Commit, repository, branch, and file-change summary;
3. Enter a new Draft name;
4. Confirm the sync;
5. Open the newly generated draft in Drafts & versions and check its file contents and structure.

Git synchronization always creates a new Named Draft and does not overwrite existing drafts or published versions. If synchronization fails, no new draft is created and existing drafts and versions are not modified.

9. Publish Versions and Type Validation

After confirming the files and configuration in the draft workspace, click Publish to create a version from the current draft. After publication succeeds, the original draft is retained and the generated version cannot be modified in place.

Before publishing, check at least these common conditions:

• The resource type is correct and its required entry file exists;
• The file tree, reference paths, and file summaries are valid;
• Every file and folder has a valid user-side Access policy;
• All Keep retention paths for Skill and Work point to valid files or directories, with no paths awaiting resolution;
• Resource files contain no credentials or other sensitive values;
• The version number is unique within the current resource.

9.1 Skill

• The resource root must contain SKILL.md;
• SKILL.md must be non-empty and contain parseable YAML frontmatter;
• Publication creates an immutable Skill Version.

9.2 Work

• The resource must contain SKILL.md as the required entry file for the Work Version;
• SKILL.md can be edited but cannot be deleted;
• The Work must contain at least one first-level member directory with <member>/SKILL.md;
• Every member file must contain parseable YAML frontmatter and a non-empty description;
• Member names must be safe and unique within the Work;
• Internal Skill files in a Work are published with the Work as a whole and do not form separate Skill Versions.

9.3 Connector

• The resource must contain SKILL.md as the required entry file for the Connector Version;
• SKILL.md must be parseable and declare the Connector ID, capabilities, authorization, invocation entry point, runtime dependencies, and status checks;
• Capability identifiers must be valid and unique;
• Authorization fields must clearly identify required, sensitive, and configuration-ownership information;
• Runtime dependencies, version constraints, and invocation entry points must be parseable;
• Resource files must not contain OAuth Tokens, API Keys, Access Tokens, real user accounts, or other sensitive values;
• Before publication, confirm that a minimal connection test and capability call have an executable path;
• Publication creates an immutable Connector Version.

10. Published Versions and Explore

In Versions, view published versions and the complete version history through View All Versions. Published versions display:

• Version;
• Published At;
• Published to Explore.

Published versions support:

• Compare with Draft: Select a Named Draft and compare it with the current version by file path;
• Create Draft from Version: Create a new Named Draft from the version snapshot;
• Create Explore Release: Carry the resource and target version into Explore Management to create an Explore publication.

When Published to Explore is Yes, the version record can open the publication configuration in Explore Management that references this version. A referenced version remains immutable.

11. Post-save Verification

1. Return to the Resource Hub list and search for the newly created resource name;
2. Verify Resource, Description, Type, Source, Latest Version, and Updated;
3. Open the resource details and confirm that the name, description, and read-only type in Resource Settings are correct;
4. Open Drafts & versions and confirm that the Named Draft exists and that the file tree and entry file are complete;
5. Verify user-side Access and Updates settings for files and folders, as well as Keep retention paths for Skill/Work;
6. If Git is used, open Git Settings and confirm the binding status, repository, default branch, resource path, and Last synced commit;
7. If a version has been published, confirm Version, publication time, and Published to Explore status;
8. Confirm that resource files, Git configuration, and version snapshots contain no sensitive credentials.

12. Completion Criteria

• The resource appears in the Resource Hub list with accurate name, description, type, and source;
• The resource type is Skill, Work, or Connector and remains locked after creation;
• The first Named Draft is created and its name is unique within the resource;
• The file tree, resource-type entry file, and end-user Access policy have been checked;
• If Skill/Work content must be retained on the user side, the Keep retention paths are confirmed valid;
• If Git is used, repository binding and synchronization information are correct, and synchronization creates a new draft;
• If external availability is required, the draft passes common and type-specific validation and is published as an immutable version;
• Passwords, Tokens, API Keys, private keys, and other sensitive values are not stored in resource versions or ordinary files.