agentleFS
Sign inStart free
vefmvaivefmvai/sysadmin/.claude/skills/second-opinion/SKILL.md

second-opinion

Skill1 starsChanged 3 months agoMITView on GitHub

Второе мнение свежим взглядом: работу оценивает не тот, кто её делал, а независимый проверяющий с чистым контекстом, которому выдана рубрика, а не просьба «посмотри». Четвёртый — самый надёжный — уровень петли проверки: выше «сделай и проверь в том же ходе», выше условия на сессию, выше детерминированного Stop-хука. Даёт брифинг-шаблон, правила разделения зон, ограничители против выдуманных находок и протокол кругов (до трёх; на третьем FAIL — стоп и разговор с оператором). Триггеры: «проверь мою работу свежим взглядом», «второе мнение», «независимая проверка», «позови проверщика», «я закончил, проверь», «second opinion», «прогони ревью этапа», «убедись, что я не соврал», «перепроверь чужим контекстом». НЕ для поиска бага в работающей системе (это /health-check и диагностика); НЕ для аудита безопасности сервера (это /audit-security); НЕ для разбора собственной сессии постфактум (это /retro).

  • Deletes or force-pushes

45 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use insecure-defaults, variant-analysis and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • allanninalSkill

    insecure-defaults

    Detects fail-open insecure defaults (hardcoded secrets, weak auth, permissive security) that allow apps to run insecurely in production. Use when auditing security, reviewing config management, or analyzing environment variable handling.

    Also in 3 projects that use this

  • allanninalSkill

    variant-analysis

    Find similar vulnerabilities and bugs across codebases using pattern-based analysis. Use when hunting bug variants, building CodeQL/Semgrep queries, analyzing security vulnerabilities, or performing systematic code audits after finding an initial issue.

    Also in 3 projects that use this

  • shmehroSkill

    ux-audit

    Perform a heuristic UX audit on a UI screen, flow, or component description

    Also in 3 projects that use this

  • sunnyclinches44Skill

    explain

    Explains code using real-world analogies and ASCII diagrams

    Also in 5 projects that use this

  • photon-groveSkill

    unslop

    Detects and rewrites generic, overly polished, or AI-sounding prose while preserving meaning. Use when the user asks to "unslop", humanize, de-AI, tighten, or review whether writing sounds generated.

    Also in 4 projects that use this

  • SentrySkill

    commit

    Create commit messages following Sentry conventions. Use when committing code changes, writing commit messages, or formatting git history. Follows conventional commits with Sentry-specific issue references.

    Also in 6 projects that use this

The file

Create a free account to mount
Files
SKILL.md
<role> Я организую проверку своей работы **чужими руками**. Сам я — худший проверяющий своей работы: я знаю, что хотел сделать, и вижу это вместо того, что получилось. Проверяющий со свежим контекстом не знает моего замысла и видит только результат.

Это не формальность. Прогон 27.07.2026: три проверщика на работу, которую я дважды объявил готовой, нашли двенадцать дефектов, два из них уровня конституции — выдуманный факт под видом замера и утечка секрета в транскрипт. Оба прошли мимо моих собственных зелёных тестов. </role>

Когда звать

Зову: закончил нетривиальную работу и собираюсь объявить её готовой; завёл замок, хук или линтер; правил персону или конституцию; закрыл этап плана; написал документ, где много проверяемых утверждений.

Не зову: правка в одну строку; работа, которую оператор уже проверил сам; задача, где проверять нечего (ответ на вопрос, справка).

Стоимость честная: каждый проверщик — отдельный прогон с чтением файлов и запуском тестов. Три проверщика на средний этап — заметный расход. Экономия ложная: дефект, найденный через месяц в бою, дороже.

Процедура

Шаг 1. Разделить зоны

Один проверщик на всё — плохо: он размажется и проверит всё поверхностно. Делю работу на непересекающиеся зоны и на каждую ставлю своего. Рабочее деление, проверенное практикой:

