Как дела у Зои TLDR — прорывов нет, работаем. Реклама продолжает болтаться вокруг прибыльности — чтобы нормально достроить финмодель, надо подождать ещё 2 месяца, чтобы когорты. пришедшие на текущую версию продукта, стали хоть чуть-чуть зврослее. По фичам — запустили медицинские карты: теперь модель знает, какие лекарства и диагнозы есть у пользователя. Доработали память — теперь контекст старых бесед не теряется: это важно, т.к. количество сообщений у активного юзера измеряется сотнями. Научили модель просматривать историю анализов и искать врачей, добавили голосовухи (на удивление не так уж и востребованные, подозреваю технические проблемы). Скоро запустим мобильное приложение и тудушки — чтобы пользователь вместе с моделью планировал свои медицинские дела. Очень необычно себя чувствовать одновременно CEO, который берётся за всё непонятное и думает про стратегию, и разработчиком, который просто пилит фичи. Во всех прошлых продуктовых забегах я ограничивался ролью CTO, изолировал себя от маркетинга. А сейчас осознал, что кроме меня это никто не сделает — и поменял букву T на E. Жутко интересно и страшно — только живых денег потратили уже 1.3 млн, и дальше эту сумму надо только увеличивать.

#рецепт В чём настоящая ценность Agent Skills. Часть 2 В прошлой части я докрутил мысль, что skill - это workflow package, а не промпт в папочке. Теперь о том, почему у одних скиллы работают, а у других превращаются в markdown-папку с надеждой на чудо или вообще не вызываются Главный подвох: настоящий прикол не только в SKILL.md, а в связке Skill + Agent Harness. Harness - это рантайм вокруг модели: поиск skills, выбор нужного, загрузка инструкций, запуск tools/MCP/shell, права, traces, approvals. Хороший инженерный разбор есть у Addy Osmani: https://addyosmani.com/blog/agent-harness-engineering/ 1) Progressive disclosure - причина почему скиллы масштабируются Агент не должен держать в контексте всю корпоративную библиотеку знаний. Сначала он видит только name + description, потом при выборе грузит SKILL.md, а уже после этого читает references/, assets/, examples/ или исполняет scripts/ Именно поэтому skill лучше гигантского AGENTS.md на 3000 строк. AGENTS.md - always-on фон, skill - on-demand способность. У Codex это описано тут: https://developers.openai.com/codex/skills, у Claude Code тут: https://code.claude.com/docs/en/skills (с CC конечно есть нюансы) Практический совет: в SKILL.md оставляй короткую процедуру, а длинные политики, API-доки, JQL-справки, шаблоны отчетов и примеры выноси в references/assets/examples. Если SKILL.md раздулся в трактат, вероятность его работы крайне низка 2) description - главный триггер, а не аннотация для красоты Частая ошибка: красивое тело скилла и бесполезный description. Агент выбирает skill именно по description, поэтому "Helps with code" - мусор. Это как задача в Jira с названием "Сделать нормально" Нормальный description отвечает: какую задачу делает skill, когда применять, какие слова его триггерят, какие входы нужны, какой результат вернуть и когда НЕ использовать. Пиши скиллы на 1 языке, не используй англорусский, шалоказахский и хинглиш Плохой пример: Helps with project management Лучше: Checks Jira sprint health, finds blocked issues, stale tasks, missing owners and release risks. Use before daily status update or weekly project report. Do not use for backlog prioritization Для проектирования смотри skill-creator от Anthropic: https://github.com/anthropics/skills/blob/main/skills/skill-creator/SKILL.md 3) Anti-rationalization надо писать прямо в инструкции Агент любит срезать углы не хуже менеджера перед пятничным демо. Он легко скажет изменение маленькое, визуально норм, тест-ран тут большой не надо запускать и тд. Поэтому в skill надо писать правила против отговорок Примеры: - - - - если есть diff, сначала inspect, потом summary, потом plan - если действие меняет внешнюю систему, сначала dry-run - если есть write/delete/update, нужен explicit approval - если нет данных, верни missing context, а не додумывай - если scanner не запускался, не пиши что проверка пройдена - - - В twinby я бы такие штуки паковал в jira-daily-radar, spec-quality-checker, release-readiness, browser-manual-test и confluence-sync. Не "агент, расскажи статус", а процедура: откуда читать, что считать риском, какой формат отчета, где нужен человек 4) Skill надо тестировать не только на результат, но и на срабатывание Минимальный набор: - explicit activation test: вызвался руками - implicit activation test: вызвался по естественному запросу - negative test: не вызвался там, где не должен - golden samples: вход -> ожидаемый выход - unit tests для scripts/ - trace review: видно какие шаги реально прошли - with/without skill: есть ли прирост качества, времени или стабильности По evals полезны OpenAI материалы: https://developers.openai.com/blog/eval-skills и разбор Phil Schmid: https://www.philschmid.de/testing-skills Хороший skill скучный: он умеет только 1 штуку делать, явно триггерится, явно проверяет, явно падает и явно просит апрув. Всё остальное обычно демка для LinkedIn/X/чата ваших фанатов в телеграм

