install

साझा प्रोफ़ाइल से एक हार्नेस अडैप्टर कॉन्फ़िगरेशन इंस्टॉल करें।

सारांशCopy Anchor Link

apothem install --harness NAME|all [--profile PATH] [--dry-run]
                 [--clean|--fresh] [--yes] [--project PATH]
                 [--quiet|-q] [--verbose|-v]
                 [--format plain|json] [--json] [--no-color]

साझा प्रोफ़ाइल को लोड और सत्यापित करता है, एक नामित अडैप्टर या रजिस्ट्री-व्यापी all सेट चुनता है, मूर्तीकरण योजना को सत्यापित करता है, और हार्नेस-नेटिव कॉन्फ़िगरेशन तथा समर्थन समूह लिखता है। प्रोजेक्ट-स्कोप अडैप्टरों को --project PATH की आवश्यकता होती है।

सतत-रूप उपनाम apothem installing (जो apothem Installing के रूप में भी स्वीकार किया जाता है) उसी हैंडलर पर रिज़ॉल्व होता है।

प्रोफ़ाइल के बिना पहला रनCopy Anchor Link

जब --profile छोड़ दिया जाता है और डिफ़ॉल्ट पथ (~/.config/apothem/profile.yaml) पर कोई प्रोफ़ाइल मौजूद नहीं होती, तो install पहले वहाँ स्टार्टर प्रोफ़ाइल लिखता है, Created a starter profile at <path> प्रिंट करता है, और आगे बढ़ता है। स्टार्टर प्रोफ़ाइल में प्लेसहोल्डर पहचान फ़ील्ड होते हैं, इसलिए इंस्टॉल प्लेसहोल्डर-पहचान नोट भी प्रिंट करता है; प्रोफ़ाइल को वैयक्तिकृत करें, फिर उसे लागू करने के लिए update चलाएँ। --json के अंतर्गत इस निर्माण की रिपोर्ट "operation": "profile_created" वाली एक warnings प्रविष्टि के रूप में की जाती है।

• --dry-run प्रोफ़ाइल कभी नहीं लिखता: पूर्वावलोकन मेमोरी में स्टार्टर प्रोफ़ाइल का उपयोग करता है और "operation": "profile_scaffold_preview" की रिपोर्ट करता है।
• एक स्पष्ट --profile PATH जो मौजूद नहीं है, कभी बनाया नहीं जाता; कमांड profile.not_found के साथ 1 पर बाहर निकलता है।

प्रभाव-त्रिज्या पूर्वावलोकनCopy Anchor Link

install --harness all मिश्रित स्कोप में फैलता है: प्रोजेक्ट-स्कोप अडैप्टर दिए गए --project रूट के अंतर्गत लिखते हैं, जबकि उपयोगकर्ता-स्कोप अडैप्टर आपकी होम डायरेक्टरी के अंतर्गत लिखते हैं — उस रूट के बाहर। कोई भी फ़ाइल लिखे जाने से पहले, कमांड ठोस टारगेट को दो शीर्षकों के अंतर्गत समूहबद्ध करके प्रिंट करता है: वे जो प्रोजेक्ट रूट के भीतर हैं और वे जो आपकी होम डायरेक्टरी के अंतर्गत हैं। एक तीसरा शीर्षक आपकी होम डायरेक्टरी के उन साझा फ़ोल्डरों को सूचीबद्ध करता है जिन्हें प्रोजेक्ट-स्कोप अडैप्टर --project के बाहर लिखते हैं: स्किल फ़ोल्डर और ~/.config/apothem/ (देखें आपकी होम डायरेक्टरी में फ़ोल्डर)। एकमात्र अपवाद --clean है: उसका क्लीन-स्लेट चरण इस पूर्वावलोकन से पहले चलता है, और वह एक बैकअप लिखता है तथा पिछले टारगेट हटाता है, जैसा नीचे वर्णित है।

