learn

name

learn

description

Изучить историю текущей переписки и обновить релевантный скилл (или несколько) с учётом накопленного опыта — добавить уточнения, убрать неработающие шаги, зафиксировать предпочтения пользователя. Используй когда пользователь пишет /learn, "обнови скилл", "запомни на будущее в скилл", "изучи переписку и поправь скилл", "учти этот опыт", "добавь в скилл то, что я сейчас сказал", "так больше не делай — поправь скилл".

learn

Точечно улучшаешь скиллы на основе того, что произошло в текущем разговоре. Цель — чтобы в следующий раз скилл сработал лучше без повторного объяснения от пользователя.

Это не замена памяти (MEMORY.md) и не способ переписать скилл целиком. Только адресные правки в местах, где скилл подвёл или где появилось новое знание.

Когда применять

• Пользователь поправил подход, сказал "не так", "стоп, делай иначе", "в следующий раз так не делай".
• Пользователь подтвердил неочевидное решение ("да, именно так и надо", "хорошо что не стал делать X").
• Скилл пропустил шаг, дал неверную инструкцию, не учёл частный случай.
• Появилось новое правило проекта (формат, путь, имя, домен), которое должно жить в скилле, а не в голове.
• Пользователь явно сказал /learn или попросил "запомнить на будущее в скилл".

Когда НЕ применять

• Факт о пользователе или проекте, не относящийся к конкретному скиллу — это в MEMORY.md через auto memory.
• Одноразовая ситуация, которая вряд ли повторится.
• Изменение, противоречащее файлу инструкций агента (CLAUDE.md / AGENTS.md) или явному указанию пользователя — сначала уточни.
• Структурный рефакторинг скилла "потому что красивее" — только функциональные правки.

Шаги

1. Найти урок

Перечитай последние сообщения текущей переписки и выдели:

• Что пошло не так? Где я ошибся, и что сказал пользователь?
• Какое неявное знание стало явным (формат, путь, имя, ограничение)?
• Какое правило подтвердилось — что стоит закрепить?

Сформулируй урок одной строкой: "В скилле X не хватало Y; теперь добавляем Y, потому что Z".

Если урока нет — скажи об этом и не редактируй файлы.

2. Выбрать скилл

1. Определи, к какому скиллу относится урок. Кандидаты ищи в .claude/skills/<name>/SKILL.md (в vault, в том числе симлинки на общий репозиторий) и в ~/.claude/skills/ (глобальные). Если файл оказался симлинком, правка уходит в общий репозиторий и затронет все vault — предупреди пользователя и спроси подтверждение до правки.
2. Если урок попадает в несколько скиллов — обнови каждый, но минимально: один и тот же текст не дублируй, лучше короткая ссылка вида "см. <other-skill>".
3. Если ни один скилл не подходит, но урок ценный — предложи пользователю создать новый скилл и не правь чужой скилл "до кучи".
4. Если урок про общий стиль работы или про пользователя — сохрани через auto memory (MEMORY.md + отдельный файл памяти), не в скилл.

3. Минимальная правка

• Точечный Edit. Не переписывай скилл целиком.
• Добавляй в существующий раздел, если он подходит. Создавай новый раздел только когда правило не вписывается ни в один из имеющихся.
• Сохраняй стиль скилла: язык и форму обращения как в остальном тексте скилла, нумерацию шагов.
• Не пиши преамбул "теперь мы научились" и "в прошлый раз было…". Скилл — это инструкция для будущих сессий, контекст текущей переписки им не нужен.
• Не добавляй комментарии "added 2026-05-05". Дата правки видна в git.
• Если правится description во frontmatter — добавь только новые триггерные фразы, не переписывай существующие.

4. Показать diff и подтвердить

Перед завершением кратко покажи пользователю:

1. Какой скилл правил.
2. Что изменил — одна-две строки (не весь diff, его покажет git).
3. Почему — отсылка к моменту переписки.

Если правок больше одной — перечисли по одной строке на правку.

Не коммить автоматически. Пусть пользователь сам решит, делать commit или сначала проверить.

Защита от ошибок

• Не редактируй скилл, если урок противоречит явному правилу из файла инструкций агента (CLAUDE.md / AGENTS.md) или прошлой инструкции пользователя — сначала уточни.
• Не удаляй существующие шаги скилла, если только пользователь явно не сказал "это больше не нужно". Если шаг устарел — добавь оговорку, не вырезай.
• Не размывай description: добавляемые триггеры должны быть осмысленными, а не общими словами вроде "помоги".
• Не меняй имя скилла (name:) и путь файла без явного запроса.
• Если урок относится к глобальному скиллу (~/.claude/skills/...), но ты не уверен — спроси, обновлять глобальный или скопировать локально в проект.
• Если скилл из плагина (~/.claude/plugins/.../skills/...) — не правь его напрямую, предложи создать локальный override или открыть PR в плагин.

Проверка перед ответом

1. Файл скилла валиден: frontmatter не сломан, markdown читается.
2. Внесённое правило не дублирует уже написанное в этом же скилле.
3. Стиль и язык согласованы с остальной частью скилла.
4. В ответе пользователю названо: какой скилл, какое правило добавлено, в каком разделе.
5. Если ничего достойного правки не нашлось — честно сказал, файлы не тронуты.