Прикольно, работает:

https://t.me/oestick/570

Интересно о [не]полноте верования:
https://t.me/essaurgey/336

МИМ в физической реальности, интересненько:

https://t.me/system_school/2283

Напоминает технику Фельденкрайза и йогу.

Сделал в узком кругу доклад по этому навыку, прилагаю презентацию

Выложил компактную версию (46 КБ инструкций против 96 КБ у полной версии) скилла project-vault:

https://github.com/dimonier/skills/tree/main/skills-compact/project-vault

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

Использовать вместо (не вместе) полной версии этого же скилла.

Разъяснение о компактизации контента для LLM

Смысл - перевод текста с обычного человеческого языка в блок текста, который LLM понимает ~так же хорошо, но который жрёт меньше токенов.

- Пример компактизованного паттерна (одного из) скилла Pattern Language as Agent Skill - 3396 байт
- Тот же паттерн в полном виде - 7211 байт
- Скилл episteme-compaction для преобразования первого во второе и обратно

Примечания.
1. Чисто для понимания LLM-ами компактизованного материала скилл не нужен, LLM уровня Qwen 3.8 27B норм справляется без доп. указаний.
2. Компактизация текста уместна в любых кейсах, где пишем текст для дальнейшего потребления LLM один раз, а читаем/используем много раз (например скилл или долговременная память какая-нибудь).

Попросил Гермеса собрать видосик про скилл project-vault, потом ещё и ещё, потом переписал 70% дикторского текста.

В итоге вроде более-менее репрезентативно получилось
(хотя местами нейрослоп всё ещё проглядывает, сорри)

Протестировал 4 способа доставки инструкций до ИИ-агентов в несколько подходов на примере спецификации FPF, финальный результат тут:
https://systemsworld.club/t/agent-skills-kak-format-doneseniya-metoda-raboty-do-ii-agenta/41439/6?u=dimonier

А вы знали про ASD-STE100?

ASD-STE100 (Simplified Technical English) — ограниченный язык, обязательный для реальных руководств по техобслуживанию. Жёстко ограниченный словарь, одно слово = одно значение, одно действие = одно предложение, синонимов нет, опасные действия — отдельным блоком. Причина, по которой авиация это ввела: читатель уставший, часто не носитель языка, работает под давлением.

Если попросить ИИ-шечку объяснить что угодно по ASD-STE100, получается доходчиво, в т.ч. по-русски (но без нюансов, т.к. лексикон ограничен).

Вот объяснение основ git языком авиатехника (для чего этот язык как раз подходит).

Четыре зоны
Дальше — только этот порядок. Не путай.

1. Рабочая зона (working tree)
Работа идёт. Файлы как есть. Никто их не принял. Случайное изменение и намеренное здесь равны.
Коротко: ещё не заявлено.

2. Заявка (staging, index)
Ты вручную объявил: вот это я хочу принять. Заявка = наряд на приёмку. Заявку можно переписать. Она ничего не фиксирует.
Коротко: заявлено, но не принято.

3. Запись (commit)
Снимок + провенанс: кто, когда, почему. Запись не редактируют. Ошибку исправляют новой записью.
Коротко: принято и подписано, но пока только у тебя.

4. Публикация (push)
Передача записей в общий ангар. До публикации работа существует в одном экземпляре. Диск умрёт — работа умрёт.
Коротко: принято и у всех.

Разница — по одной строке
- Рабочая зона: ещё не заявлено.
- Заявка: заявлено, но не принято.
- Запись: принято, подписано, у тебя.
- Публикация: принято, у всех.

Процедура. Закрыть изменение
1. Осмотр. git status — всегда первым.
2. Отметь изменённое. git add файл (или git add -A).
3. Проверь заявку. git status, git diff --staged.
4. Запиши. git commit -m "что и почему".
5. Проверь журнал. git log --oneline.
6. Передай. git push.

Опасное — отдельно
⚠️ ПРЕДУПРЕЖДЕНИЕ. git push --force удаляет чужие записи в общем ангаре. Без разрешения не применяй.
⚠️ ВНИМАНИЕ. Рабочая зона не защищена. Не закрывай смену с незаписанной работой.
📌 ПРИМЕЧАНИЕ. Заявка исчезает. Запись остаётся.
📌 ПРИМЕЧАНИЕ. Git ведёт формуляр у тебя на машине. GitHub — общий ангар, место обмена. Это разные вещи, новички их путают.

Три слова, которые встретишь дальше
- Ветка (branch) — отдельная линия записей. Черновик, который не мешает основной линии.
- Свод (merge) — соединить две линии записей.
- Расхождение (conflict) — две записи правят одно место. Стоп. Не угадывай. Разбирай руками.

Многие ли изучают мир так? Да, это стандартная и сильная техника.
В авиации это не метафора, а закон. Руководство, написанное «нормальным» языком, непригодно к эксплуатации.

Авиационный ход идёт снизу: что сделать → что проверить → что будет, если ошибиться.
Техруководство отвечает на вопрос «что мне сделать и чем я заплачу за ошибку?»

Для старта в Git второе важнее: оно меняет поведение, а не только понимание. Ты не «понял» — ты теперь знаешь, где место заявки и что исчезнет, если не сделать push. Это разные уровни усвоения.

Как сделать ответы LLM читаемыми - лестница из 4 ступеней

