🔥 HARDKODING PRO · CLAUDE CODE · 04/05

Первый настоящий проект: от идеи до Git checkpoint

Проверено 09.10.2026. Команды Claude Code и интерфейс могут обновляться. Перед применением сверяй их с официальной документацией.

Теперь перестаём тренироваться на README. В этом гайде ты проведёшь Claude Code через полный цикл разработки маленького продукта: research, plan, реализация, проверка, simplify и Git.

End-to-endPlan modeTestsDiffGit60–90 минут9 визуальных примеров

Настоящий вайбкодинг начинается не с «напиши приложение», а с правильно управляемого цикла.

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

HARDKODING PRO · CLAUDE CODE · МАРШРУТ 00 → UI → 01 → 02 → 03 → 04 → 05 · Непонятное слово? Смотри Wiki внизу

00Подготовка UIИнтерфейс 01Первый запуск 02Модели и режимы 03Память и Skills 04Первый проект 05Сессии и Remote Control

← 03 · Память и Skills 05 · Сессии и Remote Control →

Результат 04/05: у тебя есть рабочий AI Project Dashboard в чистом HTML/CSS/JS, изменения проверены через diff и manual tests, код упрощён через /simplify и зафиксирован отдельным Git commit.

Экран 1 из 13 · вся практика, 9 схем и 6 промптов сохранены · проверено 09.10.2026

Строим AI Project Dashboard

Маленький продукт, но с реальным состоянием и пользовательским действием.

Что должно работать

список AI-проектов;
у каждого проекта: название, статус и следующий шаг;
добавление нового проекта;
изменение статуса;
сохранение в localStorage;
данные не пропадают после refresh;
empty state для пустого списка;
mobile-first интерфейс.

Почему без framework?
Чтобы ученик видел работу агента, а не три часа лечил npm, build system и зависимости. В этом уроке важен workflow разработки, а не стек.

Idea

→

Research

→

Plan

→

Build

→

Verify

→

Git

Research-first: сначала факты

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

Research-first: сначала изучаем реальные файлы, структуру и ограничения проекта.

Промпт №1: research

Работаем внутри текущего учебного проекта.

Сейчас ничего не меняй.

Задача проекта:
создать простое веб-приложение "AI Project Dashboard" без фреймворков и без внешних зависимостей.

Функции:
- список AI-проектов;
- у каждого проекта: название, статус, следующий шаг;
- кнопка "Добавить проект";
- данные пока можно хранить локально в браузере;
- адаптивный интерфейс для телефона и компьютера.

Сначала проведи research по текущему проекту:
1. Какие файлы уже есть?
2. Какие технологии уже используются?
3. Что можно переиспользовать?
4. Какие новые файлы минимально нужны?
5. Какие риски и неизвестные есть?

Ничего не создавай и не редактируй.
Ответ дай коротким списком с evidence: пути файлов и факты, которые ты реально увидел.

Если копирование не сработало, выдели вручную.

Evidence 1: какие файлы реально существуют.

Evidence 2: какой stack реально используется.

Evidence 3: какие команды реально доступны.

Evidence 4: что Claude не знает и должен уточнить.

Плохой старт: «Сделай мне крутое приложение».
Нормальный старт: «Изучи текущий проект, перечисли факты, потом предложи минимальный путь».

Plan mode: сначала карта изменений

Anthropic рекомендует Plan для изменений, затрагивающих несколько файлов.

Plan mode: сначала согласовываем карту изменений, затем пишем код.

/planread-only планирование до первого изменения

Промпт №2: минимальный план

Теперь перейди в Plan mode и составь минимальный план реализации.

Ограничения:
- не использовать React, Vue, Next.js и другие фреймворки;
- не устанавливать npm-пакеты;
- не использовать внешнюю БД;
- максимум 3 новых файла;
- mobile-first;
- данные храним через localStorage;
- не менять файлы вне этой задачи.

План должен содержать:
1. список файлов, которые будут созданы или изменены;
2. что именно будет в каждом файле;
3. порядок реализации;
4. как проверить результат вручную;
5. какие edge cases проверить;
6. критерий "готово".

Пока ничего не меняй.

Если копирование недоступно, выдели вручную.

Прими план только если понимаешь:

какие файлы будут затронуты;
зачем нужен каждый файл;
как будет храниться состояние;
как ты проверишь работу;
чего Claude НЕ будет делать.

Plan mode — не бюрократия. Это самый дешёвый момент, чтобы сказать: «не трогай этот файл», пока Claude ещё ничего не сломал.

Git branch до изменений

Не превращаем main в песочницу.

Feature branch отделяет эксперимент от основной версии проекта.

Для обычной разработки

Проверь git status.
Если репозиторий ещё не создан — сначала инициализируй Git.
Создай отдельную ветку, например feat/ai-project-dashboard.
Убедись, что работа идёт не в main.

Почему до build?
Потому что branch — это граница эксперимента. Ошибка не должна автоматически становиться новой версией основного проекта.

Реализация: выполняем согласованный план

Plan закончен. Теперь агент может менять файлы.

Build: Claude реализует согласованный AI Project Dashboard по этапам.

