LIFEHUBBER
Choose theme

AI Resources

OpenSpace

GitHub stars: 7.7K GitHub forks: 923 Declared license: MIT: MIT Last pushed August 12, 2026: Pushed 1mo ago
Stats from GitHub

OpenSpace is an HKUDS project for managing and running AI agent skills. It records skill use across tasks and supports fixes, derived variants and captured workflows.

The publisher documents a local skill library, optional cloud package discovery and one runtime used through CLI, Python API and MCP interfaces. Use this as a first read, not a recommendation. Open the original project before trusting details like terms, limits, privacy, cost, setup, or safety.

What it is

Skills with a record of use

OpenSpace stores task history, tool results and file changes alongside skill quality records. The library can therefore record what happened after a skill was found.

Why it stands out

Trust and reuse have separate controls

The project distinguishes provisional and trusted skills from whether a skill is enabled for reuse. A provisional skill can already be reused.

Availability

Local library, optional cloud hub

The publisher says local execution, search and evolution work without a cloud hub key. Model-provider configuration is separate from that hub access.

Why it matters

What makes it useful

When an agent finds a skill but still falls back to another approach, finding it was only part of the task. OpenSpace records selected, applied, completed and fallback outcomes separately. For someone checking a repeatedly used skill, those records distinguish discovery from actual use and completion.

Notable points

What stands out

A successful overall task is not enough for the publisher's CAPTURED workflow. Its README requires a source trace showing both execution of the reusable subworkflow and a separate validation of its claimed result. It also describes an independent semantic review before commit. For someone examining a captured skill, the relevant evidence is that particular subworkflow and its validation; the whole task need not have succeeded.

Before using

What to review

The configuration guide defaults evolution to autonomous, where admitted and validated FIX, DERIVED and CAPTURED actions may commit. It describes audit_only as recording the evolution decisions without skill writes, and fix_only as committing explicit direct FIX actions. Those modes answer whether skill changes can be written.

Execution permissions are separate: the same guide lists allow_shell_commands as true and sandbox_enabled as false by default, with per-backend policies. An audit-only evolution mode does not itself describe a sandbox for task execution.

Decide which task histories, tool results, file changes and generated skills to retain, remove or share. Review imported and evolved instructions before using them, and choose cloud package visibility and uploads deliberately.

Two open upstream reports describe poor multiword local ranking without embeddings and a Windows/Codex search_skills call that hangs after tool discovery. Their proposed fixes, pull requests 117 and 122, remain open as of 5 October 2026; adoption and independent reproduction are unverified.

Reader fit

Who may find it relevant

Builders and teams maintaining a reusable skill library can use the records to examine how their agents find, apply and change skills. For someone choosing between their own skill library and cloud discovery, the main README distinguishes local search_skills from cloud package discovery. cloud_browse_skills provides cloud discovery, and a selected cloud skill is imported locally before reuse. The configuration guide separately defines model credentials, so access to the skill hub does not configure the model that runs tasks.

Editorial note

Why LifeHubber lists it

A useful skill may be worth sharing, but its local track record is a separate thing from its instructions. OpenSpace's README requires a matching locally trusted SkillStore record for upload, while leaving that local trust state and the .skill_id sidecar out of the cloud package. This makes sharing an admission step rather than transferring the sender's trust label to another installation. For teams managing skills across agents, that boundary is an additional reason to examine the project alongside its local reuse and evolution records.

Source links

Source materials

Reader note

Before relying on this entry

LifeHubber lists entries to help readers inspect AI projects, not to endorse them or prove they are safe, suitable, accurate, maintained, or right for a specific use. We do not verify every entry in depth. Before relying on anything listed, review the original materials, terms, privacy practices, limits, and risks that matter for your situation.

What to explore next

Compare how agent skills change and earn trust.

OpenSpace manages skill quality across real runs. These next steps compare benchmark-driven skill evolution and a separate inspection layer for skills before reuse.

Advertisements

Advertisements

For project maintainers

Listed here? You can use the badge.

If you maintain a project with a current LifeHubber listing, you may add the optional “Listed on LifeHubber AI Resources” badge to its README, docs, or website. No introduction or permission request is needed.

See what’s moving