Agent skill · software engineering · nexu-io
od-share-to-community
Package the user's just-finished work as an OpenDesign plugin without asking for fields the project files already answer, then surface the existing Add-to-My-plugins / Open-Design-PR buttons.
Why this skill is useful
Adds a complete executable workflow for packaging and validating Open Design plugins, including error handling and metadata generation.
What it needs
Requires gh, od installed locally. Requires github account access. About 4k tokens when loaded. Last updated 2026-08-07. 84,236 stars on the source repository.
What this skill does
od-share-to-community (scenario) Triggered by the post-completion "Share to OpenDesign" submission action. The user just finished a piece of work in this project and wants to ship it as a plugin. They have not been asked any questions yet. Required outcome Produce a folder named generated-plugin/ in the active project workspace. At minimum: SKILL.md with frontmatter and clear agent instructions. open-design.json with valid plugin metadata: specVersion, name, version, description, mode, task kind, inputs, plus any pipeline / context references the workflow needs. plugin.repo is optional during scaffolding, but do not silently omit it: check gh --version and gh auth status, then prefer the local account login printed by auth status. Only use gh api user --jq .login as a fallback when auth status does not expose a login. If gh is missing, not logged in, rate-limited, or cannot resolve a real owner, omit plugin.repo instead of inventing an owner and explicitly report the auth problem with gh auth refresh -h github.com -s repo,workflow, gh auth login -h github.com -s repo,workflow, or od plugin publish-repo generated-plugin --owner <github-login-or-org> as recovery commands. Never write placeholder owners such as open-design-user, <vendor>, example-user, your-org, or your-username into the final manifest. Optional examples/ and assets/ only when they help review or reuse. Auto-derive from the project — do not ask the user fields the files already answer The agent's CWD is the user's OD project root. Before generating anything, read what's already there and infer the plugin from it. Treat the project files as the source of truth; the user does not need to retype things you can see. What to read, in this order, and what to take from each: 1. .artifact.json (or artifact.json) at the project root — task kind, mode, the prompt the user actually ran, the file the agent produced. This drives od.taskKind, od.mode, the default useCase.query, and the example output path. 2. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills nexu-io/od-share-to-community