Промпт №3: build

План согласован.

Выполни его по шагам.

Правила:
- меняй только файлы из согласованного плана;
- не добавляй зависимости;
- не меняй CLAUDE.md;
- после каждого логического шага коротко пиши, что сделал;
- если встретишь проблему, сначала объясни её, потом предлагай решение;
- после реализации запусти доступные проверки;
- если автоматических тестов нет, сделай чёткий manual test checklist.

Финальный результат должен включать:
1. рабочий AI Project Dashboard;
2. mobile-first layout;
3. добавление проекта;
4. изменение статуса;
5. сохранение данных после перезагрузки;
6. понятный empty state;
7. evidence: какие файлы изменены, что проверено, что не проверено.

Если кнопка не сработала, скопируй вручную.

Нормальная автономность

Claude реализует согласованный plan, запускает проверки и сообщает фактами.

Плохая автономность

Claude сам решает сменить stack, поставить 8 пакетов и переписать половину проекта.

Если Claude меняет направление, не подтверждай автоматически. Спроси: «Почему это необходимо и почему этого не было в согласованном плане?»

Готово только после проверки

Слово «готово» от модели — не evidence.

Проверка результата: работающий продукт, тесты и фактический evidence.

Промпт №4: приёмка

Теперь ничего не меняй.

Сделай приёмку проекта как reviewer.

Проверь:
1. git status;
2. какие файлы изменены;
3. соответствует ли реализация согласованному плану;
4. нет ли лишних файлов и зависимостей;
5. работает ли localStorage;
6. есть ли empty state;
7. есть ли mobile-first поведение;
8. какие проверки реально выполнены;
9. что осталось только предположением.

После этого выполни /diff и объясни изменения простыми словами.
Не исправляй код без отдельного разрешения.

Если копирование не сработало, выдели вручную.

/diffинтерактивный просмотр незакоммиченных изменений

Проверка	Что считается evidence
Файлы	`git status` + diff
Запуск	страница реально открывается
Добавление проекта	новая карточка появляется
Статус	изменение сохраняется
Persistence	refresh не удаляет данные
Mobile	проверено узкое окно / телефон
Ошибки	console без необъяснённых ошибок

Если автоматических тестов нет, manual checklist — это тоже проверка. Главное, чтобы она была выполнена, а не перечислена как намерение.

Review → approval → /simplify

Сначала понимаем, что стоит улучшить. Потом разрешаем автоматические правки.

Review, подтверждение, /simplify и повторная проверка diff. — Review → подтверждение → /simplify → повторный diff: сначала понимаем изменения, потом разрешаем автоматическое упрощение.

/simplifyпроверить recent changes на reuse, качество и эффективность

Промпт №5: review перед /simplify

Сейчас ничего не меняй.

Проведи review недавно изменённых файлов.

Найди:
- дублирование;
- лишнюю сложность;
- слабое переиспользование;
- проблемы читаемости;
- места, где упрощение может случайно изменить функциональность.

Верни короткий список рекомендаций:
1. что именно стоит упростить;
2. зачем;
3. какой риск у изменения;
4. какие файлы будут затронуты.

Ничего не исправляй. После отчёта жди моего решения.

Если копирование недоступно, выдели вручную.

После твоего подтверждения: запускай /simplify. Этот bundled skill может сам применять улучшения к recent changes, поэтому сначала review, потом approval, затем /simplify и повторный diff.

Не упрощай раньше времени. Если продукт ещё не работает, «рефакторинг красоты» может просто замаскировать отсутствие результата. После /simplify обязательно снова посмотри diff и повтори ключевые проверки.

/rewind: не всегда надо чинить вперёд

Claude Code автоматически создаёт checkpoints во время работы.

/rewind и checkpoints помогают вернуться к стабильной точке внутри сессии.

/rewindвернуться к более раннему checkpoint разговора / кода

Esc, Escоткрыть rewind/checkpoint menu

Когда использовать

Claude пошёл не в ту архитектуру;
после нескольких шагов стало хуже;
ты хочешь сравнить две реализации;
дешевле откатиться, чем чинить последствия.

Важно: checkpointing не заменяет Git. Rewind помогает внутри сессии, Git остаётся source of truth для версии проекта.

Важно: /rewind и Git решают разные задачи.

/rewind помогает вернуться к контрольной точке внутри сессии Claude Code; для устойчивой истории проекта используй Git-коммит и, при необходимости, отдельную ветку. Не рассчитывай, что откат в Claude автоматически спасёт изменения из других инструментов или внешних систем. /simplify может изменять файлы — проверь diff и тесты после его запуска.

Git checkpoint: фиксируем проверенный результат

Commit делается после evidence, не вместо evidence.

Git checkpoint: проверенный результат фиксируется понятным commit и SHA.

Промпт №6: безопасный commit

Подготовь проект к локальному Git checkpoint.

Ничего не пушь и не создавай PR без отдельной команды.

1. Покажи git status.
2. Покажи список изменённых файлов.
3. Убедись, что нет .env, секретов, временных файлов и мусора.
4. Предложи commit message в формате:
   feat: add AI project dashboard
