Skill package loading experiment #1378
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit adds the ability to load skills from installed OpenHands skill packages, enabling reusable skill distribution across projects. Features: - Package discovery using Python entry points - Configuration via .openhands/packages.yaml - Functions to list, load, and inspect skill packages - Integration with existing skill loading infrastructure - Comprehensive tests and documentation - Example demonstrating all features New files: - openhands-sdk/openhands/sdk/context/skills/package_loader.py - tests/sdk/context/skill/test_package_loader.py - examples/01_standalone_sdk/04_use_skill_packages.py - docs/skill-packages.md - .openhands/packages.yaml (template) Related to: https://github.com/OpenHands/package-poc
Update package_loader.py to support both manifest.json (Claude Code format) and skill-package.yaml (legacy format), with manifest.json taking priority. This aligns the software-agent-sdk with the OpenHands package-poc refactoring (PR #17) that migrated from YAML to JSON-based manifests for cross-ecosystem compatibility with Claude Code. Changes: - Add _load_package_descriptor() helper function that tries manifest.json first, then falls back to skill-package.yaml - Update list_skill_packages() to use the new helper - Update get_skill_package() to use the new helper - Add json import for manifest parsing - Add type checking for triggers data Tested with openhands-simple-code-review package using manifest.json format. Co-authored-by: openhands <openhands@all-hands.dev>
Convert Claude Code manifest.json format to skill-package.yaml structure to maintain compatibility with existing code that expects the nested format. Changes: - Add _normalize_manifest() helper to convert flat manifest structure to nested metadata/spec structure - Handle both string and dict author formats - Map keywords to tags field - Extract repository URL from repository object This allows the SDK to seamlessly work with both manifest.json (Claude Code) and skill-package.yaml (legacy) formats. Co-authored-by: openhands <openhands@all-hands.dev>
BREAKING CHANGE: Skill packages must now use manifest.json format only. The legacy skill-package.yaml format is no longer supported. This aligns with PR #17 in package-poc which fully migrated to the Claude Code manifest.json standard. Packages without manifest.json will fail to load with a clear error message. Changes: - Remove fallback to skill-package.yaml in _load_package_descriptor() - Update error messages to indicate manifest.json is required - Update docstrings and comments to reflect manifest.json-only support - Keep _normalize_manifest() to convert Claude Code flat structure to internal nested structure Note: yaml import is retained for loading user configuration files (.openhands/packages.yaml), not package descriptors. Co-authored-by: openhands <openhands@all-hands.dev>
|
Looks like there are a few issues preventing this PR from being merged!
If you'd like me to help, just leave a comment, like Feel free to include any additional details that might help me get this PR into a better state. You can manage your notification settings |
- Updated test_package_loader.py to use manifest.json format instead of YAML - Fixed E501 line too long issue in skill package example - Renamed 04_use_skill_packages.py to 31_use_skill_packages.py for correct numbering Co-authored-by: openhands <openhands@all-hands.dev>
Contributor
Coverage Report •
|
||||||||||||||||||||
yamlfmt hook added the standard --- separator Co-authored-by: openhands <openhands@all-hands.dev>
jpshackelford
added a commit
that referenced
this pull request
Dec 19, 2025
…ll_packages.py - Updated example code to access flat manifest.json structure instead of nested metadata/spec - Fixed descriptor access patterns: descriptor['displayName'] instead of descriptor['metadata']['displayName'] - Renamed from 04_use_skill_packages.py to 31_use_skill_packages.py to match PR #1378 - Updated documentation reference to point to new filename - Added defensive handling for author and repository fields that can be string or object Co-authored-by: openhands <openhands@all-hands.dev>
Contributor
Author
|
Closed in favor of #1399 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Experimental support for loading skills from installed packages via entry points.
See
docs/skill-packages.mdandexamples/01_standalone_sdk/04_use_skill_packages.pyfor details.@jpshackelford can click here to continue refining the PR
Agent Server images for this PR
• GHCR package: https://github.com/OpenHands/agent-sdk/pkgs/container/agent-server
Variants & Base Images
eclipse-temurin:17-jdknikolaik/python-nodejs:python3.12-nodejs22golang:1.21-bookwormPull (multi-arch manifest)
# Each variant is a multi-arch manifest supporting both amd64 and arm64 docker pull ghcr.io/openhands/agent-server:92b0578-pythonRun
All tags pushed for this build
About Multi-Architecture Support
92b0578-python) is a multi-arch manifest supporting both amd64 and arm6492b0578-python-amd64) are also available if needed