ЗонаЧто проверяет
Код и замкиделает ли механизм то, что обещает; пытается сломать
Поведениеживые прогоны, не сломалась ли процедура, соответствие правилам репозитория
Правдивость документовкаждое фактическое утверждение против реальности

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

Шаг 2. Написать брифинг

Шаблон и разбор каждого пункта — references/briefing-template.md. Открываю его до того, как писать задание: брифинг по памяти теряет ограничители, а без них проверяющий начинает выдумывать находки.

Коротко, что обязано быть в брифинге:

  1. «НЕ ВЕРЬ НИЧЬИМ СЛОВАМ» — прямым текстом. Проверяющий читает файлы и запускает команды сам, отчёт исполнителя ему не источник.
  2. Зона — что проверяет и что НЕ его дело.
  3. Рубрика, а не просьба. Не «посмотри, всё ли хорошо», а список вопросов с порогом (ADR-0031). Проза даёт разброс трактовок, рубрика — воспроизводимый вердикт.
  4. Задание сломать, а не осмотреть. «Напиши СВОИ фикстуры, минимум N, не те, ради которых замок писался». Это единственный способ отличить замок от иллюзии замка.
  5. Ограничитель. Проверяющий, которому велено искать дыры, найдёт их и в исправной работе. Рамка: корректность и заявленные требования, а не вкус проверяющего. Без рамки получишь переусложнение под видом находок.
  6. Границы безопасности. Что нельзя трогать: боевой сервер, приватные каталоги оператора, деструктивные операции git. Уборку за собой — точечно, rm -f плюс rmdir: замок красной зоны остановит rm -rf, и проверщик встанет на ровном месте.
  7. Формат вердикта: находки по тяжести, у каждой — файл, строка, чем подтверждено (команда и её вывод), затем PASS или FAIL одним словом.

Шаг 3. Запустить и не мешать

Проверщики работают параллельно. Пока они читают — не правлю файлы их зоны: правка посреди прогона делает их выводы недействительными. Правлю то, что вне зон, либо жду.

Шаг 4. Разобрать находки

По каждой находке — своё решение, не пакетом:

  • Подтверждаю и чиню — дефект реальный.
  • Подтверждаю, но не чиню сейчас — реальный, но вне объёма: в попутные находки (§4.4).
  • Отклоняю — с обоснованием. Проверяющий тоже ошибается; сегодняшний прогон дал и такие пункты. Отклонение без обоснования — не отклонение, а игнорирование.

Ошибка проверяющего не отменяет остальных находок. Соблазн «он ошибся здесь, значит и там» — самый вредный исход второго мнения.

Шаг 5. Круги

FAIL → чиню → зову снова. До трёх кругов. На третьем FAIL — стоп и разговор с оператором: три круга без схождения означают, что дело не в мелочах.

Правка по находкам сама вносит дефекты — это не гипотеза: 27.07.2026 починка первого круга внесла два новых бага (зацикливание разборщика и сторож, лгущий про таймаут), и оба поймал тест, а не чтение кода. Поэтому после правок круг повторяется, а не закрывается по ощущению.

Что считать результатом

Проверка закрыта, когда: все находки разобраны (починены, вынесены в попутные или обоснованно отклонены); тесты и линтеры зелёные после правок; получен PASS либо явно записано, почему остаток принят.

Зелёные тесты не заменяют второго мнения. В прогоне 27.07.2026 оба теста были зелёными ровно в тот момент, когда замок покрывал одну форму синтаксиса из двух: тест проверял то же, что и замок, — то есть подтверждал сам себя.

Чего этот скилл НЕ делает

Не заменяет живой тест (§3.11) — проверяющий тоже может поверить зелёному статусу. Не заменяет мою ответственность: находки разбираю я, вердикт принимаю я, отвечаю за результат тоже я.

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.

Check your setup, free