| name | learn |
| description | Изучить историю текущей переписки и обновить релевантный скилл (или несколько) с учётом накопленного опыта — добавить уточнения, убрать неработающие шаги, зафиксировать предпочтения пользователя. Используй когда пользователь пишет /learn, "обнови скилл", "запомни на будущее в скилл", "изучи переписку и поправь скилл", "учти этот опыт", "добавь в скилл то, что я сейчас сказал", "так больше не делай — поправь скилл". |
learn
Точечно улучшаешь скиллы на основе того, что произошло в текущем разговоре. Цель — чтобы в следующий раз скилл сработал лучше без повторного объяснения от пользователя.
Это не замена памяти (MEMORY.md) и не способ переписать скилл целиком. Только адресные правки в местах, где скилл подвёл или где появилось новое знание.
Когда применять
- Пользователь поправил подход, сказал "не так", "стоп, делай иначе", "в следующий раз так не делай".
- Пользователь подтвердил неочевидное решение ("да, именно так и надо", "хорошо что не стал делать X").
- Скилл пропустил шаг, дал неверную инструкцию, не учёл частный случай.
- Появилось новое правило проекта (формат, путь, имя, домен), которое должно жить в скилле, а не в голове.
- Пользователь явно сказал /learn или попросил "запомнить на будущее в скилл".
Когда НЕ применять
- Факт о пользователе или проекте, не относящийся к конкретному скиллу — это в
MEMORY.md через auto memory.
- Одноразовая ситуация, которая вряд ли повторится.
- Изменение, противоречащее CLAUDE.md или явному указанию пользователя — сначала уточни.
- Структурный рефакторинг скилла "потому что красивее" — только функциональные правки.
Шаги
1. Найти урок
Перечитай последние сообщения текущей переписки и выдели:
- Что пошло не так? Где я ошибся, и что сказал пользователь?
- Какое неявное знание стало явным (формат, путь, имя, ограничение)?
- Какое правило подтвердилось — что стоит закрепить?
Сформулируй урок одной строкой: "В скилле X не хватало Y; теперь добавляем Y, потому что Z".
Если урока нет — скажи об этом и не редактируй файлы.
2. Выбрать скилл
- Определи, к какому скиллу относится урок. Кандидаты ищи в
.claude/skills/<name>/SKILL.md (проектные) и в ~/.claude/skills/ (глобальные).
- Если урок попадает в несколько скиллов — обнови каждый, но минимально: один и тот же текст не дублируй, лучше короткая ссылка вида "см.
<other-skill>".
- Если ни один скилл не подходит, но урок ценный — предложи пользователю создать новый скилл и не правь чужой скилл "до кучи".
- Если урок про общий стиль работы или про пользователя — сохрани через auto memory (
MEMORY.md + отдельный файл памяти), не в скилл.
3. Минимальная правка
- Точечный
Edit. Не переписывай скилл целиком.
- Добавляй в существующий раздел, если он подходит. Создавай новый раздел только когда правило не вписывается ни в один из имеющихся.
- Сохраняй стиль скилла: язык и форму обращения как в остальном тексте скилла, нумерацию шагов.
- Не пиши преамбул "теперь мы научились" и "в прошлый раз было…". Скилл — это инструкция для будущих сессий, контекст текущей переписки им не нужен.
- Не добавляй комментарии "added 2026-05-05". Дата правки видна в git.
- Если правится
description во frontmatter — добавь только новые триггерные фразы, не переписывай существующие.
4. Показать diff и подтвердить
Перед завершением кратко покажи пользователю:
- Какой скилл правил.
- Что изменил — одна-две строки (не весь diff, его покажет git).
- Почему — отсылка к моменту переписки.
Если правок больше одной — перечисли по одной строке на правку.
Не коммить автоматически. Пусть пользователь сам решит, делать commit или сначала проверить.
Защита от ошибок
- Не редактируй скилл, если урок противоречит явному правилу из CLAUDE.md или прошлой инструкции пользователя — сначала уточни.
- Не удаляй существующие шаги скилла, если только пользователь явно не сказал "это больше не нужно". Если шаг устарел — добавь оговорку, не вырезай.
- Не размывай
description: добавляемые триггеры должны быть осмысленными, а не общими словами вроде "помоги".
- Не меняй имя скилла (
name:) и путь файла без явного запроса.
- Если урок относится к глобальному скиллу (
~/.claude/skills/...), но ты не уверен — спроси, обновлять глобальный или скопировать локально в проект.
- Если скилл из плагина (
~/.claude/plugins/.../skills/...) — не правь его напрямую, предложи создать локальный override или открыть PR в плагин.
Проверка перед ответом
- Файл скилла валиден: frontmatter не сломан, markdown читается.
- Внесённое правило не дублирует уже написанное в этом же скилле.
- Стиль и язык согласованы с остальной частью скилла.
- В ответе пользователю названо: какой скилл, какое правило добавлено, в каком разделе.
- Если ничего достойного правки не нашлось — честно сказал, файлы не тронуты.