जब चयन प्रोजेक्ट रूट के बाहर लिखता है, चाहे किसी होम-रूट वाले अडैप्टर के फ़ोल्डर में या किसी साझा फ़ोल्डर में, तो एक इंटरैक्टिव पुष्टि होम-रूट वाले लेखनों की रक्षा करती है। --yes, एक गैर-इंटरैक्टिव शेल (कोई TTY नहीं), --dry-run, और --format json में से प्रत्येक बिना प्रॉम्प्ट के आगे बढ़ता है। केवल --dry-run कुछ भी नहीं लिखता; --format json पूर्वावलोकन और पुष्टि-प्रॉम्प्ट को छोड़ देता है, पर फिर भी लेखन करता है। होम डायरेक्टरी वाले प्रॉम्प्ट को अस्वीकार करने पर इंस्टॉल लेखन से पहले ही रुक जाता है। --clean के साथ, क्लीन-स्लेट चरण पहले चलता है और उसकी अपनी प्रति-टारगेट पुष्टि होती है: वह ~/.apothem/backups के अंतर्गत एक बैकअप लिखता है और जिन टारगेट की पुष्टि होती है उन्हें हटाता है। इंस्टॉल प्रॉम्प्ट अस्वीकार किए जाने पर भी वे हटाने की कार्रवाइयाँ और बैकअप यथावत बने रहते हैं।

आपकी होम डायरेक्टरी में फ़ोल्डरCopy Anchor Link

सात प्रोजेक्ट-स्कोप अडैप्टर Apothem की स्किल, और वे नियम और टेम्पलेट जिनका स्किल हवाला देती हैं, आपकी उपयोगकर्ता होम के फ़ोल्डरों में लिखते हैं:

cursor, github-copilot, windsurf, zed  ->  ~/.agents/skills/ (codex writes it too)
codebuddy                               ->  ~/.codebuddy/skills/
kiro                                    ->  ~/.kiro/skills/
trae                                    ->  ~/.trae/skills/
all seven                               ->  ~/.config/apothem/rules/ and templates/ (codex uses them too)

• --project नियम फ़ाइल और वह प्रोजेक्ट चुनता है जिससे इंस्टॉल संबंधित है। यह नहीं बदलता कि स्किल कहाँ जाती हैं: --project A वाला इंस्टॉल और --project B वाला इंस्टॉल एक ही फ़ोल्डर लिखते हैं।
• किसी फ़ोल्डर का नाम लेने वाला हर इंस्टॉल वही फ़ाइलें लिखता है। दूसरा इंस्टॉल उन्हें पाता है और unchanged रिपोर्ट करता है, और आप किस क्रम में इंस्टॉल करते हैं, इससे कोई फ़र्क नहीं पड़ता।
• होम फ़ोल्डर प्रोजेक्ट में कुछ भी लिखे जाने से पहले लिखे जाते हैं। यदि वहाँ कोई लेखन विफल होता है, तो अडैप्टर का इंस्टॉल त्रुटि के साथ रुक जाता है और प्रोजेक्ट अपरिवर्तित रहता है। त्रुटि रास्ते में आने वाले पथ का नाम बताती है, उदाहरण के लिए ~/.agents नामक एक फ़ाइल जहाँ फ़ोल्डर होना चाहिए।
• प्रत्येक स्किल फ़ोल्डर उसके बगल में एक छिपे हुए .<name>.apothem-staging फ़ोल्डर में लिखा जाता है और पूरा होने पर उसका नाम बदलकर उसे जगह पर रखा जाता है, ताकि कोई विफल या बाधित लेखन कभी भी अपने अंतिम नाम के अंतर्गत आधा-लिखा स्किल फ़ोल्डर न छोड़े। पूरा करने के लिए इंस्टॉल फिर से चलाएँ; वह बचे हुए स्टेजिंग फ़ोल्डर को बदल देता है।
• इनमें से किसी फ़ोल्डर पर या उसके ऊपर का कोई सिमलिंक, जैसा डॉटफ़ाइल प्रबंधक ~/.config या ~/.agents के लिए बनाते हैं, तब अनुसरित किया जाता है जब वह आपकी होम डायरेक्टरी के भीतर कहीं ले जाता है। जो लिंक आपकी होम डायरेक्टरी से बाहर जाता है, वह इंस्टॉल को target escapes the allowed materialization root के साथ रोक देता है, और किसी स्किल फ़ोल्डर के भीतर का लिंक भी ऐसा ही करता है।
• इंस्टॉल आपकी रिपॉज़िटरी में कोई स्किल या नियम फ़ाइल नहीं जोड़ता। प्रोजेक्ट को अडैप्टर की नियम फ़ाइल मिलती है, साथ ही वह .apothem/ डेटा फ़ोल्डर जो हर प्रोजेक्ट इंस्टॉल बनाता है।
• जिस स्किल फ़ोल्डर का नाम किसी Apothem स्किल का है और जिसे Apothem ने नहीं लिखा, उसे छोड़ दिया जाता है। इंस्टॉल एक Warning: पंक्ति प्रिंट करता है और --format json एनवेलप में "outcome": "warning" और "operation": "skill_conflict" वाली एक warnings प्रविष्टि होती है जो फ़ोल्डर का नाम बताती है। फ़ोल्डर का नाम बदलें या उसे हटाकर कहीं और रखें, फिर update चलाएँ।
• ऐसा हर इंस्टॉल, अपडेट और ड्राई रन एक Note: प्रिंट करता है जो उन फ़ोल्डरों के नाम बताता है जिन्हें वह --project के बाहर लिखता है। JSON एनवेलप में यह "operation": "user_level_write" और एक paths सूची वाली एक warnings प्रविष्टि होती है।