5. После моего подтверждения создай commit.
6. После commit покажи:
   - commit SHA;
   - чистый ли git status;
   - какие проверки были выполнены до commit.

Если кнопка не сработала, выдели вручную.

Что должно остаться в конце:
ветка feat/ai-project-dashboard
рабочий продукт
чистый diff без мусора
пройденные проверки
один понятный commit
commit SHA как evidence

В этом Level 0 мы останавливаемся на локальном checkpoint. Push → PR → CI → merge — отдельный production workflow, который используется, когда проект реально идёт дальше.

★

Бизнес-кейс: локальный дашборд продаж

Альтернативный проект с той же дисциплиной Research → Plan → Build → Test → Review → Git.

Здесь новое действие: сделай его, проверь результат и только потом переходи дальше.

Основной AI Project Dashboard сохраняется без изменений. Этот дополнительный маршрут полезен предпринимателю: он создаёт приложение для учебных данных без настоящего кабинета WB/Ozon.

Шаг 1. Возьми исходные данные

Скачай demo_marketplace_sales.csv из урока 03. Создай отдельную ветку, не меняй исходный файл.

Шаг 2. Plan, без изменений

Спроектируй локальный HTML-дашборд для учебного CSV: загрузка файла, фильтр по SKU, таблица продаж и рекламных затрат, график, отображение формул. Не подключай API или сеть. Сначала дай структуру файлов, ограничения, план и тест-кейсы. Ничего не меняй до моего подтверждения.

Шаг 3. Реализация и проверка

После моего одобрения реализуй план. Обработай пустой CSV, ошибочные числа и пропущенные поля. Проверь результат на учебном CSV: 64 900 ₽ после возвратов, 11 300 ₽ рекламы. Покажи diff, проведи тесты и подготовь Git checkpoint. Без commit и deploy до моего согласия.

Проверка готовности

✅ Локальный HTML открывается. ✅ При смене SKU числа и график пересчитываются. ✅ Ошибочный CSV даёт понятное сообщение. ✅ Итоги сходятся. ✅ Нет сетевых вызовов, чужих данных, токенов. ✅ Diff и Git checkpoint подтверждены.

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

🧠 Wiki этого урока

Короткая расшифровка терминов человеческим языком.

Research-first: Сначала изучить фактическое состояние проекта, потом менять.
Plan mode: Read-only этап планирования.
Git: Система контроля версий.
Branch: Отдельная ветка Git.
Commit: Зафиксированная точка истории Git.
SHA: Уникальный идентификатор Git commit.
localStorage: Локальное хранилище браузера.
Framework: Готовая программная основа вроде React/Vue/Next.js.
Dependency: Внешний пакет или библиотека.
Regression: Поломка ранее работавшего после изменений.
Diff: Сравнение изменений в файлах.
Evidence: Проверяемое доказательство готовности.

FAQ

Почему не попросить Claude сразу сделать всё?

Потому что ошибка в плане дешевле ошибки в коде. Research и Plan позволяют поправить направление до изменения файлов.

Почему feature branch, если проект учебный?

Потому что мы тренируем правильный workflow. Привычка работать прямо в main потом дорого обходится на реальном проекте.

Нужно ли обязательно иметь automated tests?

Нет. Но должно быть evidence. Если проект простой и тестов нет, выполни конкретный manual checklist и зафиксируй, что именно проверено.

/rewind заменяет git checkout?

Нет. Rewind — checkpoint внутри Claude Code. Git — история и source of truth проекта.

Claude может сам сделать commit?

Да, если ты разрешишь. Но перед commit сначала проверь status, diff, tests и отсутствие секретов/мусора.

Источники и дата проверки · 09.10.2026

Сведения о командах и режимах проверены на дату публикации; возможности и меню Claude Code могут меняться.

HARDKODING PRO · CLAUDE CODE · МАРШРУТ 00 → 05 · Непонятное слово? Смотри Wiki внизу

00Подготовка 01Первый запуск UIИнтерфейс 02Модели и режимы 03Память и Skills 04Первый проект 05Сессии и Remote Control

← 03 · Память и Skills 05 · Сессии и Remote Control →

Первый настоящий проект: от идеи до Git checkpoint

Строим AI Project Dashboard

Что должно работать

Research-first: сначала факты

Промпт №1: research

Plan mode: сначала карта изменений

Промпт №2: минимальный план

Прими план только если понимаешь:

Git branch до изменений

Для обычной разработки

Реализация: выполняем согласованный план

Промпт №3: build

Нормальная автономность

Плохая автономность

Готово только после проверки

Промпт №4: приёмка

Review → approval → /simplify

Промпт №5: review перед /simplify

/rewind: не всегда надо чинить вперёд

Когда использовать

Git checkpoint: фиксируем проверенный результат

Промпт №6: безопасный commit

Бизнес-кейс: локальный дашборд продаж

Шаг 1. Возьми исходные данные

Шаг 2. Plan, без изменений

Шаг 3. Реализация и проверка

Checkpoint 04/05

🧠 Wiki этого урока

FAQ