#рецепт В чём настоящая ценность Agent Skills. Часть 1 Здравствуй, дорогой читатель. Скиллы до сих почти никто не понял. Я уже писал вводный пост про скиллы и почему менеджерам стоит смотреть на них как на святой грааль: https://t.me/junior_pm/422 После доклада про Agentic Harness хочу докрутить мысль инженернее. Скилл - это не "промпт в папочке", а слой поведения агента. MCP, API и CLI дают агенту руки, а skill объясняет, когда этими руками не стоит случайно уронить запросом БД, переписать ТЗ или сделать ревью уровня "в целом норм" 1) Agent Skill - это workflow package Если давать адекватное определение, скилл -> самодостаточный пакет процедурного знания, который агент динамически загружает для решения задачи Если разложить по-честному, то prompt - это разовая инструкция, script - детерминированный код, MCP tool - доступ к действию, subagent - отдельный worker, AGENTS.md/rules - фоновые правила проекта. Skill находится между всем этим: он говорит агенту, когда применять процесс, как идти по шагам, какие артефакты читать, какие проверки делать и где остановиться за апрувом Реализуется в формате папка с SKILL.md (YAML + Markdown) + опциональные файлы. Skill.md = metadata + instructions + optional references + usage policy. Открытый формат лежит тут: https://github.com/agentskills/agentskills, реальные примеры от Anthropic тут: https://github.com/anthropics/skills, у OpenAI Codex механика описана тут: https://developers.openai.com/codex/skills 2) Skill хорошо ложится на BPMN-мышление процессников description - триггер процесса, тело SKILL.md - шаги, When to use / When not - гейты, scripts/ - подпроцессы, references/ - политики и справка, assets/ - шаблоны, examples/ - эталонные входы/выходы, allowed-tools - права. Те это уже не markdown с советами, а почти исполняемая процедура Менеджерский кайф тут простой: можно перестать пересказывать агенту как у нас принято и начать версионировать это в Git. Не Тимлид Петя знает как делать ревью, а code-review/SKILL.md, пошаренный на всех и прописанный хуком всем перед отправкой MRa 3) Скиллы органично зарождаются и эволюционируют: 0. Замечаешь что пару раз в неделю делаешь одно и то же. Ctrl + c - Ctrl + v инструкция аля в Claude Code 1. Описываешь повторяющееся действие и структурируешь в промпт 2. Переносишь промпт в формат agent skills, чисто враппер 3. Добавляешь в скилл воркфлоу с гейтами что, после чего и как проверять 4. Объясняешь скилл как писать скрипты для решения задачи в моменте 5. Делаешь готовые шаблоны и скрипты и прикладываешь их в скилл, чтобы он их вызывал 6. Выносишь весь дактайпинг, шейрд и прочее из скриптов в общие ассеты, энвы и конфиги 7. Оборачиваешь скрипты в MCP или CLI 7. Переписываешь проект на чистовой бойлерплейт и правильную структуру 8. Распространяешь В twinby я смотрю на это именно так: не заменим людей агентами, а вытащим повторяемые куски работы в управляемый слой. Например, как собирать апдейты по джире, как проверять на корректность ТЗ, как автоматизировать ручные тесты в браузере и тд Практический вывод Первый skill стоит делать не про агенты, инстаграм инфоцыганщину про Agent OS/Second brain/AI native team, а про маленькую повторяемую проверку: backlog hygiene, PR review precheck, release readiness, spec quality checker, repo safety scan. Чем уже граница, тем проще проверить качество и тем меньше шанс собрать очередной карго-культ в красивой папке, нужный 1 человеку

