agentleFS
sergeeeysergeeey/Claude-cod-top-2026/skills/core/skill-self-update/SKILL.md

skill-self-update

Skill9 starsChanged 6 months agoMITView on GitHub

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).

The file

Files
SKILL.md
<!-- 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 — Закоммитить

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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.