dzHarness × Codex

30 минут · 1 идея · 1 live demo

Не промпт.
Система.

Как за несколько команд превратить Codex из «умного собеседника» в воспроизводимого проектного агента с помощью dz harness-cli.

Жечков Дмитрий · t.me/llm_notes

Codexskillsquality gatesself-contained demo

Маршрут · 1–3–1

Одна проблема.
Три слоя. Один показ.

Почему сильной модели недостаточно
Что добавляет harness и где здесь dz
Live: собираем проектный арсенал для Codex
Как перенести подход в свой проект

Проблема

Модель умеет.
Проект не помнит.

Prompt-only

  • правила живут в голове оператора
  • контекст собирается заново
  • «готово» означает уверенность модели
≠

Harness-first

  • правила лежат рядом с кодом
  • навыки подключаются воспроизводимо
  • «готово» привязано к проверке
Тезис: качество работы агента — свойство не только модели, но и среды вокруг неё.

Ментальная модель

dz = package manager
+ cross-compiler

Намерение«что должен уметь агент?»
Skillканонические инструкции и ресурсы
dzвыбор, сборка, проверка
Targetформат конкретного harness
Codex.agents/skills/

Описываем способность один раз — доставляем в формат нужной платформы.

Полка · доказательство, не каталог

Одна кузница.
Разный материал.

Тону в лентах

news

Дайджест со ссылками и памятью прошлых выпусков.

Прочитал — не применяю

book-digitizer

Книга превращается в навыки для решений агента.

Есть сырая идея

design-thinking

Потребности отделяются от красивых догадок.

Пакет непонятен людям

package-story-page

Код и README становятся короткой проверяемой историей.

Не показываем весь каталог. Берём один инструмент и вскрываем его до винтиков.

Target: Codex

Инструкции становятся
частью проекта

На диске
project/
├── AGENTS.md
├── .agents/
│   └── skills/
│       ├── design-taste-frontend/
│       │   └── SKILL.md
│       ├── package-story-page/
│       │   └── SKILL.md
│       └── presentation-storyteller/
│           └── SKILL.md
└── src/

Что меняется

  • skill можно ревьюить как код
  • состав арсенала виден на диске
  • следующая сессия получает те же правила

Главная идея

Где живёт правило —
там его судьба

Чатзабылось после ответа
Памятьможет не попасть в контекст
Skillсработает при верном маршруте
Pipelineшаг нельзя тихо пропустить
Gate / CIнарушение останавливает работу
Не «модель поумнее», а обязательный checklist. Следующий показ проверит именно пожарную сигнализацию.

Live demo · цель

За 8 минут: от пакета
к понятной story-page

package-story-page

Извлекает честную историю продукта из README, package.json и кода.

design-taste-frontend

Убирает шаблонный «AI look» и задаёт осознанный визуальный характер.

presentation-storyteller

Держит повествовательную дугу, источники и речь спикера.

Контракт показа: Codex создаёт автономный HTML и исполняемый gate — затем мы докажем, что gate умеет краснеть.

Live demo · шаг 1/3

Изолируем показ.
Ставим skills.

Терминал · выполнить до запуска Codex
# Из корня dz-harness; основное дерево останется нетронутым
git worktree add ../dz-talk-demo HEAD
cd ../dz-talk-demo

# Установка skills без изменения пользовательских hooks
dz init --target codex \
  --select design-taste-frontend,package-story-page,presentation-storyteller \
  --project . --no-hooks --no-verify

dz list --skills-dir .agents/skills
codex
Говорим вслух: worktree — страховка показа; --no-hooks не меняет глобальную конфигурацию зрителя.

Live demo · шаг 2/3

Просим результат.
И доказательство.

Вставить в Codex
Изучи packages/@dzhechkov/harness-cli/package.json и README.md.
Используй установленные skills package-story-page,
design-taste-frontend и presentation-storyteller.

Создай два файла: out/live-demo/index.html — автономную
русскоязычную story-page о dz для нового разработчика —
и out/live-demo/verify.mjs — детерминированную проверку.
Ограничения страницы: без CDN и сборки, 5 экранов,
клавиатурная навигация, видимый CTA с точной командой для Codex.
Проверка обязана именованно проверять эти ограничения и выходить
с кодом 1, если найден внешний script src или stylesheet href.

До редактирования назови 4 критерия готовности.
После редактирования запусти проверку HTML и сообщи:
1) какие файлы созданы; 2) какую команду запускал;
3) её exit code; 4) что осталось непроверенным.

Не диктуем макет. Фиксируем аудиторию, артефакт, ограничения и evidence contract.

Live demo · шаг 3/3

Финал — это
квитанция

Проверяем проверку: green → red → green
# 1. Штатная страница — GREEN
node out/live-demo/verify.mjs

# 2. Пускаем «дым»: внешний script — нужен RED
cp out/live-demo/index.html /tmp/dz-live-demo-index.html
sed -i 's#</body>#<script src="https://example.com/demo.js"></script></body>#' out/live-demo/index.html
node out/live-demo/verify.mjs

# 3. Возвращаем байты — снова GREEN
cp /tmp/dz-live-demo-index.html out/live-demo/index.html
node out/live-demo/verify.mjs
git status --short

Смотрим не на красноречие

01файл реально существует 02gate зелёный на норме 03gate красный на нарушении 04после восстановления снова зелёный
Зелёная проверка ничего не стоит, пока вы не видели её красной.

После демо

Skill отвечает «как».
Harness удерживает цикл.

Discoverregistry search
Installinit / setup
UseCodex применяет skill
Verifyguard / doctor
Learnteach / recall

Для существующего проекта

Сначала dz architecture и минимальный набор skills. Не устанавливайте весь каталог «на всякий случай».

Для повторяемой работы

Правило усиливают: рекомендация → skill → детерминированный gate → CI.

Забрать с собой

Три правила на завтра

1

Храните способность

Не переобъясняйте процесс в каждом промпте — оформляйте повторяемое решение как skill.

2

Ставьте минимум

Выбирайте skills под текущую задачу и компилируйте под реальный target.

3

Требуйте квитанцию

Слово «готово» начинается после воспроизводимой команды проверки.

Финиш · 29:00

Вопросы?

Автор: Жечков Дмитрий Telegram · llm_notes ↗ Живой harness-backlog ↗ Все обучалки по пакетам ↗ Архитектура harness-hub ↗