Сделайте плагин готовым для команды

Этот гайд начинается там, где заканчивается первый успешный плагин. Цель здесь не просто “оно работает у меня”, а репозиторий, который другой коллега может клонировать, проверить и использовать без скрытых устных договорённостей.

Итоговый результат

К концу у вас должно быть:

• репозиторий с package-standard layout
• generated-файлы, которые воспроизводятся из исходного состояния проекта
• строгая проверка готовности, которая проходит чисто
• явный выбор основного target’а или target’ов в scope, задокументированный для команды
• явный выбор runtime или runtime-политики по target’ам
• CI-friendly путь, который можно повторить на другой машине

1. Начните с самого узкого стабильного пути

Используйте самый сильный путь по умолчанию, если нет реальной причины поступить иначе:

plugin-kit-ai init my-plugin
cd my-plugin
plugin-kit-ai generate .
plugin-kit-ai validate . --platform codex-runtime --strict

Это даёт самую чистую базу для дальнейшего handoff.

2. Сделайте выбор явным

Для team-ready repo должно быть явно сказано как минимум:

• какой target является основным и какие ещё target’ы реально поддерживаются
• какой runtime используется и меняется ли он по target’ам
• какая команда является главной командой проверки, или какой набор команд нужен для multi-target repo
• зависит ли репозиторий от Go SDK path или от shared runtime package

Если эта информация живёт только в голове одного maintainer'а, репозиторий ещё не готов.

3. Держите репозиторий честным

Прежде чем расширять проект, зафиксируйте три правила:

• исходное состояние проекта живёт в package-standard layout
• generated target files являются outputs
• generate и validate --strict остаются частью обычного workflow

Не патчите generated-файлы вручную и не надейтесь, что команда просто не будет заново запускать генерацию.

4. Добавьте повторяемый CI gate

Минимальный gate должен выглядеть так:

plugin-kit-ai doctor .
plugin-kit-ai generate .
plugin-kit-ai validate . --platform codex-runtime --strict

Если выбран Node или Python путь, добавьте bootstrap и зафиксируйте версию runtime в CI.

Если repo поддерживает несколько target’ов, CI gate должен явно проверять каждый из них, а не надеяться на косвенную совместимость.

5. Проверьте, действительно ли вам нужен другой путь

Уходите от пути по умолчанию только тогда, когда компромисс действительно оправдан:

• используйте claude, когда Claude hooks — это реальное product requirement
• используйте node --typescript, когда команда TypeScript-first и локальный runtime-путь действительно приемлем
• используйте python, когда проект сознательно остаётся локальным для репозитория и Python-first

Смена пути должна решать продуктовую или командную задачу, а не просто отражать вкусы по языку. Если продукт реально multi-target, формулируйте это прямо: у repo есть primary path и дополнительные target’ы в поддерживаемом scope.

6. Сделайте handoff видимым

Новый коллега должен суметь ответить на такие вопросы по repo и docs:

• как установить prerequisites?
• какая команда доказывает, что репозиторий в порядке?
• под какой target идёт validation?
• какие файлы являются исходным состоянием проекта, а какие — generated?

Если ответ на любой из этих вопросов — “спроси исходного автора”, значит репозиторий ещё не готов.

7. Привяжите repo к публичному контракту

Такой repo должен вести людей на:

• Готовность к продакшену
• Интеграцию с CI
• Стандарт репозитория
• текущий публичный release note, сейчас это v1.0.6

Финальное правило

Репозиторий действительно готов, когда другой коллега может его клонировать, понять path и target scope, воспроизвести generated outputs и пройти strict validation gate без импровизации.

Свяжите этот гайд с Первым плагином, Архитектурой авторинга и Границей поддержки.