История началась с поста Aniket Panjwani про GPT Pro как внешний слой проверки. Идея была простой: перед дорогим решением полезно остановиться и спросить сильную модель не «как сделать», а «что мы упускаем».
Через несколько часов эта мысль стала не заметкой с промптом, а устанавливаемым Codex-скиллом: `pro-review-bundle`. Он собирает безопасный пакет контекста для GPT Pro, проверяет приватность, фиксирует границы и возвращает внешний разбор обратно в рабочий процесс Codex. Заодно это стало моим первым публичным репозиторием на GitHub.
Источник
Пост → скилл
Идея из публичного поста быстро превратилась в конкретный рабочий инструмент, а не осталась вдохновляющей заметкой.
Порог
Первый GitHub
Внутренний инструмент был оформлен как публичный репозиторий, которым можно пользоваться и который можно проверять.
Проверка
Сразу в работе
Скилл сразу применили на реальной задаче, где внешняя проверка поймала архитектурный риск до кода.
Исходная задача
Саму идею можно было записать в заметку: перед рискованными задачами спрашивать GPT Pro как внешнего рецензента. Но заметки редко меняют поведение. Чтобы практика жила, она должна включаться в рабочий процесс без лишнего трения.
Codex работает в своём контуре, а GPT Pro доступен через ChatGPT. Значит, нужен мост: безопасно собрать контекст, вынести его наружу и вернуть результат как внешний разбор.
Если каждый раз вручную выбирать файлы, проверять секреты и вспоминать правильный формат, практика быстро умирает. Инструмент должен сам вести через нужные шаги.
Что получилось
Скилл не пытается заменить человека и не даёт GPT Pro право утверждать изменения. Его задача проще и полезнее: подготовить безопасный пакет для внешней проверки и вернуть ответ в процесс как материал для решения.
В пакет попадают цель, текущее состояние, план, границы, риски, вопросы и выбранные фрагменты проекта.
Скилл проверяет, не попали ли в пакет секреты, приватные данные, лишние логи, `.env` или чувствительный для продакшна материал.
Ответ GPT Pro не исполняется автоматически. Сначала фиксируется, что принимаем, что отвергаем и как меняется план.
Публичный шаг
До этого код жил в приватных проектах: клиентские системы, рабочие инструменты, эксперименты для себя. Здесь появился маленький, но законченный артефакт, который можно было вынести наружу без раскрытия клиентского контекста.
Публичная упаковка заставила привести скилл в форму: README, установка, правила применения, проверки безопасности и понятная область использования.
В статье и упаковке важно сохранить честную линию: идея вдохновлена публичным постом Aniket Panjwani, реализация, проверка приватности и Codex-процесс собраны под собственный рабочий контур.
В публичный репозиторий ушёл переносимый инструмент, а не данные проектов, приватные планы или внутренние материалы.
Скилл можно установить, повторить и улучшать. Это уже рабочая практика, а не удачная ручная сессия.
Боевая проверка
Первая проверка скилла случилась почти сразу на настоящей задаче. Там внешний разбор поймал важный архитектурный риск: подтверждение валютного курса в системе роялти оказалось не просто полем, а финансовым решением с доказательной базой.
Проверка заставила остановиться до кода и посмотреть на предметную область внимательнее, чем требовала исходная формулировка задачи.
Сначала зафиксировали архитектурное решение и границы доказательной базы, затем вернулись к реализации.
Проект, клиент, отчёты, суммы и финансовые подробности не раскрываются. Публичным остаётся только инженерный урок.
Пост, оценка идеи, сборка скилла, публикация репозитория и применение на задаче уложились в один короткий рабочий контур.
Результат
Главный результат этой истории не только в одном найденном риске. Важно, что появилась повторяемая траектория: заметить полезную идею, быстро превратить её в инструмент, вынести в публичный репозиторий и проверить на реальной работе.
Внутренний рабочий инструмент стал публичным артефактом, который можно показать, установить и развивать.
Не просто промпт, не просто статья, а устанавливаемый рабочий механизм, который встраивается в процесс.
Не магический советчик и не автоматическое одобрение, а внешний рецензент для сложных планов и дорогих ошибок.
Так можно обрабатывать и другие идеи: оценить, собрать минимальный инструмент, проверить на реальной задаче и только потом масштабировать.
Когда такой подход нужен
Большинство хороших идей умирает между заметкой и применением. Здесь важен сам способ работы: быстро превратить внешний сигнал в свой инструмент и сразу проверить его на реальном контуре.
Когда хочется не просто прочитать полезный пост, а встроить идею в повторяемый процесс.
Когда маленький помощник уже полезен тебе, но может стать аккуратным публичным репозиторием или переиспользуемым скиллом.
Когда есть продакшн-чувствительная, архитектурная, финансовая или клиентская задача, где второй взгляд лучше получить до кода.
Источник
В статье подробно описано, как идея внешней проверки из поста Aniket Panjwani превратилась в Codex-скилл, проверку приватности, первый публичный GitHub-репозиторий и боевую проверку на реальном архитектурном риске.
Кейсы
Кейс
DevOps-аудит семи VPS: сначала безопасная инвентаризация и документы, потом риски, решения и точечные изменения там, где они действительно нужны.
Открыть →Кейс
Связка человека, агента, Notion и кода, в которой мысль быстро превращается в опубликованный результат на живом сайте.
Открыть →Кейс
Контентный pipeline, где сырьё из Telegram, соцсетей и закладок превращается в черновики сайта через Notion-агента.
Открыть →