क्षमता नोटCopy Anchor Link

प्रत्येक अडैप्टर केवल वे क्षमताएँ प्रक्षेपित करता है जिन्हें उसका हार्नेस नेटिव रूप से समर्थन करता है; जिन क्षमताओं की कोई नेटिव सतह नहीं है, उनकी रिपोर्ट की जाती है, उन्हें चुपचाप छोड़ा नहीं जाता। plain मोड में यह प्रति हार्नेस एक एकल समूहबद्ध नोट होता है (उदाहरण के लिए Note: <harness> - 9 capabilities not projected; pass --verbose for detail); --verbose के अंतर्गत प्रत्येक क्षमता अपनी अलग औचित्य पंक्ति प्रिंट करती है। कोई भी अन्य अडैप्टर चेतावनी plain मोड में भी अपनी अलग Warning: पंक्ति पर प्रिंट होती है, उदाहरण के लिए Zed की वह चेतावनी जो उस निर्देश फ़ाइल का नाम बताती है जिसे नई .rules छिपा देती है। --format json एनवेलप वर्बोसिटी की परवाह किए बिना हमेशा पूरी warnings ऐरे वहन करता है।

इंस्टॉल और अपडेट परामर्शों को भी Note: पंक्तियों के रूप में प्रिंट करते हैं। कोई परामर्श कभी नहीं बदलता कि इंस्टॉल क्या लिखता है। जब कोई इंस्टॉल एक साझा रूट लिखता है — एक ऐसा पथ जिसे अन्य टूल भी लोड करते हैं (उदाहरण के लिए स्किल फ़ोल्डर ~/.agents/skills/) — तो नोट उन टूल के नाम बताता है, और जो टूल उस पथ को केवल किसी शर्त के अंतर्गत लोड करता है उसे कोष्ठक में रखता है, उदाहरण के लिए Open-Claw (only under its default state directory)। जो इंस्टॉल ऐसा फ़ोल्डर लिखता है जिसे अन्य इंस्टॉल भी लिखते हैं (holder भूमिका), वह बताता है कि फ़ोल्डर तब तक बना रहता है जब तक उसका उपयोग करने वाला अंतिम Apothem इंस्टॉल अनइंस्टॉल नहीं हो जाता, और उन इंस्टॉल के नाम बताता है जो अभी उसका उपयोग करते हैं। जब कोई इंस्टॉल ऐसे टूल को लक्षित करता है जो किसी अन्य इंस्टॉल के साझा रूट से पहले ही Apothem सामग्री लोड करता है, तो नोट उस इंस्टॉल का नाम बताता है जिसने उसे रखा: पंजीकृत स्वामी, जब तक वह अभी भी फ़ोल्डर का उपयोग करता है, अन्यथा सबसे पुराना इंस्टॉल जो उसका उपयोग करता है। --format json एनवेलप में प्रत्येक परामर्श "outcome": "advisory" और "operation": "shared_root" वाली एक warnings प्रविष्टि होता है; उसकी role owner, holder, या reader होती है, holders फ़ोल्डर का उपयोग करने वाले इंस्टॉल सूचीबद्ध करता है, और owner_of_record अभिलिखित स्वामी का नाम बताता है।

