Skip to main content

​
प्रकाशन

प्रकाशन आपके चुने हुए स्वामी के अंतर्गत किसी skill फ़ोल्डर या plugin पैकेज को ClawHub पर भेजता है। ClawHub जांचता है कि आपका टोकन उस स्वामी के लिए प्रकाशित कर सकता है, metadata, नाम, संस्करण, फ़ाइलें और source जानकारी को validate करता है, फिर release को संग्रहीत करता है और स्वचालित सुरक्षा जांच शुरू करता है। यदि validation विफल होता है, तो कुछ भी प्रकाशित नहीं होता। नए releases सामान्य install और download surfaces से तब तक बाहर भी रह सकते हैं जब तक review पूरा नहीं हो जाता।

​
Skills

सबसे सरल प्रकाशन पथ CLI है। साइन इन करें, फिर एक local skill फ़ोल्डर प्रकाशित करें: 
clawhub login
clawhub skill publish ./my-skill \
  --slug my-skill \
  --name "My Skill" \
  --owner <owner>
किसी org स्वामी पर प्रकाशित करते समय --owner <handle> का उपयोग करें। authenticated user के रूप में प्रकाशित करने के लिए इसे छोड़ दें। प्रकाशन अपरिवर्तित content को छोड़ देता है। एक नया skill 1.0.0 से शुरू होता है, और बाद के बदलाव स्वतः अगला patch संस्करण प्रकाशित करते हैं। --version केवल तब पास करें जब आपको स्पष्ट संस्करण चाहिए। catalog repos के लिए, ClawHub के reusable skill-publish.yml workflow का उपयोग करें। यह root के अंतर्गत प्रत्येक immediate skill फ़ोल्डर के लिए skill publish कॉल करता है (default: skills), या केवल skill_path के रूप में दिए गए फ़ोल्डर के लिए। 
jobs:
  publish:
    uses: openclaw/clawhub/.github/workflows/skill-publish.yml@main
    with:
      owner: <owner>
      dry_run: false
    secrets:
      clawhub_token: ${{ secrets.CLAWHUB_TOKEN }}
प्रकाशित किए बिना नए और बदले हुए skills का preview करने के लिए dry_run: true का उपयोग करें।

​
Plugins

Plugins npm-style package names का उपयोग करते हैं। scoped package names में नाम के पहले भाग में स्वामी शामिल होता है: 
@owner/package-name
scope चयनित publish स्वामी से मेल खाना चाहिए। यदि आपके package का नाम @openclaw/dronzer है, तो इसे केवल @openclaw के रूप में प्रकाशित किया जा सकता है। यदि आप @vintageayu के रूप में प्रकाशित करते हैं, तो package का नाम बदलकर @vintageayu/dronzer करें। यह किसी package को ऐसे org namespace का दावा करने से रोकता है जिसे publisher नियंत्रित नहीं करता। यदि आप किसी org, brand, package scope, owner handle, या namespace के rightful owner हैं जो ClawHub पर पहले से claim या reserve किया गया है, तो public, non-sensitive proof के साथ एक Org / Namespace Claim issue खोलें। क्या शामिल करना है और public issues से क्या बाहर रखना है, इसके लिए Org और Namespace Claims देखें।

​
Plugin प्रकाशित करने से पहले

  • ऐसा स्वामी चुनें जो package scope से मेल खाता हो।
  • openclaw.plugin.json शामिल करें। code plugins को openclaw.compat.pluginApi और openclaw.build.openclawVersion के साथ package.json भी चाहिए।
  • custom plugin card icon दिखाने के लिए, किसी भी HTTPS image URL के साथ openclaw.plugin.json में icon जोड़ें।
  • source repository और exact commit metadata शामिल करें, या GitHub-backed checkout से CLI का उपयोग करें ताकि यह उन्हें detect कर सके।
  • प्रकाशित करने से पहले clawhub package validate <source> चलाएं। package, manifest, SDK import, या artifact findings के लिए, Plugin validation fixes देखें।
  • release बनाने से पहले clawhub package publish <source> --dry-run चलाएं।
  • नए releases के public install surfaces से बाहर रहने की अपेक्षा करें जब तक automated security checks और verification पूरा न हो जाए।

​
Packages के लिए trusted publishing

Package trusted publishing दो-चरणीय setup है:
  1. सामान्य manual या token-authenticated clawhub package publish के माध्यम से package को एक बार प्रकाशित करें। यह package row बनाता है और उन package managers को स्थापित करता है जो इसकी trusted publisher config बदल सकते हैं।
  2. एक package manager GitHub Actions trusted publisher config set करता है:
clawhub package trusted-publisher set @owner/package-name \
  --repository owner/repo \
  --workflow-filename package-publish.yml
config set होने के बाद, future supported GitHub Actions publishes repository में long-lived ClawHub token संग्रहीत किए बिना OIDC/trusted publishing का उपयोग कर सकते हैं। configured repository और workflow filename GitHub Actions OIDC claim से मेल खाने चाहिए। यदि आप --environment <name> भी पास करते हैं, तो GitHub Actions environment claim को उस नाम से exact match करना होगा। trusted publisher config set होने पर ClawHub configured GitHub repository को verify करता है। Public repositories को public GitHub metadata के माध्यम से verify किया जा सकता है। Private repositories के लिए ClawHub को उस repository तक GitHub access चाहिए, उदाहरण के लिए future ClawHub GitHub App installation या किसी अन्य authorized GitHub integration के माध्यम से। current reusable package publish workflow workflow_dispatch publishes के लिए secretless trusted publishing support करता है जब id-token: write उपलब्ध हो। Tag-push real publishes को अभी भी clawhub_token चाहिए, इसलिए tag releases, first publishes, untrusted packages, या break-glass publishes के लिए CLAWHUB_TOKEN उपलब्ध रखें। config inspect या remove करें: 
clawhub package trusted-publisher get @owner/package-name
clawhub package trusted-publisher delete @owner/package-name
trusted publisher config हटाना rollback path है। यह future trusted publish token minting को तब तक disable करता है जब तक कोई package manager फिर से config set नहीं करता।

​
FAQ

​
Package scope चयनित स्वामी से मेल खाना चाहिए

यदि package scope और चयनित स्वामी मेल नहीं खाते, तो ClawHub publish को reject करता है: 
Package scope "@openclaw" must match selected owner "@vintageayu".
Publish as "@openclaw" or rename this package to "@vintageayu/dronzer".
इसे ठीक करने के लिए, या तो package scope द्वारा named स्वामी चुनें, या package का नाम बदलें ताकि scope उस स्वामी से मेल खाए जिसके रूप में आप publish कर सकते हैं। यदि package name में पहले से सही scope है लेकिन package गलत publisher के स्वामित्व में है, तो ownership transfer करें: 
clawhub package transfer @opik/opik-openclaw --to opik
package या skill transfer का उपयोग केवल तब करें जब आपके पास current owner और destination publisher दोनों का admin access हो। Package transfer आपको ऐसे scope में publish करने की अनुमति नहीं देता जिसे आप manage नहीं कर सकते। यदि आपके पास current owner तक access नहीं है लेकिन आपको लगता है कि आपका org, project, या brand rightful namespace owner है, तो staff review के लिए public, non-sensitive proof के साथ एक Org / Namespace Claim issue खोलें। file करने से पहले Org और Namespace Claims देखें। यह org namespaces की रक्षा करता है। @openclaw/dronzer नाम का package @openclaw namespace का दावा करता है, इसलिए केवल @openclaw स्वामी तक access रखने वाले publishers ही इसे publish कर सकते हैं।