Передача пакета планувальнику інсталятора

Корисний результат передачі — каталог стандартного пакета та чіткий опис того, що було перевірено. Інсталятор одержувача складає власний план для обраних агентів та області. Інструменти розробки зі збірки з вихідного коду можуть надати докази, але на комп'ютері одержувача вони не потрібні.

Підготуйте пакет і докази

Оберіть каталог із кореневим plugin.json, а не неоднозначний батьківський репозиторій. Додайте:

• Назву, версію пакета та точну ревізію джерела або перевірений знімок.
• Відносний корінь пакета та призначення його Skills і MCP-серверів.
• Результати перевірки й огляду з версією інструмента або ревізією вихідного коду.
• Потрібні ідентифікатори клієнтів та результати сумісності для кожного компонента.
• Передумови виконання, потреби автентифікації та ще не перевірені аспекти.
• Кожен явний тест виконання з обраним сервером, інструментом і платформою.

Версія пакета та версія CLI описують різні речі. Зазначайте їх окремо. Не додавайте облікові дані та зайві абсолютні шляхи до діагностики для поширення.

Завершіть перевірки розробки, якщо вони доступні

Ці необов'язкові команди потребують збірки з увімкненими інструментами розробки, яка відрізняється від поточного випуску інсталятора:

agentplugins author validate ./review-helper
agentplugins author inspect ./review-helper
agentplugins author test ./review-helper
agentplugins author compat ./review-helper --target codex
agentplugins author doctor ./review-helper

Ця послідовність є статичною: вона не запускає код пакета та не читає профіль клієнта реального користувача. Якщо виконувалися явні перевірки виконання MCP, запишіть їх окремо. Успішна пряма перевірка виконання все ще не доводить виявлення нативним клієнтом або OAuth.

Запросіть план у випущеного інсталятора

agentplugins validate ./review-helper
agentplugins add ./review-helper --target codex --dry-run

Інсталятор може завантажувати метадані безпеки або сканер закріпленої версії навіть для локального джерела. Його перевірка й попередній перегляд не є автономними перевірками інструментів розробки.

Перша команда надає докази читання пакета інсталятором. Друга обирає Codex і показує план встановлення без застосування керованих змін. Для іншого клієнта оберіть підтримувану ціль за результатами сумісності. Для плану проєкту явно додайте --scope project --project-root /path/to/project.

Перевірте назву пакета, джерело, місця призначення, результати перевірок безпеки та подальші вимоги активації. До застосування усуньте розбіжності з передачею, яку задумав автор. План не є квитанцією про встановлений стан.

Надайте відтворюване джерело

Для віддаленого розповсюдження використовуйте джерело, яке приймає CLI одержувача: підписаний пакет Directory, точне джерело GitHub або підтримуване пряме джерело Git чи архів. Див. джерела встановлення щодо синтаксису й доступності. Для точного відновлення використовуйте незмінну ревізію або надійно збережений версійний архів. Локальний каталог потрібно окремо передати свідомо обраним способом.

CLI розробки з вихідного коду не надає команд публікації пакетів, експорту наборів чи подання до Directory. Розміщення вихідного коду — окремий крок від його перевірки. Оголошення залежностей у uap.toml — це контракт менеджера UAP; кореневий plugin.json залишається джерелом ідентифікаційних даних переносного пакета.

Поясніть, що залишається

Наданий доказ	Подальша робота
Відповідність стандарту	Корисні інструкції та правильна поведінка інструментів.
Статичні перевірки розробки	Схвалення випуску та кваліфікація публічного каналу.
Статична сумісність клієнтів	Фактичне нативне виявлення й активація.
Пряма перевірка виконання MCP, якщо проводилася	Інші інструменти, клієнти, автентифікація та неперевірені середовища.
Попередній перегляд інсталятора	Застосування перевірених змін і завершення налаштування клієнта.

Коли одержувач буде готовий до встановлення, він може перейти до використання плагінів. Зберігайте інструкції щодо довіри та активації для конкретних клієнтів разом із пакетом.