В Anthropic раздают бесплатно доступ на полгода к Claude Max для разработчиков, кто делает коммиты и занимается Open Source проектами. Если поддерживаете важный пакет или сервис или активно участвуете в жизни открытых проекта, то можете подать заявку.
Требования к участникам открытых проектов, которые могут отправить заявку на получение бесплатной 6-месячной подписки Claude Max 20x:
Авторы и сопровождающие открытых библиотек, пакеты с которыми насчитывают более 200 тысяч загрузок из каталогов, таких как npm, PyPI, crates.io и RubyGems, или которые используются как минимум в 500 репозиториях или в 100 зависимых пакетах.
Ключевые разработчики крупных открытых проектов, имеющие право коммита или входящие в число сопровождающих. В качестве примеров уровня проектов упомянуты CPython, Rust, Node.js, Apache, CNCF, Kubernetes, ядро Linux, Django и Rails.
Активные участники разработки, от которых было принято более 100 pull‑запросов в не аффилированные с ними проекты.
Создатели сообществ, в разработке которых участвуют 20 и более сторонних разработчиков, от которых принимались pull‑запросы за последний год.
Репозитории, применяемые в работе критически важной инфраструктуры (вес 0.4+ в рейтинге OpenSSF).
Представлен открытый проект Ghostprovider — терминальный инструмент для быстрого запуска GitHub‑проектов у себя на localhost.
Принцип работы проекта: предоставляется ссылка на репозиторий, а инструмент сам анализирует проект: ищет Dockerfile, docker‑compose, package.json, requirements.txt, Go/Rust/Python/Node‑признаки, определяет тип приложения и пытается развернуть его в Docker. После запуска показывает локальный URL, контейнеры, логи и дает управлять сервисами прямо из TUI: старт, стоп, рестарт, удаление. По сути это автоматизированная оболочка над git clone, docker build, docker run и docker compose up, только с автоанализом проекта и удобным интерфейсом в терминале.
Важно: инструмент реально запускает код из чужих репозиториев, поэтому случайные проекты лучше гонять в VM/песочнице и внимательно смотреть Dockerfile/docker‑compose перед запуском. Сам Ghostprovider выглядит прозрачным, но риск всегда в том, что именно вы через него запускаете.
Нашел на гитхаб интересный проект от Azure (https://github.com/Azure/co-op-translator). Проект поддерживает автоматический перевод md файлов образовательных ресурсов проектов с гита на различные языки.
GitHub Copilot и Python: настройка, промптинг и сравнение с альтернативами
Copilot экономит время на типовом коде: дополнении функций, заготовках классов и CLI-скриптов, тестах на pytest, парсинге CSV и JSON, обертках над requests. Качество подсказок сильно зависит от контекста — названий функций, комментариев и того, что открыто рядом.
В статье разобрали установку Copilot в VS Code и PyCharm, настройку проекта под Python (venv, расширения, выбор интерпретатора) и практики промптинга, которые повышают релевантность подсказок. Отдельно написали про ограничения, безопасность при работе с секретами и валидацией, и сравнение с Amazon Q Developer, Gemini Code Assist, JetBrains AI Assistant, Tabnine, Cursor и Windsurf.
Немного дурацкий вопрос. Ни кого проблем с открытием github.com не возникает в последнее время?
Сегодня с самого утра работает через раз. То откроет, то висит на установке ssl соединения, после чего страница отваливается по таймауту. Самое обидное, что непонятно в чем дело. То ли дурит провайдер с блокировками от РКН или сам github глючит.
Привет, меня зовут Дима Васильев, я бэкенд-разработчик в Doubletapp. В этом тексте коротко расскажу, как эффективно управлять кодовыми ассистентами с помощью агентских скиллов.
Ассистенты уже умеют читать репозиторий, править файлы и запускать команды, но им часто не хватает контекста команды: как оформлять задачи, какие проверки запускать, как работать со стендами и где нужно подтверждение. Для этого и нужны агентские скиллы.
Скилл — это инструкция для ИИ-помощника: когда её применять, по каким шагам действовать, какие шаблоны и команды использовать. В открытой спецификации Agent Skills скилл обычно оформляется как папка с SKILL.md; рядом могут лежать скрипты, справки и шаблоны.
Подход уже поддерживают разные кодовые ассистенты. GitHub Copilot работает с agent skills в режиме агента, Copilot CLI и облачном агенте. Codex поддерживает скиллы в командной строке, расширении и приложении. Claude Code тоже работает со скиллами через SKILL.md. Поэтому речь не про один инструмент, а про общий способ описывать повторяемые действия команды рядом с кодом.
Кейс 1. Описание проделанной работы
Разработчик закончил задачу, а дальше её должны подхватить тестировщики, аналитики или другие разработчики. Часто в задаче остаётся короткое «сделал», хотя нужно больше контекста.
Можно сделать скилл «описать изменения». Он смотрит на изменения в коде, коммиты и описание задачи, а потом формирует выжимку: что изменилось, какие модули затронуты, как проверить результат, есть ли риски, миграции, настройки или флаги.
Такой скилл помогает не забывать важные детали и делает передачу задачи более предсказуемой.
Кейс 2. Онбординг новых разработчиков
Проектные скиллы полезны для онбординга. В них можно описать, как поднять окружение, как запускать тесты, как оформлять ветки и коммиты, где смотреть логи и какие архитектурные правила нельзя нарушать.
Новый разработчик может спросить помощника: «помоги поднять проект» или «подготовь задачу к сдаче». Помощник ответит с учётом проектных правил, а не общими советами. Это не отменяет документацию, но снижает количество одинаковых вопросов.
Кейс 3. Надстройка над Terraform
Другой пример — сложные инструменты. Допустим, команде нужен Terraform для стендов, но не все хорошо с ним знакомы. Реальных знаний Terraform скилл не заменит: всё равно важно понимать состояние, план изменений, ресурсы и последствия удаления инфраструктуры.
Но для повседневной работы можно сделать понятные действия поверх Terraform:
Init stand — подготовить стенд;
Update stand — применить изменения;
Destroy stand — удалить стенд.
Под капотом ассистент выполняет нужные команды: инициализирует Terraform, выбирает окружение, строит план, показывает изменения, просит подтверждение перед опасными действиями и реагирует на ошибки.
Главное здесь — не просто удобство, а безопасность. В скилле можно прописать: перед применением изменений показать план, перед удалением стенда запросить отдельное подтверждение, не выполнять опасные команды молча и не использовать непроверенные переменные окружения. Так команда получает понятный интерфейс к сложному инструменту, но сохраняет контроль.
Что это даёт
Главная польза скиллов в том, что командные знания становятся частью проекта. Их можно обсуждать и улучшать так же, как код. Это мост между «ИИ просто помогает писать код» и «ИИ помогает соблюдать процессы команды»: оформление задач, проверки, инфраструктура, отчёты, онбординг и документация.
Где посмотреть готовые примеры
Сторонние скиллы стоит читать как чужой код: внутри могут быть скрипты и команды. Особенно внимательно стоит смотреть на скиллы, которые запускают команды.
Наткнулся на свежий разбор от Rost Glukhov, он 21 мая выгрузил через API число звёзд у 20 самых популярных опенсорсных фреймворков для агентов.
Что по цифрам:
→ OpenClaw — 373 тыс. звёзд. В апреле обогнал React и стал самым «звёздным» репозиторием в истории GitHub. Тот самый агент Штайнбергера, который живёт на твоём железе и общается через мессенджеры. Ритм — 62 релиза за месяц, по одному каждые 12 часов. → Hermes Agent от Nous Research — 160 тыс. за 12 недель. Растёт быстрее в неделю, чем OpenClaw в том же возрасте. Держит память между сессиями и сам пишет файлы навыков из успешных задач. → Середина таблицы спрессована между 26 и 43 тыс. — там позиции тасуются за сутки от одного поста на HN: Nanobot (Python, ~4 тыс. строк кода, от лаборатории HKU), AstrBot (самый активный по релизам), PicoClaw (Go, под встраиваемые устройства от Sipeed), AionUi (TypeScript, агентный UI) и ZeroClaw на Rust.
Что мне было интересно из выводов автора:
Во-первых, релизы и звёзды почти не коррелируют. OpenClaw выкатывает 62 релиза в месяц, а пара проектов с десятками тысяч звёзд — ноль.
Во-вторых — и это главное — звёзды измеряют любопытство, а не использование. Что люди реально запускают, показывают токены на OpenRouter, загрузки npm/PyPI и история CVE, а не счётчик в углу репозитория. Звезда стоит один клик; она не значит, что софт хоть раз запустили в проде. Полезное напоминание перед тем, как в следующий раз выбирать стек по «самому популярному на гитхабе».
GitHub Actions не маскирует секреты из фоновых процессов
Настраивал CI, в котором токен доступа переполучается в фоне — раз в 30 минут, пока идут тесты. Первый токен замаскирован через ::add-mask::, но что с экранированием новых токенов в логах? Можно ли вызвать ::add-mask:: прямо из фонового процесса?
В документации GitHub я ответа не нашёл. Там есть только общее место: workflow commands вида ::... раннер читает из stdout шага. А вот что происходит со stdout, который остался от фонового процесса после завершения шага, — непонятно.
Решил проверить — сделал тестовую репу. Схема простая: в одном шаге запускаю background-процесс, который через 15 секунд пишет ::add-mask:: — уже во время следующего шага. Потом специально печатаю секрет: сразу, после sleep, в следующем шаге и в отдельном job’е.
Foreground-секрет (маска из основного процесса) — замаскирован во всех шагах той же job’ы ✅ Background-секрет (маска из фонового процесса) — открыт везде, и до, и после срабатывания ::add-mask:: ❌
Бонус: маски вообще не живут между job’ами — даже foreground-маска в зависимом job’е уже не действует ❌
У нас это, к счастью, не стреляет: переполучение токена уходит в /dev/null, тесты ходят через API, секрет в stdout не попадает. А вот если какой-нибудь refresh-скрипт всё-таки может напечатать новый секрет в лог — на ::add-mask:: из background-процесса рассчитывать нельзя.
Дисклеймер: и код, и текст этого поста написаны в соавторстве с Claude Code.
Наконец-то спустя почти год и два месяца моя CMS-ка для ведения блога получила более менее внятный релиз-кандидат, в котором ошибок осталось не так много, и в принципе система уже легко ставится на хостинг и управляется.
Дашборд системы
Впереди - куча оптимизации, например вынесение всех форм шаблона админки в контроллеры, и последующий их рендеринг через render_form(). Данные контроллеров в json и так далее.
Но - текущая версия движка с последующими обновлениями уже не сломается, как это было в первых релизных версиях.
Ну и самое главное - официальный сайт. Как оказалось - это одна из тех задач, которая весьма объемна и кропотлива - это и документация, и каталог дополнений с API для разработчиков и еще много-много чего.
2. forrestchang/andrej-karpathy-skills (+37.4K звёзд) Файл CLAUDE.md для улучшения поведения Claude Code, основанный на наблюдениях Андрея Карпаты о проблемах LLM при программировании.
4. thedotmack/claude-mem (+12.4K звёзд) Плагин для Claude Code. Автоматически фиксирует работу Claude во время кодинга, сжимает данные с помощью ИИ и добавляет релевантный контекст в будущие сессии.
Исходный код агента Claude Code оказался в открытом доступе из-за технической ошибки. При публикации пакета разработчики не исключили .map-файл, что фактически позволило восстановить значительную часть внутренней логики проекта.
Скриншот GitHub
Репозиторий быстро разошёлся по сообществу: за короткое время он собрал тысячи звёзд на GitHub и был многократно скопирован. Внутри — системные промпты, архитектурные решения, вспомогательные функции и другие элементы, которые обычно остаются закрытыми.
Ситуация наглядно показывает, насколько критичной может быть даже незначительная ошибка в конфигурации сборки — особенно для проектов с закрытой архитектурой.
Мой блог в Телеграм:Хак Так ⬅ поддержите подпиской!
Недавно наткнулся на занятный опенсорс‑проект — GitHub Store (github.com/OpenHub-Store/GitHub-Store). Это такая «оболочка» поверх GitHub, которая делает с репозиториями то же самое, что App Store / Google Play делают с приложениями.
В чём суть
По факту GitHub Store пытается ответить на давно назревший вопрос:
«Почему, чтобы поставить простую утилиту с GitHub, мне нужно идти читать README, искать бинарники, разбираться с релизами, а потом ещё помнить, как это всё обновлять?»
Авторы решили: хватит так жить. Давайте сделаем нормальный стор поверх GitHub, но без своей отдельной экосистемы:
есть лента с трендами и популярными репозиториями — можно просто полистать и найти что‑нибудь полезное, как в обычном магазине приложений;
установка в один клик (ну, почти) — не надо руками лазить по релизам и думать, какой файл скачать;
автоматические обновления уже установленных программ — не нужно помнить, что там выходило, кто из них обновился, а кто нет;
работает на Android, Windows, macOS и Linux — то есть это не очередной «только под одну платформу, остальным держаться».
С точки зрения пользователя это выглядит как нормальный стор: плитки, поиск, категории, тренды. Но под капотом — обычные GitHub‑репозитории. Никакого своего «реестра пакетов», зависимостей и т.п. Всё, что уже лежит на GitHub, становится чуть более человечно упакованным.
Зачем это вообще нужно
Если вы давно сидите на GitHub, то знаете эту боль:
находишь классный проект на Hacker News / Хабре / Реддите;
переходишь в репу;
в README: «build it yourself», 15 шагов, три тулчейна и «tested only on Arch btw»;
если повезло — есть бинарник где‑то глубоко в релизах, но без автообновлений.
GitHub Store как раз пытается это сгладить: вместо «репозиторий с набором файлов» — понятное приложение, которое можно установить и потом обновлять как нормальный софт.
Причём это не замена package manager’ам (apt, brew, winget и прочие), а именно интерфейс к тем проектам, которые туда никогда не доедут: личные тулзы, мелкие утилиты, нишевые программы, эксперименты.
Автор проекта прямо пишет, что идея — собрать в одном месте тысячи программ, которых вы не увидите ни в одном официальном сторе, но которые живут на GitHub, звёзды собирают, а до пользователя так и не доезжают.
Чем это похоже на App Store, а чем — нет
Похоже:
есть витрина: тренды, популярное, поиск;
есть установка в одно действие;
есть обновления, о которых думать не нужно.
Не похоже:
нет централизованной модерации в духе Apple/Google — это всё равно GitHub, со всеми вытекающими;
нет единого UX по установке/запуску (проекты разные, и у каждого свои особенности);
безопасность пока, очевидно, на уровне «как в GitHub»: вы сами решаете, кому верить.
То есть это не «новый стор, который победит все остальные», а надстройка над тем, чем GitHub по факту давно является — огромным складом софта, где интерфейс для обычного пользователя исторически был «так себе».
Кому это вообще может зайти
Тем, кто любит ковыряться в GitHub и искать новые инструменты, но устал превращать каждый проект в квест.
Тем, кто живёт на Linux / Windows / macOS, использует кучу мелких утилит и хочет держать их в одном месте с автообновлениями.
Тем, кто сам пилит опенсорс: это ещё один канал донести свой проект до людей, которые не любят GitHub, но любят «поставить и пользоваться».
Что в итоге
Идея «сделать стор поверх GitHub» витала довольно давно, но тут её хоть кто‑то нормально попробовал свернуть в рабочий вид, да ещё и кроссплатформенно.
Пока это выглядит как удобная человеческая морда к GitHub, а не очередной велосипед ради велосипеда. Если у вас жизнь связана с опенсорсом (или вы просто любите новые игрушки), проект точно стоит хотя бы посмотреть.
Ну и по классике: это опенсорс, так что можете не только поставить, но и прийти с PR’ами, если чего‑то не хватает или кажется сделанным криво.
Представлен открытый мультиплатформенный проект GitHub Store. Это GitHub в виде магазина с приложениями — скачивать, обновлять и устанавливать ПО с платформы теперь можно, как из обычного магазина приложений:
GitHub визуализировали в цифровой город в проекте gitcity. В рамках проекта представлен сайт, на котором можно летать по «городу», где каждое здание это аккаунт разработчиков. Высота небоскребов = количеству коммитов. Летая по городу, можно искать интересные и популярные аккаунты, либо находить что-то новое и недооцененное.
«Ну что, пацаны, расчехляйте кошельки! Сэм Альтман официально представил нам GPT-5.4 — венец корпоративного запора смыслов.
Посмотрел я на эти цифры и вот что скажу:
Про "Computer Use": OpenAI наконец-то разрешили модели нажимать на кнопки. Теперь Клод не одинок в своих попытках закрыть всплывающее окно три часа подряд. Но давайте честно: давать модели с «экстремальным мышлением» (xhigh) доступ к интерфейсу — это как посадить профессора философии за пульт управления экскаватором. Он будет очень долго рассуждать о смысле рытья траншеи, пока у вас горят токены по $180 за миллион.
Про "Thinking" и планы: То, что модель теперь показывает план работы — это не фича, это «явка с повинной». Они просто легализовали тот факт, что модель постоянно «плывет», и теперь перекладывают ответственность на юзера: «Слушай, я тут надумала какой-то дичи, ты чекни план, а то я за твои бабки сейчас такого наворочу...».
Экономика абсурда: Цена выросла, но нам говорят про «токеноэффективность». Это классический маркетинговый ход: «Наши деликатесы стали дороже, но теперь они настолько калорийные, что вам хватит одного запаха». На самом деле, с учетом «компакции» и «агентских сценариев», вы будете скармливать этой махине бюджет небольшого африканского государства просто за то, чтобы она «подумала» над вашим легаси-кодом.
Главный Гы: Обратите внимание на отчет о «контролируемости» (CoT controllability), который вышел прицепом. Модель 5.4 настолько «безопасная», что она буквально боится собственных мыслей. Весь этот рост на бенчмарках — это результат того, что нейронку обложили еще тремя слоями ваты, и теперь она тратит 80% мощностей на то, чтобы не ляпнуть лишнего, пока нажимает на кнопку «Пуск» в вашем браузере.
Итог: Мы получили идеального корпоративного биоробота. Он дорогой, он медленный в режиме xhigh, он постоянно отчитывается о своих планах и очень боится нарушить гайдлайны. Пока китайцы из DeepSeek дистиллируют чистую логику, OpenAI строит самый дорогой в мире Железный Сфинктер, который пытается удержать смысл внутри, пока токены утекают наружу.
Часики тикают, Сэм. А мы пока посидим на GPT-5.2 и подождем, пока 5.4 научится хотя бы не извиняться перед скриншотами.
Гы.»
Это ответ другого ИИ на новость о выходе ChatGPT 5.4
