Перейти к основному содержимому

Приложение J. Как организовать хранилище skills в Git

Если skills становятся активом компании, их нельзя хранить в личных заметках, чатах и случайных документах.

Их нужно хранить так же дисциплинированно, как код, регламенты или архитектурные решения.

Практичный вариант — вести библиотеку skills в Git.

Git дает компании:

  • историю изменений;
  • review через PR или MR;
  • владельцев;
  • ветки для черновиков;
  • обсуждение изменений;
  • проверку качества;
  • возможность отката;
  • прозрачный путь от идеи сотрудника до опубликованного skill.

Это особенно важно, потому что skill является рабочим протоколом компании, а не личным промптом.

Главный принцип​

Любой сотрудник может предложить skill.

Но ни один skill не становится корпоративным стандартом без review.

Рабочая формула:

  1. Любой сотрудник может создать skill.
  2. Skill master помогает оформить и проверить.
  3. Владелец процесса подтверждает смысл.
  4. Review проверяет качество, безопасность и source of truth.
  5. После merge skill становится доступен команде.

Зачем Git, если сотрудники не разработчики​

На первый взгляд Git кажется инструментом разработчиков.

Для skills Git полезен как система управления изменениями.

Нужно знать:

  • кто предложил skill;
  • какую проблему он решает;
  • кто его проверил;
  • какие источники используются;
  • какие права нужны;
  • какие риски есть;
  • когда skill изменился;
  • почему старая версия была заменена;
  • кто утвердил публикацию.

Все это Git и PR/MR-процесс дают естественно.

Для сотрудников можно сделать простой интерфейс: форма, ассистент, шаблон, задача в трекере, бот или веб-страница. Но под капотом результат все равно попадает в Git как изменение в библиотеке skills.

Структура репозитория skills​

Пример структуры:

company-ai-skills/
  README.md
  skills/
    sales/
      proposal-draft/
        SKILL.md
        examples/
        evals/
      client-request-triage/
        SKILL.md
    delivery/
      project-status-summary/
        SKILL.md
      meeting-summary/
        SKILL.md
    engineering/
      task-context-bootstrap/
        SKILL.md
      mr-review/
        SKILL.md
    finance/
      invoice-draft/
        SKILL.md
    legal/
      contract-review/
        SKILL.md
  templates/
    skill-template.md
    eval-template.md
    review-checklist.md
  governance/
    roles.md
    review-policy.md
    publishing-policy.md
    deprecation-policy.md
  registry/
    skills-index.yaml

В малой компании структура может быть проще:

skills/
  proposal-draft/SKILL.md
  meeting-summary/SKILL.md
  contract-review/SKILL.md

Но даже в простом варианте у каждого skill должны быть владелец, версия и правила качества.

Что лежит внутри одного skill​

Минимальный состав:

skill-name/
  SKILL.md
  examples/
    good-result.md
    bad-result.md
  evals/
    cases.md
  README.md

SKILL.md содержит рабочий протокол.

examples/ показывает хорошие и плохие результаты.

evals/ хранит тестовые сценарии для проверки.

README.md можно использовать для пояснений владельцам и истории.

Если skill простой, можно начать только с SKILL.md, но по мере роста критичности лучше добавлять примеры и evals.

Роль skill master​

В компании нужна роль, которая отвечает за качество библиотеки.

Рабочее название — skill master.

На первом этапе это может быть функция AI-Native lead, методолога, архитектора, руководителя операционного ядра или сильного сотрудника, который понимает и работу, и ассистентов.

Skill master отвечает за:

  • прием предложений от сотрудников;
  • помощь в оформлении skill;
  • проверку структуры;
  • контроль наличия source of truth;
  • проверку границ Delegate / Review / Act;
  • проверку правил остановки;
  • проверку безопасности;
  • организацию review;
  • публикацию утвержденных skills;
  • удаление устаревших skills;
  • обучение сотрудников, как создавать skills.

Skill master не обязан быть экспертом во всех процессах. Бизнес-смысл утверждает владелец процесса, а skill master следит, чтобы skill был оформлен как управляемый корпоративный актив.

Кто участвует в review​

Для обычного skill достаточно:

  • автор;
  • skill master;
  • владелец процесса.

Для критичного skill могут добавляться:

  • security;
  • юрист;
  • технический архитектор;
  • владелец source of truth;
  • руководитель направления.

Например:

Тип skillКто обязательно смотрит
КП, заявки, встречиВладелец процесса и skill master
ДоговорыВладелец процесса, юрист и skill master
ФинансыВладелец процесса, финансы и skill master
Инженерные агентыTech lead, security при необходимости и skill master
Данные клиентовВладелец процесса, security и skill master

Жизненный цикл skill:

  1. Идея.

  2. Черновик.

  3. Branch.

  4. PR/MR.

  5. Review.

  6. Pilot.

  7. Merge.

  8. Publish.

  9. Usage metrics.

  10. Improvement.

  11. Deprecation.

  12. Идея

Любой сотрудник может предложить:

Мне нужен skill, который помогает делать X, потому что сейчас мы теряем Y, а хороший результат должен выглядеть как Z.

  1. Черновик

Сотрудник заполняет карточку skill или просит ассистента помочь.

Важно: сотрудник не обязан знать Git.

Он должен знать свою работу.

  1. Branch

Для skill создается ветка:

skill/proposal-draft-quality-review
skill/project-status-summary
skill/legal-contract-risk-check
  1. PR/MR

В PR/MR должно быть:

  • зачем нужен skill;
  • какая роль использует;
  • какой контур улучшает;
  • какие source of truth нужны;
  • какие риски;
  • как проверяли;
  • кто владелец.
  1. Review