Невыносимая слопность бытия Бывает так, что открываешь статью, всё в ней написано чисто и по делу, а к третьему абзацу ловишь себя на желании закрыть вкладку, хотя устать по объёму ещё рано. Автор называет это песком в глазах и замечает любопытную вещь. Дело не в том, что текст сложный. Когда читать реально тяжело физически, кривой шрифт или запутанный синтаксис, понимание от этого не проседает, это проверяли отдельно. А слоп лёгкий, прозрачный, и всё равно отталкивает. Значит, мозг цепляется не за смысл, а за форму. Он вылавливает повтор композиции раньше, чем дочитывает мысль до конца, и начинает реагировать на сам факт узнавания. В статье эта форма разобрана до десяти конкретных приёмов, по которым неотредактированный ИИ-черновик узнаётся с первого абзаца, плюс объяснение, почему разметчики невольно научили модели писать именно так.

Электронный репеллент Комары боятся стрекоз – стрекоза их ест. Значит, если телефон будет жужжать так же, как машут крылья стрекозы, комары решат, что рядом хищник, и улетят. Химии на коже не надо, покупать ничего не надо. Идею реализовал #стартапдня Anti Mosquito Repellent Sound. Внутри приложения выбор частот и большая кнопка «включить». Кусают комары – нажимаешь кнопку. Продолжают кусать – меняешь частоту: местные стрекозы, значит, по-другому летают. К сожалению, наука утверждает, что работать это в принципе не может. Стрекозы машут крыльями 30 раз в секунду – это 30 герц, а iPhone минимально воспроизводит 200 герц. Кроме того, кусающие самки вообще почти глухие – слух у комаров мужское дело, самцы им ищут самок. И, кстати, там другие рабочие частоты, не стрекозиные. И, наконец, были прямые исследования с правильно жужжащими отпугивателями – нет, даже они бесполезны. Приложение не должно работать тем более. Но кому и когда мешали такие рассуждения. В реальной жизни все у стартапа хорошо. В сторе аппка лежит 9 лет, регулярно обновляется, поддерживает 23 языка, собрала десятки тысяч оценок с вполне приличным баллом 4.2-4.3 в разных странах. В субботу мне её довольный пользователь демонстрировал. Он и подписку, наверное, платит. https://apps.apple.com/us/app/anti-mosquito-repellent-sound/id1242188677 #насвои #насеройстороне

👫 H2H-маркетинг: как брендам привлечь потребителей и снова вернуть их доверие С развитием нейросетей люди стали меньше доверять рекламе и больше ценить простое человеческое общение. А я теперь все чаще слышу про маркетинговую модель H2H. Рассказываю, в чем ее суть и как это использовать бизнесу. 💡 Что такое H2H-маркетинг? Расшифровывается как Human-to-Human (Человек-к-Человеку). Это маркетинговая модель, цель которой - построить личные и доверительные отношения с потребителями. Традиционные модели обычно фокусируются на категории клиента. В сфере B2B реклама апеллирует к логике и рассказывает об окупаемости - ведь решение о покупке принимает бизнес. В B2C делают ставку на эмоциональных и социальных преимуществах продукта, который получит человек после покупки. H2H-маркетинг всегда ориентируется на человеческие истории. Главное при таком подходе - люди с их желаниями, сомнениями и потребностями. Вот как использовать модель предпринимателям и маркетологам. 🤝 Показывайте людей, которые стоят за брендом. Расскажите о ценностях и мотивации основателя, покажите, чем увлекаются сотрудники, и что их вдохновляет. Или даже запостите фотки рабочих будней. Это превратит бренд из холодной корпорации в сообщество живых людей. 🤝 Будьте честны. Если сделаете ошибку, лучше признать ее публично - так вы покажете, что тоже живой человек, и можете накосячить. Удивительно, но уязвимость и честность создают более глубокую связь, чем идеальный образ. 🤝 Вовлекайте клиентов в создание продукта. Спрашивайте мнение аудитории через соцсети и опросы, корректируйте продукт на основе обратной связи и рассказывайте, как именно потребители помогли вам. Люди ценят, когда их слышат. 🤝 Вдохновляйтесь UGC-контентом. Используйте минимум постановки и больше показывайте реальные эмоции. Самые популярные ролики выглядят так, будто вы не рекламу снимаете, а хвастаетесь покупкой перед друзьями. 🤝 Нанимайте сотрудников, которым близок дух бренда. Так менеджерам не придется заучивать скрипты. Они просто будут общаться с клиентами естественно, и люди почувствуют искренность. 🤝 Ориентируйтесь на качество, а не количество касаний. Лучше один осмысленный разговор, чем сотни холодных звонков. 🤝 Создавайте сообщества. Пусть клиенты общаются, делятся опытом и рекомендуют продукты друг другу - так доверие к бренду вырастет само по себе. 🤝 Используйте ИИ в меру. Поручите ему провести исследование или сделать анализ. Креативом и общением с клиентами лучше пусть занимаются люди. А вы уже практикуете H2H-маркетинг? И как вам? Заходите в комментарии, делитесь опытом. 👉🏼 Подписывайтесь на «Телеграмму...» в Максе: max.ru/yumaks #МАРКЕТИНГ #НАСМОТРЕННОСТЬ #СОВЕТЫ

