Как за 1 час собрать рабочий Skill в Claude

Это не теория, а простой пайплайн, который реально работает.

Сначала идея
Берёшь повторяющуюся задачу и сразу формулируешь, что именно должен делать скилл. Лучше максимально конкретно.

Дальше сборка
Запускаешь skill-creator и отвечаешь на вопросы. На выходе получаешь папку и SKILL.md с логикой, триггерами и инструкциями.

Потом тест
Пробуешь на реальных запросах. Смотришь, срабатывает ли там, где нужно.

Оценка
Смотришь eval. Это шаг, который почти все пропускают, а зря. Он показывает, где скилл ведёт себя нестабильно.

Доработка
Чистишь формулировки, уточняешь триггеры, убираешь лишние срабатывания.

Финал
Загружаешь в Capabilities → Skills и проверяешь уже в живом чате.

Как ускорить процесс

Открой Claude Cowork
Выбери Opus + Extended Thinking
И просто напиши:
"Помоги создать скилл для моей повторяющейся задачи"

Главное правило

Если скилл срабатывает лишний раз, проблема почти всегда в описании.

Хороший скилл - это не код, а правильно заданный контекст.

https://www.youtube.com/shorts/GhgKXX0mdxk

⚡️ Вы слышали про Rust. Знаете, что он быстрый, безопасный и что за ним будущее.

Осталось одно: сесть и выучить.

Этот курс со Stepik- кратчайший путь от «знаю что такое Rust» до «пишу на нём».

6 модулей, 50 уроков, 143 теста. Ownership, borrowing, traits, async, Tokio, Axum, макросы, WASM — всё разложено по полочкам и закреплено практикой.
Никакого видео на 40 минут ради одной мысли. Подробный текст, много кода, реальные задачи после каждого урока. На выходе — портфолио из 10+ проектов: от CLI-утилит до REST API с базой данных.

48 часов действует скидка 55 процентов: stepik.org/course/269250

Продвинутый SQL-прием: partial index вместо “универсального” индекса

Если в таблице много строк, но запрос почти всегда смотрит только активные записи, не обязательно индексировать всё.

Например, есть таблица заказов:

SELECT *
FROM orders
WHERE user_id = 42
  AND status = 'active';

Обычный индекс:

CREATE INDEX idx_orders_user_status
ON orders(user_id, status);

Работает, но он хранит данные по всем статусам: active, cancelled, archived, failed и так далее.

Если чаще всего нужны только активные заказы, можно сделать partial index:

CREATE INDEX idx_orders_active_user
ON orders(user_id)
WHERE status = 'active';

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

SELECT *
FROM orders
WHERE user_id = 42
  AND status = 'active';

Индекс не обязан покрывать всю таблицу. Иногда лучший индекс - это индекс только по тем строкам, которые реально участвуют в горячих запросах.

Особенно полезно для флагов вроде deleted_at IS NULL, status = 'active', is_published = true, processed = false.

#sql #postgresql #database #backend

🖥️✨ Hermes Web UI: Интуитивный веб-дашборд для управления AI чатами. Позволяет отслеживать использование, настраивать каналы и управлять заданиями через удобный интерфейс.

🚀Основные моменты:
- Мультисессионное управление чатами с поддержкой различных платформ.
- Аналитика использования токенов и отслеживание затрат.
- Настройка и управление заданиями по расписанию.
- Интегрированный терминал для работы с несколькими сессиями.

📌 GitHub: https://github.com/EKKOLearnAI/hermes-web-ui

#javascript

🚀 Логическая аналитика с LynxDB

LynxDB — это легковесная система для анализа логов, работающая в одном бинарном файле без зависимостей. Она использует язык запросов Lynx Flow, позволяющий легко обрабатывать данные в виде конвейера.

🚀 Основные моменты:
- Пайплайн-запросы для обработки данных
- Полнотекстовый поиск и колоночное хранилище
- Поддержка кластерного режима и материализованных представлений
- Никакой конфигурации — разумные настройки по умолчанию
- Активная разработка, обратная связь приветствуется

📌 GitHub: https://github.com/lynxbase/lynxdb

#rust

wtf 💀

🚀 Примеры использования Cursor SDK для разработки

Репозиторий содержит небольшие примеры для работы с Cursor SDK на TypeScript. Он позволяет интегрировать кодирующего агента в ваши приложения, управлять состоянием и взаимодействовать с агентами в облаке и локально.

🚀 Основные моменты:
- Примеры для создания агентов и работы с API.
- Веб-приложение для быстрой разработки и тестирования.
- Канбан-доска для управления агентами и артефактами.
- CLI для запуска агентов из терминала.

📌 GitHub: https://github.com/cursor/cookbook

Редкий и реально продвинутый SQL-совет: используй логарифмы для произведения вероятностей.

В SQL удобно считать SUM, AVG, COUNT, но почти никто не думает про PRODUCT. А в аналитике он часто нужен: вероятность цепочки событий, retention funnel, скоринговые модели, reliability, ML-фичи.

Проблема: если перемножать много маленьких чисел, например 0.97 * 0.91 * 0.88 * ..., быстро получишь underflow или потерю точности.

Математический трюк:

a * b * c = exp(ln(a) + ln(b) + ln(c))

То есть вместо прямого произведения считаем сумму логарифмов.

SELECT
    user_id,
    EXP(SUM(LN(probability))) AS total_probability
