Приложение 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 он полезен не потому, что это “код”.

Он полезен потому, что company skill требует управления изменениями.

Нужно знать:

кто предложил 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 был оформлен как управляемый корпоративный актив.

Кто участвует в 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 идея -> черновик

-> branch -> PR/MR -> review

-> pilot -> merge

-> publish -> usage metrics

-> improvement -> deprecation

1. Идея

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

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

2. Черновик

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

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

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

3. Branch

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

skill/proposal-draft-quality-review
skill/project-status-summary
skill/legal-contract-risk-check

4. PR/MR

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

зачем нужен skill;

какая роль использует;

какой контур улучшает;

какие source of truth нужны;

какие риски;

как проверяли;

кто владелец.

5. Review

Review проверяет:

понятна ли цель;

не является ли skill просто промптом;

указан ли source of truth;

есть ли ограничения;

есть ли правило остановки;

есть ли качество;

нет ли нарушения прав и безопасности;

понятен ли формат результата;

есть ли владелец.

6. Pilot

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

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

7. Merge и publish

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

8. Improvement

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

9. 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, надежные источники, права доступа, память и измеримое качество работают вместе.