जो इंस्टॉल हुक पंजीकृत करता है, वह हुक फ़ाइल के बारे में भी नोट प्रिंट करता है। एक hook_review परामर्श उस चरण का नाम बताता है जिसकी टूल को हुक चलाने से पहले आवश्यकता होती है (एक पुनरारंभ और एक समीक्षा, या वर्कस्पेस पर भरोसा करना), या ऐसी हुक फ़ाइल के जोखिम का जिसे कोई रिपॉज़िटरी कमिट करती है और जो इस मशीन के इंटरप्रेटर का नाम लेती है। एक hook_import परामर्श ऐसे टूल के लिए दिखाई देता है जो Claude Code की सेटिंग्स फ़ाइलों के हुक भी चलाता है, जैसे वे जिन्हें Claude Code के लिए Apothem इंस्टॉल लिखता है, और वह उस आयात को बंद करने के लिए टूल के अपने स्विच का नाम बताता है और यह भी कि वह स्विच और क्या रोकता है। प्रत्येक "outcome": "advisory", harness, हुक फ़ाइल के path और एक message वाली एक warnings प्रविष्टि होता है।

एक हुक कमांड प्रोजेक्ट पथ और इंटरप्रेटर पथ को दोहरे उद्धरण चिह्नों के भीतर रखती है, जिन्हें sh, Git Bash और PowerShell में से प्रत्येक पढ़ता है। जिस पथ में $, एक बैकटिक, एक दोहरा उद्धरण चिह्न या एक बैकस्लैश हो, वह कमांड से कोई अलग फ़ाइल चलवा देगा, इसलिए इंस्टॉल (और --dry-run) एक त्रुटि के साथ रुक जाता है जो पथ का नाम बताती है और कुछ भी नहीं लिखता; प्रोजेक्ट को कहीं और ले जाएँ या उसका नाम बदलें और उसे फिर से चलाएँ। पथ में एक स्पेस या एक एपॉस्ट्रॉफ़ी ठीक है।

प्रोफ़ाइल के MCP सर्वरों को तीन परामर्श मिलते हैं, जिनमें से प्रत्येक प्रोफ़ाइल फ़ील्ड का नाम बताता है:

क्रेडेंशियल परामर्श उस मान को कभी प्रिंट नहीं करता जो उसे मिला। जिस मान में ${...} संदर्भ होता है, उसे कभी फ़्लैग नहीं किया जाता।

टिप्पणियों वाले ऑपरेटर कॉन्फ़िगCopy Anchor Link

कुछ हार्नेस कॉन्फ़िग ऐसी फ़ाइलें हैं जिन्हें आप भी संपादित करते हैं, जैसे settings.json, opencode.json (जो JSONC हो सकती है), openclaw.json (JSON5), और config.yaml। इंस्टॉल अपनी कुंजियाँ इन फ़ाइलों में मर्ज करता है और आपके द्वारा जोड़ी गई हर कुंजी को बनाए रखता है।

मर्ज फ़ाइल को सादे JSON या YAML के रूप में फिर से लिखता है, जिससे टिप्पणियाँ, अनुगामी कॉमा और JSON5 सिंटैक्स हट जाएँगे। इसलिए:

• जब मर्ज किसी भी मान को नहीं बदलेगा (उदाहरण के लिए, आपने Apothem की कुंजियाँ पहले ही स्वयं जोड़ दी हैं), तो फ़ाइल को बाइट-दर-बाइट वैसा ही छोड़ दिया जाता है।
• जब मर्ज को ऐसी फ़ाइल में कोई मान बदलना हो जिसमें टिप्पणियाँ या JSON5 सिंटैक्स है, या ऐसी फ़ाइल में जो बिल्कुल पार्स नहीं होती, तो इंस्टॉल उस हार्नेस के लिए कुछ भी नहीं लिखता और त्रुटि कोड config.unparseable के साथ 1 पर बाहर निकलता है। fix फ़ील्ड उन कुंजियों के नाम बताता है जिन्हें इंस्टॉल जोड़ता, ताकि आप फ़ाइल को सादे JSON या YAML में बदल सकें, या उन कुंजियों को हाथ से जोड़कर फिर से चला सकें।
• जब कोई कुंजी जिसे इंस्टॉल एक मैपिंग या सूची से भरता है (उदाहरण के लिए config.yaml में skills.external_dirs) आपकी फ़ाइल में एक स्केलर मान, या दूसरा कंटेनर आकार, रखती है, तो इंस्टॉल उस हार्नेस के लिए कुछ भी नहीं लिखता और उसी त्रुटि कोड के साथ 1 पर बाहर निकलता है, क्योंकि कुंजी भरने से आपका मान नष्ट हो जाएगा। त्रुटि कुंजी का नाम बताती है; उसे उस आकार में बदलें जिसका वह नाम बताती है, या उसे हटा दें, और फिर से चलाएँ। जो कुंजी आपने खाली छोड़ी है (skills: जिसके नीचे कुछ नहीं है), उसे भर दिया जाता है।