FROM events
WHERE probability > 0
GROUP BY user_id;

Где это полезно:

SELECT
    user_id,
    EXP(SUM(LN(conversion_rate))) AS funnel_survival_rate
FROM funnel_steps
GROUP BY user_id;

Это стандартный численный прием из математики, который делает расчет стабильнее.

Особенно полезно, когда у тебя много шагов в воронке, вероятностная модель, риск-скоринг или аналитика событий.

Главное правило: LN(x) работает только для x > 0, поэтому нули нужно обрабатывать отдельно. Например, если хотя бы одна вероятность равна нулю, итоговое произведение тоже будет ноль.

⚡️ Один SQL-запрос выполнялся за 298 мс.

Почти такой же - за 0,66 мс.

Разница в 451 раз из-за одной строки.

Ситуация обычная: cursor pagination, сортировка по date DESC, id DESC, лимит на 1000 записей и composite index по (date, id). На первый взгляд, все должно работать быстро.

Но EXPLAIN ANALYZE показывает другое: Postgres вроде бы использует Index Scan, но после этого выкидывает 900 000 строк через Filter.

То есть индекс есть, но запрос все равно тащит слишком много лишнего.

Проблема в условии:

`date < @date OR (date = @date AND id <= @lastId)`

Для разработчика это выглядит логично: сначала сравниваем дату, потом id.

Но для оптимизатора такой OR плохо ложится на composite index. В итоге база не может сразу пойти по нужному диапазону и вынуждена фильтровать огромный кусок данных.

Правильнее записать условие через tuple comparison:

`(date, id) <= (@date, @lastId)`

Смысл тот же, но для Postgres это уже понятный диапазон по составному индексу.

И результат: 298 мс превращаются в 0,66 мс.

Индекс сам по себе ничего не гарантирует.

Важно не только создать индекс, но и написать запрос так, чтобы оптимизатор реально смог его использовать.

Claude можно превратить в личного сборщика презентаций: https://www.youtube.com/watch?v=5RNTmbbyUHw

Большинство людей просят AI: «сделай слайды» - и получают обычный текст, который потом приходится вручную переносить в PowerPoint.

Но есть способ лучше: сделать для Claude отдельный Skill под презентации.

Открываете Claude, заходите в Customize, выбираете Skills, создаете новый skill и вставляете туда свои правила: какие презентации вы делаете, для какой аудитории, в каком стиле, какая структура нужна и что должно быть на каждом слайде.

После этого Claude перестает гадать.

Он уже знает, как должен выглядеть ваш deck: где нужен сильный opening slide, где краткий executive summary, где схема, где таблица, где финальный CTA.

Главная мысль простая: чем точнее instructions, тем меньше ручной переделки.

Вместо хаотичного «сделай презентацию» вы получаете повторяемый workflow: один раз настраиваете skill, а дальше Claude собирает слайды по вашим правилам.

Это не магия. Это нормальная упаковка контекста, стиля и структуры в reusable-инструмент.

Именно так AI начинает работать не как чат-бот, а как часть вашего production-процесса.

https://www.youtube.com/shorts/qyYOG338hyY

Открыл Claude, написал большой промпт - получил обычный нейротекст.

Рабочая схема другая.

Сначала делаете файл about-me.md.
Туда кладёте:
кто вы,
для кого пишете,
какой стиль нужен,
что бесит в текстах,
какой результат хотите получать.

Потом подключаете этот файл в Cowork, чтобы Claude читал его перед каждой задачей.

И только после этого даёте реальную задачу:
пост, план, письмо, разбор, аудит.

Главный трюк - перед стартом заставьте Claude задать уточняющие вопросы. Не угадывать, а сначала понять задачу.

В итоге он пишет не «как ИИ», а ближе к вашему стилю, потому что у него есть контекст.

https://youtube.com/shorts/JjGrRyt_HBM

🤖 Machine Learning Roadmap: от базы до гуру вайбкодинга

Карта обучения машинному обучению (Machine Learning, Deep Learning, LLM, Generative AI, MLOps) - от первого import numpy до уровня инженера, который понимает, как ИИ работает внутри, и может писать прод‑системы, а не только дёргать API.

https://github.com/justxor/MachineLearningRoadmap/tree/main

🔥 Huawei хочет обойти санкции не нанометрами, а задержками в чипе

Huawei представила Tau Scaling Law - подход, который должен ускорять чипы не только за счёт уменьшения транзисторов, а за счёт сокращения времени прохождения сигнала внутри схемы.

Идея простая: если нельзя быстро догнать TSMC и Intel по литографии, нужно выжимать больше из архитектуры, трассировки, памяти, interconnect и софта. Меньше лишнего пути для сигнала - меньше задержка, выше плотность и эффективность.

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

Huawei утверждает, что за последние шесть лет уже спроектировала и массово выпустила 381 чип с этим подходом, а будущие Kirin осенью 2026 года станут первым крупным тестом LogicFolding.

Самая громкая заявка - к 2031 году выйти на плотность уровня 14Å, то есть примерно 1,4 нм, без прямой зависимости от классического shrink.

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

Это не отменяет физику и не делает Huawei новым TSMC завтра. Но показывает, куда может сдвинуться гонка чипов: не только «у кого меньше нанометры», а «кто лучше сокращает задержки по всему стеку».

huawei.com/en/news/2026/5/ieee-iscas-tau-scaling