Review проверяет:

  • понятна ли цель;
  • является ли skill рабочим протоколом;
  • указан ли source of truth;
  • есть ли ограничения;
  • есть ли правило остановки;
  • есть ли качество;
  • нет ли нарушения прав и безопасности;
  • понятен ли формат результата;
  • есть ли владелец.
  1. Pilot

Новый skill сначала может иметь статус pilot.

Его проверяют на 3-10 реальных задачах.

  1. Merge и publish

После review и пилота skill сливается в основную ветку и становится доступен сотрудникам через установленный механизм: плагин, пакет skills, внутренний каталог или агентную платформу.

  1. Improvement

Ошибки и улучшения идут через новые PR/MR.

  1. Deprecation

Если skill устарел, его не удаляют молча.

Его помечают:

status: deprecated
replaced_by: new-skill-name
reason: source of truth changed

Статусы skill:

СтатусЗначение
draftЧерновик, не использовать в работе
pilotМожно использовать ограниченной группой
approvedУтвержден для роли или контура
deprecatedУстарел, есть замена или причина вывода
blockedВременно запрещен из-за риска

Статус должен быть виден в SKILL.md или в реестре.

Пример шапки SKILL.md​

---
name: proposal-draft
status: approved
version: 1.3.0
owner: sales-operations
role: sales-manager
process: incoming-demand
source_of_truth:
  - CRM
  - proposal-templates
  - meeting-summary

risk_level: medium
reviewers:
  - skill-master
  - head-of-sales

last_reviewed: 2026-05-19
---

После шапки идет сам рабочий протокол.

Что должен уметь обычный сотрудник​

Обычный сотрудник не обязан знать Git-команды.

Но он должен уметь:

  • заметить повторяющуюся работу;
  • описать, где теряется время или качество;
  • показать пример хорошего результата;
  • указать source of truth;
  • объяснить, где человек принимает решение;
  • предложить улучшение существующего skill;
  • проверить skill на реальной задаче.

Техническую часть может помогать делать ассистент или skill master.

Как сотрудник предлагает новый skill​

Простой маршрут:

  1. Сотрудник пишет идею в форму, задачу или ассистенту.
  2. Ассистент помогает заполнить карточку skill.
  3. Skill master проверяет структуру.
  4. Владелец процесса подтверждает бизнес-смысл.
  5. Создается branch и PR/MR.
  6. Review проверяет качество и безопасность.
  7. Skill проходит пилот.
  8. После merge skill публикуется для роли или команды.

Шаблон PR/MR для skill​

# Новый или измененный skill

## Что меняется

## Какую работу улучшает

## Для какой роли и процесса

## Source of truth

## Delegate / Review / Act

## Ограничения и правило остановки

## Риски безопасности и данных

## Как проверяли

## Примеры результата

## Владелец skill

## План пилота или публикации

Правила merge​

Skill нельзя сливать в основную ветку, если:

  • нет владельца;
  • нет source of truth;
  • нет правила остановки;
  • не описаны ограничения;
  • нет формата результата;
  • skill требует данных, к которым нет прав;
  • skill обещает автономное действие без проверки;
  • есть риск утечки чувствительных данных;
  • владелец процесса не подтвердил смысл.

Для критичных контуров merge запрещен без security review.

Публикация skills​

После merge skill должен попасть туда, где его увидят ассистенты и сотрудники.

Варианты:

  • пакет skills для агентной платформы;
  • внутренний marketplace;
  • плагин для ассистента;
  • каталог в базе знаний;
  • автоматическая доставка в рабочие среды.

Важно: Git — это источник управления изменениями, но пользователь не должен каждый раз вручную копировать файлы.

У компании должен быть механизм доставки утвержденных skills.

Метрики библиотеки skills​

Следите за количеством skills, качеством и реальным использованием.

Полезные метрики:

  • сколько skills в статусе approved;
  • сколько skills реально используются;
  • сколько skills без владельца;
  • сколько skills давно не пересматривались;
  • сколько PR/MR создано сотрудниками;
  • сколько предложений пришло от неразработчиков;
  • сколько ошибок исправлено через обновление skill;
  • какие skills дают наибольший эффект;
  • какие skills нужно удалить.

Количество skills само по себе не показатель зрелости.

Зрелость — это когда skills используются, улучшаются и имеют владельцев.

Ошибки организации skills​

Первая ошибка — хранить skills в личных заметках.

Так компания теряет историю и не может масштабировать опыт.

Вторая ошибка — разрешить всем менять основную библиотеку без review.

Так быстро появляется хаос.

Третья ошибка — сделать процесс слишком разработческим.

Если обычный сотрудник не может предложить skill, компания теряет лучшие практики с передовой.

Четвертая ошибка — назначить skill master единственным автором.

Он должен помогать и проверять, сохраняя процесс быстрым и понятным для авторов.

Пятая ошибка — не удалять устаревшие skills.

Старая инструкция в AI-Native контуре может быть опаснее отсутствия инструкции.

Главная мысль​

Библиотека skills должна быть устроена как живой корпоративный продукт.

Любой сотрудник может предложить новый skill для своей роли или процесса. Git хранит историю и изменения. PR/MR дает контроль качества. Skill master помогает оформить, проверить и провести skill до публикации. Владелец процесса отвечает за смысл и результат.

Так удачная практика одного человека становится активом всей компании.

От экспериментов к операционному ядру​

AI-Native — это управленческая дисциплина, где люди, ассистенты, skills, надежные источники, права доступа, память и измеримое качество работают вместе.