sip — скилл для Claude Code: проверка своего же результата
Скилл-оркестратор: после того как агент что-то создал или изменил, он прогоняет результат через другие скиллы репозитория вместо доверия к собственной оценке.
npx skills add LilMGenius/paperthin --skill sip -a claude-codeЧто делает sip
sip запускается по триггеру: вы только что создали или изменили артефакт либо скилл и собираетесь объявить работу готовой, закоммитить или передать дальше. В этот момент скилл прогоняет результат через набор проверок из того же репозитория. Сам он ничего не проверяет — только маршрутизирует находки обратно в сессию автора.
Порядок такой. Сначала shower — холодное чтение артефакта, проверка на понятность свежими глазами. Дальше factchk, если в тексте есть утверждение о реальности, или mandela, если заданы eval, метрика или эксперимент. Потом ssotize в режиме аудита ищет дубли и противоречия по репозиторию, а его план консолидации выполняется только после одобрения. detool подключается, когда артефакт заявляет переносимость или независимость от инструментов. Завершает re0 — приведение изменённых документов к чистому виду.
Проверки, которые не подходят к случаю, пропускаются, и скилл просит сказать, что именно пропущено и почему. Не установленный скилл тоже не запустится. Git sip не трогает и коммитов не делает. Ещё он не вызывает скиллы, помеченные disable-model-invocation: их запускает человек. Это стоит держать в голове, если строите цепочку проверок на своём наборе скиллов.
Какие задачи решает
- проверить свежий артефакт до того, как объявить работу готовой
- поймать дубли и противоречия, которые изменение внесло в репозиторий
- отделить утверждения о реальности от догадок автора
- привести изменённые документы к читаемому виду вместо заплатки поверх черновика
- проверить заявленную переносимость артефакта между инструментами
Примеры запросов агенту
- я дописал README, прогони sip
- проверь этот скилл через sip перед коммитом
- прогони sip по изменённым докам
Как установить sip
1Через Skills CLI (Vercel)
npx skills add LilMGenius/paperthin --skill sip -a claude-code2Вручную: положить файлы
~/.claude/skills/sip/SKILL.mdПапка скилла целиком; для одного проекта — .claude/skills/sip/
1Через Skills CLI (Vercel)
npx skills add LilMGenius/paperthin --skill sip -a codex2Вручную: положить файлы
.agents/skills/sip/SKILL.mdДля всех проектов — ~/.agents/skills/
1Через Skills CLI (Vercel)
npx skills add LilMGenius/paperthin --skill sip -a cursor2Вручную: положить файлы
.cursor/skills/sip/SKILL.mdCursor читает и .agents/skills/, и .claude/skills/
1GitHub CLI
gh skill install LilMGenius/paperthin sip2Вручную: положить файлы
.github/skills/sip/SKILL.md1Через Skills CLI (Vercel)
npx skills add LilMGenius/paperthin --skill sip -a gemini-cli2Командой платформы
gemini skills install https://github.com/LilMGenius/paperthin --path skills/depth/sipВручную: положить файлы
.devin/skills/sip/SKILL.mdСтарый путь .windsurf/skills/ тоже читается
Через Skills CLI (Vercel)
npx skills add LilMGenius/paperthin --skill sip -a opencodeClaude.ai
Упакуйте папку в zip и загрузите в Settings → Capabilities → Skills
По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов
Вопросы о sip
Как установить sip в Claude?
Выполните npx skills add LilMGenius/paperthin --skill sip -a claude-code. Файл скилла окажется в ~/.claude/skills/sip/SKILL.md.
Что делает sip?
Он запускает проверки вашего свежего результата через другие скиллы репозитория — shower, factchk, mandela, ssotize, detool, re0 — и возвращает находки в сессию автора. Сам проверок не выполняет.
Что нужно, чтобы sip сработал?
Он запускает только те скиллы, которые установлены, и пропускает то, что не подходит к случаю. Скиллы с пометкой disable-model-invocation он не вызывает — их запускает человек.
Исходный текст
SKILL.md · MIT
---
name: sip
description: "After you create or change an artifact or skill, taste-test it with our own skills instead of trusting your in-session judgment — recursive self-improvement, made automatic. Use right after writing or editing anything, before calling it done, committing, or handing it off."
---
Taste your own cooking: the moment you finish making something, check it with the very skills this repo ships before you serve it.
## Goal
A reminder buried in docs ("remember to verify") won't reliably fire in a fresh session. `sip` makes the recursive self-improvement loop a triggered habit: right after any create or change, run our own skills on the result — the clean checks and the true ones — so quality doesn't ride on the author's biased in-session judgment.
## Workflow
1. Spot the trigger: you just created or changed an artifact or skill and are about to call it done, commit, or hand it off.
2. **Cold-read it** — run `shower` on the artifact (fresh-eyes comprehension / handoff check).
3. **Verify it's true** — if the artifact asserts a reality-grounded claim, run `factchk`; if it defines an eval, metric, or experiment, run `mandela`. Skip when it has neither.
4. **Check consistency** — run `ssotize` in audit mode across the repo for anything the change duplicated or contradicted; execute its consolidation plan only after approval.
5. **Detool portability claims** — run `detool` only when the artifact claims portability, tool-neutrality, stack-agnostic durability, or cross-agent reuse. Skip when it is provenance, operational notes, a tool-targeted runbook, or does not claim portability.
6. **Tidy** — `re0` the changed docs so the result reads as a clean v0, not a patch over a draft.
7. Apply the findings here, then serve it.
## Rules
- Trigger on your OWN output, right after making it — that's when bias is highest and a check is cheapest.
- Use the skills; don't re-implement them — `shower` for clarity, `factchk`/`mandela` for truth, `ssotize` for SSOT, `detool` for portability claims, `re0` for cleanup. `sip` orchestrates and routes findings back to the author session to fix; the skills do the work.
- Skip what plainly doesn't apply, or any check whose skill isn't installed — run only what's present. `factchk`/`mandela` fire only when there is a claim or an eval; `detool` fires only when the artifact claims portability, tool-neutrality, stack-agnostic durability, or cross-agent reuse; a one-line prose tweak may need only a consistency check. Say what you skipped and why.
- Stop at the artifact — `sip` never touches git or makes commits.
- Chain only model-invoked skills; a user-invoked skill (marked `disable-model-invocation`) is a human's to fire deliberately, so `sip` must not call one.
## Verification
Before finishing:
1. The change was actually run through the relevant skills, not eyeballed.
2. Findings were applied (or consciously deferred with a stated reason).
3. The artifact actually changed as a result (a diff exists), or every skipped skill has a stated reason.
© LilMGenius · MIT · LilMGenius/paperthin