Полный текст во вложении.

Ниже пример первой ступени применительно к ее описанию в этом же материале (о ней был предыдущий пост, с примером про git):

Проблема не в модели. Проблема в том, как вы просите её объяснять.

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

Андрей Карпатый написал об этом пост 2 октября. Он один из основателей OpenAI в прошлом. С мая 2026 года он работает в Anthropic, в команде, которая обучает Claude. Его мысль: ИИ делает всё больше работы сам. Работа человека смещается в проверку и понимание сделанного.

Карпатый предложил лестницу из четырёх ступеней. Каждая следующая ступень, по его словам, лучше предыдущей. Ступени работают не только в Claude Code, но и в Codex. Автор ролика добавляет к лестнице сторожа — плагин «You should know».

Первая ступень — правила письма. Автор ролика называет их языком авиамехаников.

Какие правила вы берёте:

1. Возьмите стандарт ASD-STE100. Это упрощённый технический английский.
2. Разрешите примерно 900 слов. У каждого слова одно значение.
3. Пишите предложения до 20 слов в инструкции и до 25 слов в описании.
4. Держите одно действие в одном предложении.
5. Пишите в действительном залоге: «система списала деньги», а не «деньги были списаны».
6. Объясняйте новый термин простыми словами при первом упоминании.
7. Называйте одну вещь одним словом. Объясните термин один раз и дальше не меняйте.
8. Давайте ответ первым. Подробности — после ответа.
9. Давайте шаги нумерованным списком.
10. Добавьте схему, если в процессе больше трёх шагов.

Куда положить правила:

1. Создайте файл CLAUDE.md в папке проекта. Claude Code читает этот файл в начале каждой сессии.
2. Положите тот же блок в общий файл Claude. Тогда правило работает во всех ваших проектах сразу.
3. Для Codex положите правила в файл AGENTS.md.
4. Спросите своего агента, куда вставить блок. Он подскажет место.

Стандарт написан для английского языка. Но его правила работают и на русском. Авторы стандарта пишут: короткие предложения, одна тема в предложении и действительный залог полезны вне авиации.

Автор ролика советует смягчить просьбу: пиши примерно на 80% по этому стандарту. Совсем жёсткие правила ломают живой текст.

Пример второй ступени пропустим, так как текстовые схемы на русском почти всегда получаются корявые.

Во вложении пример третьей ступени объяснения материала из предыдущего поста.

А вот и четвертая ступень повышения понятности объяснений LLM в продолжение пары предыдущих постов.

Радикально 😁

Больше методов управления собой - хороших и разных:

- Конвейер управления собой: курс лекций, описывающий построение алгоритмического конвейера управления своими делами и улучшению различных сфер своей жизни. Уже написан.
- Фабрика моей жизни: курс лекций, описывающий построение алгоритмических конвейеров по управлению всеми сферами жизни и наведение порядка в ней. Частично написан, новые лекции выходят.

Отсюда: https://t.me/essaurgey/352

Как рассказать архитектуру историей: нарративная дуга и три акта

Типичная ситуация:

- Архитектор показывает бизнесу сложную диаграмму и говорит: «Вот решение».
- Бизнес смотрит и спрашивает: «Что это? Опишите так, чтобы мы поняли».
- Архитектор в недоумении: «Это же архитектура».

Разговор рассыпается.

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

Вот да.

Плюс ментальные прививки не так инвазивны.

https://t.me/essaurgey/358

Новое слово

Печалити

В помощь детям при изучении истории: https://t.me/essaurgey/360

Не в бровь, а в глаз, тскть

https://t.me/ailev_blog_discussion/38310

По крайней мере, для работников умственного и софт-скиллового труда.

Тех, кто работает руками, пока касается не сильно.
Поэтому в моём ближнем окружении уже двое людей осваивают профессию сварщика.

Теперь и без пейволла: https://habr.com/ru/articles/1095804/

Поверхностно просмотрел - всё выглядит знакомо.
- Представленное колесо баланса совпадает с моим по 7 позициям из 8.
- Конвейер похож на творческий конвейер, о котором рассказывают в треке личного развития МИМ.

Вот только о предсмертных желаниях я не думал, надо будет подумать.

Вспоминается "Книга жизни и практики умирания":

Уже после смерти моего мастера я подружился с Дуджомом Ринпоче, одним из величайших мастеров медитации, мистики и йоги нашего времени. Однажды он со своей женой ехал на автомобиле по Франции, любуясь по пути живописными видами сельской местности. Они проезжали мимо кладбища, украшенного цветами, со свежеокрашенной оградой. Жена Дуджома Ринноче сказала: "Ринпоче, посмотри, как прибрано и чисто все на Западе. Даже места, где они хоронят трупы, безупречны. На Востоке даже дома, где живут люди, далеко не так чисты".

"А, да, – ответил он, – это правда; это очень цивилизованная страна. У них такие замечательные жилища для мертвых трупов. Но разве ты не заметила, какие замечательные у них жилища и для живых трупов?"

Всякий раз, когда я вспоминаю этот случай, я думаю о том, насколько пустой и тщетной может быть жизнь, когда она основывается на ложной вере в длительность и постоянство. Когда мы так живем, то становимся, как сказал Дуджом Ринпоче, бессознательными, живыми трупами.