Skill Self Update

---
name: skill-self-update
description: >
  Reads a skill's feedback.log, decides whether accumulated feedback justifies
  a change, applies a surgical edit to that skill's SKILL.md, archives the
  processed feedback, and commits the change to git with a clearly-marked
  automated message. Designed to run headless (`claude -p`) on a schedule —
  see docs/living-skills.md for the Task Scheduler setup.
  Triggers: /skill-self-update <skill-dir>, "обнови скилл по фидбеку",
  "прочитай feedback.log и обнови SKILL.md".
  НЕ для: ручного улучшения скилла без накопленного фидбека (→ /self-improve
  skill <path>), одноразового аудита реестра скиллов (→ /skill-audit).
tools: Read, Edit, Bash, Glob
effort: medium
---

<!-- BSV — Brief Skill View
Скил   : skill-self-update
TL;DR  : Feedback.log → surgical SKILL.md edit → archive → git commit. Headless, scheduled.
Вызов  : /skill-self-update skills/extensions/<name>
НЕ для : Ручной /self-improve без накопленного фидбека
-->

# Skill Self-Update — feedback.log → SKILL.md, автономно

## Контекст

Этот скилл — "мотор" механизма живых скиллов ("живые скиллы" — паттерн из
внешнего источника, не официальная фича Anthropic; см. `docs/living-skills.md`
для полного обоснования и сравнения с `skill-creator`/`self-improve`). Он не
запускается сам по расписанию — расписание живёт вне репо, в
`~/.claude/scripts/skill-feedback-update.ps1` + Windows Task Scheduler, потому
что это машинно-специфичная инфраструктура, а не портируемый конфиг.

Опт-ин: только скиллы, которые ЯВНО добавили в свой `SKILL.md` директиву
"после задачи спроси фидбек → допиши в `<skill-dir>/feedback.log`" (см.
`docs/living-skills.md` для шаблона директивы). Без этой директивы
`feedback.log` не наполняется, и этот скилл на следующем прогоне корректно
завершается без изменений — это не баг, это отсутствие входных данных.

## Вход

```
/skill-self-update <относительный путь до директории скилла>
Пример: /skill-self-update skills/extensions/research-audit
```

## Алгоритм

### Шаг 1 — Прочитать feedback.log

Путь: `<skill-dir>/feedback.log`. Если файла нет — сообщить и остановиться
(не создавать пустой файл самовольно, opt-in должен быть явным действием
человека, а не побочным эффектом первого запуска).

Формат ожидаемых записей (одна на строку или блок, с датой):
```
[YYYY-MM-DD] <фидбек пользователя как есть>
```

### Шаг 2 — Найти необработанные записи

Ищи маркер `<!-- processed through: YYYY-MM-DD HH:MM -->` в конце файла (если
его нет — все записи необработаны). Взять только записи ПОСЛЕ последнего
маркера.

### Шаг 3 — Порог значимости (anti-overfitting)

**Если необработанных записей < 2 — остановиться без изменений.** Один
отзыв — шум или единичный кейс, не основание переписывать инструкцию,
которая управляет поведением на будущее. Залогировать "недостаточно фидбека
(N=1), пропуск" и выйти.

Это тот же принцип, что Anti-Overfitting Gate в `rules/falsification-ladder.md`
(не менять на основании одного результата) — облегчённая версия для
скилл-инструкций, не для научных гипотез.

### Шаг 4 — Проанализировать и предложить правку

Прочитать необработанные записи. Определить:
- Повторяющийся паттерн жалобы/похвалы (≥2 записи об одном и том же —
  сильный сигнал) vs единичные разрозненные точки (слабый сигнал, вероятно
  ещё не порог для правки конкретно ПО НИМ, даже если общее число ≥2)
- Какая именно секция `SKILL.md` затронута (не переписывать файл целиком)

**Правь МИНИМАЛЬНО и ТОЧЕЧНО** — как `Edit`, не `Write` всего файла. Сохраняй
frontmatter, структуру, стиль остального документа. Если фидбек противоречит
существующей инструкции — предпочти явно написать исключение/уточнение,
а не молча удалить старое правило (кто-то мог полагаться на него по другой
причине).

Если после анализа реальной, конкретной правки не находится (фидбек
описателен, но не даёт actionable изменения) — не выдумывай правку. Залогируй
"фидбек прочитан, конкретной правки не выявлено" и переходи сразу к Шагу 5
(всё равно архивируй обработанное — не повторно анализировать в следующий раз).

### Шаг 5 — Архивировать обработанное

Добавить в конец `feedback.log`:
```
<!-- processed through: YYYY-MM-DD HH:MM -->
```
Не удалять сами записи — маркер просто сдвигает границу "уже учтено".

### Шаг 6 — Закоммитить

```bash
git add <skill-dir>/SKILL.md <skill-dir>/feedback.log
git commit -m "auto(skill-feedback): update <name> from N feedback entries — YYYY-MM-DD

<1-2 строки — что именно изменено и на основании какой обратной связи>

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>"
```

**НЕ push.** Автоматизация коммитит локально; push — отдельное решение
человека, как и любой push в этом репо (см. `feedback_explicit_go_before_git_actions`
в личной памяти пользователя — то же правило распространяется и на
автоматизированные коммиты).

Если правки не было (Шаг 3 или Шаг 4 остановили процесс) — всё равно
закоммитить ТОЛЬКО обновлённый `feedback.log` (маркер processed), если
он менялся, отдельным коммитом `chore(skill-feedback): mark <name> feedback processed, no change needed`.

## Anti-patterns

| Паттерн | Почему плохо |
|---|---|
| Переписать весь `SKILL.md` с нуля на основе фидбека | Теряет структуру, стиль, всё что фидбек не касался напрямую |
| Применить правку на основании 1 отзыва | Один голос ≠ паттерн; см. Шаг 3 |
| Удалить старое правило вместо добавления исключения | Ломает случаи, для которых старое правило было написано |
| Запушить автокоммит | Push — решение человека, не автоматизации |
| Придумать правку когда фидбек неактуренабелен | Галлюцинация "улучшения" хуже отсутствия изменения |

## Связанные скилы

- `/self-improve skill <path>` — ручной Critic↔Author цикл, без feedback.log,
  для разового точечного улучшения по запросу человека
- `/skill-audit` — health-check всей экосистемы скиллов (PROMOTE/KEEP/MERGE/
  FREEZE/DELETE), не per-skill feedback loop
- `docs/living-skills.md` — полное обоснование паттерна, сравнение с
  `skill-creator`, ссылка на `~/.claude/scripts/skill-feedback-update.ps1`