विकल्पCopy Anchor Link

JSON आउटपुटCopy Anchor Link

जब --json (या --format json) दिया जाता है, तो stdout पर एक एकल JSON दस्तावेज़ लिखा जाता है:

{
  "schema_version": 1,
  "status": "success",
  "command": "install",
  "action": "installed",
  "harness": "claude-code",
  "profile_path": "C:\\Users\\Example\\.config\\apothem\\profile.yaml",
  "project": null,
  "files_written": ["C:\\Users\\Example\\.claude\\settings.json"],
  "results": [],
  "warnings": [],
  "error": null,
  "output_path": "C:\\Users\\Example\\.claude\\settings.json"
}

--dry-run के लिए कुछ भी नहीं लिखा जाता, और results हर वह पथ सूचीबद्ध करता है जिसे इंस्टॉल लिखता, प्रत्येक के साथ वह परिणाम जो उसका होता (created, updated या unchanged) और, ऐसी फ़ाइल के लिए जिसे आप भी संपादित करते हैं, detail.diff में यूनिफ़ाइड डिफ़ — वही योजना जो apothem diff दिखाता है:

{
  "schema_version": 1,
  "status": "dry_run",
  "command": "install",
  "action": "dry_run",
  "harness": "claude-code",
  "files_written": [],
  "results": [
    {
      "harness": "claude-code",
      "outcome": "created",
      "operation": "write_text",
      "path": "C:\\Users\\Example\\.claude\\settings.json",
      "message": "dry run: no filesystem changes made"
    }
  ],
  "warnings": [],
  "error": null
}

जब --clean दिया जाता है, तो एनवेलप अतिरिक्त रूप से एक clean ऑब्जेक्ट वहन करता है जो हटाने के चरण का वर्णन करता है — प्रति-टारगेट निपटान सूची, रन एक पूर्वावलोकन था या नहीं, और टाइमस्टैम्प वाली बैकअप डायरेक्टरी (ड्राई-रन में null):

{
  "clean": {
    "dry_run": true,
    "backup_dir": null,
    "targets": [
      {
        "path": "C:\\Users\\Example\\.claude",
        "present": true,
        "removed": false,
        "skipped_reason": null
      }
    ]
  }
}

एक क्लीन ड्राई-रन दोनों चरणों का पूर्वावलोकन एक ही दस्तावेज़ में करता है: clean के अंतर्गत हटाने का पूर्वावलोकन और results के अंतर्गत नए लेखन का पूर्वावलोकन।

अपेक्षित सत्यापन त्रुटियाँ उसी एनवेलप का उपयोग करती हैं और एक त्रुटि ऑब्जेक्ट शामिल करती हैं:

{
  "schema_version": 1,
  "status": "error",
  "command": "install",
  "harness": "all",
  "files_written": [],
  "error": {
    "code": "project.required",
    "field": "project",
    "reason": "project-scope harnesses require --project: cursor, gemini-cli, github-copilot, kimi-code, windsurf, codebuddy, kiro, trae, zed, glm.",
    "fix": "Pass --project PATH or select only user-scope harnesses."
  }
}

उदाहरणCopy Anchor Link

apothem install --harness claude-code
apothem install --harness claude-code --dry-run
apothem install --harness cursor --project . --profile ~/profile.yaml --json
apothem install --harness all --project . --dry-run --json
apothem installing --harness claude-code   # continuous-form alias
apothem Installing --harness claude-code   # capitalized variant

निकास कोडCopy Anchor Link

यह भी देखेंCopy Anchor Link

• apothem installing — इस कमांड का सतत-रूप उपनाम (यहाँ प्रलेखित; CLI दोनों रूप स्वीकार करता है)
• apothem update — किसी हार्नेस पर वर्तमान प्रोफ़ाइल फिर से लागू करें
• apothem verify — पुष्टि करें कि अडैप्टर सक्रिय है
• आरंभ करना — पूर्ण इंस्टॉलेशन गाइड