XYZ-Aquila-mini: компактная reasoning-модель для глубокого веб-поиска XYZ AI Lab выпустила XYZ-Aquila-mini под Apache 2.0. По заявленным результатам модель лидирует среди open-weight моделей до 40B сразу на нескольких поисковых бенчмарках: * GAIA - 97.1 * DeepSearchQA - 89.5 * BrowseComp - 78.8 Модель заточена под длинные цепочки планирования, поиск по англоязычному и китайскому вебу, проверку источников и восстановление после ошибок при работе с инструментами. Контекст до 256K токенов. Отдельно интересен их подход AI4AI: люди задают цели, ограничения и критерии качества, а ИИ-агенты сами разбирают ошибки и предлагают контролируемые изменения для post-training. Модель: https://modelscope.ai/models/XYZAILab/XYZ-Aquila-mini

📄 Что такое XPath Injection? Когда речь заходит об инъекциях, обычно вспоминают SQL Injection. Но не все приложения используют базы данных SQL. Некоторые работают с XML-документами, а для поиска данных применяют язык запросов XPath. Именно здесь может возникнуть уязвимость XPath Injection.

📌 XPath Injection — это уязвимость, при которой злоумышленник может повлиять на XPath-запрос, изменив его логику с помощью специально сформированного пользовательского ввода.

Другими словами, приложение начинает искать данные не так, как задумал разработчик. 🧠 Что такое XPath?

XPath (XML Path Language) — это язык запросов, который используется для поиска элементов в XML-документах.

XML может применяться для: — хранения настроек приложения; — обмена данными между сервисами; — хранения информации о пользователях; — работы с некоторыми устаревшими корпоративными системами. 💀 Чем это опасно? Если приложение уязвимо, атакующий может: — обойти проверку подлинности; — получить доступ к данным, которые не должен видеть; — извлечь конфиденциальную информацию; — изменить логику поиска данных. Последствия зависят от того, какую роль XML играет в работе приложения. 🛡 Как защититься? Основные рекомендации: — не формировать XPath-запросы путём объединения строк; — проверять и валидировать пользовательский ввод; — использовать безопасные механизмы передачи параметров в запросы; — ограничивать доступ к конфиденциальным XML-данным. 📌 Сегодня XPath Injection встречается значительно реже, чем SQL Injection или XSS, поскольку XML всё чаще уступает место JSON. Однако во многих корпоративных системах, интеграционных решениях и устаревших приложениях XML по-прежнему активно используется, поэтому знание этой уязвимости остаётся полезным для специалиста по веб-безопасности. #web #owasp #xpath #xml #injection #pentest

В последнее время стал чаще юзать Codex, но именно его стиль ответов не очень нравится Так что всегда включал скилл humanizer чтобы убирать ИИ-слоп из ответов и документов которые он пишет Этот скилл неплох, но в основном просто исправляет формулировки, сохраняя исходный смысл, но не улучшая читаемость Так что именно для ответов агента, которые сам читаешь, нашел новый скилл: i-have-adhd Он построен на принципах которые помогают людям с СДВГ легче воспринимать информацию:

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

Прикрепил сравнение всех трех вариантов, как по мне i-have-adhd самый читаемый Оба скилла хорошо работают с русским и любыми другими языками 😏 @tips_ai #tools