🎓 Онбординг: с первого дня до уверенного CC
Структурированный план для нового разработчика в команде: что сделать в первый день, чек-листы на неделю, типичные ошибки и прогресс-трекер навыков.
✅ Чек-лист: День 1
Всё что должен сделать новый разработчик в первый день, чтобы начать продуктивно работать с CC.
📅 Чек-лист: Неделя 1
20 задач на первую неделю. Распределены по дням — но темп можно адаптировать под реальные задачи проекта.
- Изучить Advanced раздел сайта (2 часа)
- Освоить /compact для длинных сессий CC
- Создать свои первые 5 шаблонов промптов
- Разобрать одну существующую фичу проекта через CC
- Первый самостоятельный PR с CC (без ментора)
- Пройти code review через CC перед отправкой
- Изучить наши команды и hooks в .claude/
- Написать первый тест с помощью CC
- Освоить работу с git worktrees
- Попробовать параллельную работу: 2 задачи одновременно
- Настроить компактные ответы CC для рутинных задач
- Изучить MCP инструменты проекта глубже
- Expert раздел сайта: прочитать 2 статьи
- Добавить свои правила в личный CLAUDE.md
- Ретроспектива с ментором: что улучшить в процессе
- Написать первую документацию через CC
- Best Practices раздел: изучить 2–3 эксперта
- Попробовать CC для задачи вне основного стека
- Обновить личный CLAUDE.md по итогам недели
- Поделиться находками с командой
📋 Шаблон CLAUDE.md для новичка
Готовый минимальный CLAUDE.md для нового члена команды. Скопируйте, адаптируйте под себя и проект.
# [Имя] — Рабочая конфигурация Claude Code
# Создан: [дата]
# Проект: [название проекта]
## Мой стек
- Backend: Laravel 11, PHP 8.3
- Frontend: Nuxt 3, Vue 3, TypeScript
- БД: PostgreSQL 16
- Контейнеризация: Docker Compose
- Тесты: Pest v2 (PHP), Vitest (JS)
## Стиль ответов Claude
- Отвечай на русском языке
- Краткость важна — не пиши вступления типа "Конечно, я помогу..."
- Сразу давай рабочий код
- Объясняй "почему" только если я спросил
- При ошибках: сначала объясни причину, потом решение
## Правила нашего проекта (из командного CLAUDE.md)
- Архитектура: Domain-Driven Design (app/Domains/)
- Логика ТОЛЬКО в Service классах, не в Controller
- Tenant isolation обязательна везде
- Все внешние данные проходят валидацию (Form Requests)
- Тесты пишем для каждой новой функции
- PSR-12 код-стиль + наш .php-cs-fixer.php
## Мои личные правила
- При сложных задачах сначала составляй план, потом пиши код
- Показывай diff изменений, не полные файлы целиком
- Указывай какие тесты нужно запустить после изменений
- Предупреждай если задача крупнее чем кажется
## Что нельзя делать (из правил команды)
- Не хардкодить секреты и credentials
- Не менять структуру папок без обсуждения
- Не изменять миграции уже применённые на prod
- Не публиковать порты 80/443 (только Caddy)
- Не трогать .env.production файлы
## Мои частые задачи
- Создать новый Laravel endpoint: [наш стандартный паттерн]
- Создать Vue компонент: Composition API + TypeScript
- Написать Pest тест: Feature тест для API endpoint
- Исправить N+1: добавить eager loading через with()
## Ссылки
- Проектный CLAUDE.md: [путь]
- Обучающий сайт: https://claude.rosveb.ru
- Командные промпты: docs/cc-prompts/
- Наш стек docs: docs/architecture.md
CLAUDE.md — живой документ, а не разовая настройка. Опытные разработчики обновляют его после каждой значимой сессии: добавляют правила которые сработали, убирают устаревшие ограничения, уточняют стек. Хорошей практикой является добавить в конец файла секцию «Что сработало недавно» — она напомнит Claude о паттернах которые оказались удачными в предыдущих сессиях.
🚨 Топ-10 ошибок новичков с CC
📖 Как читать чужой CLAUDE.md
Попали в новый проект и открыли CLAUDE.md команды. Что искать в первую очередь:
📄 Командные соглашения: шаблон rules/ структуры
Tech Lead создаёт структуру командных правил. CC читает эти файлы из CLAUDE.md через импорты.
rules/
├── architecture.md # DDD структура, слои, паттерны
├── security.md # Tenant isolation, secrets, auth
├── coding-style.md # Именование, PSR-12, Prettier
├── database.md # Migrations, индексы, N+1 запреты
├── testing.md # Pest конвенции, coverage требования
├── git.md # Ветки, commits, PR процесс
├── api.md # REST контракты, versioning, errors
└── performance.md # Query limits, кеш, lazy loading
# Проект: [Название]
## Архитектура и правила
@rules/architecture.md
@rules/security.md
@rules/coding-style.md
@rules/database.md
## Тестирование
@rules/testing.md
## Процессы команды
@rules/git.md
@rules/api.md
## Инфраструктура
- OS: Windows Server 2025 + WSL2 + Docker
- Proxy: Caddy (не публикуем 80/443, только proxy-сеть)
- PostgreSQL: shared_buffers=4GB, work_mem=64MB
- Reverse proxy добавление: proxy add domain.ru container:port
## Контекст проекта
[описание продукта и целей]
## Стек
- Backend: Laravel 11 (PHP 8.3 + Octane)
- Frontend: Nuxt 3 (Vue 3 + TypeScript)
- DB: PostgreSQL 16 + Redis 7
- Tests: Pest v2 + Vitest
- CI/CD: GitHub Actions
# Безопасность
## Tenant Isolation (КРИТИЧЕСКИ ВАЖНО)
- ВСЕ запросы к БД ДОЛЖНЫ фильтроваться по tenant_id
- Используй TenantScope global scope или явный ->where('tenant_id', ...)
- Policy классы всегда проверяют tenant владения
- Тест: создай два tenant, убедись что данные изолированы
## Secrets и Credentials
- НИКОГДА не хардкодить секреты в код
- Все чувствительные данные через .env
- .env файлы в .gitignore (кроме .env.example)
- Production secrets в GitHub Secrets или Vault
## Authentication
- API: Laravel Sanctum (не JWT самодельный)
- Token lifetime: 7 дней по умолчанию
- Refresh tokens: реализованы в AuthService
- Проверка прав: Policy классы, не if-else в controller
## Webhooks
- Stripe: обязательно Webhook::constructEvent() верификация
- ЮKassa: проверка IP адресов из официального списка
- Логируй все webhook события в webhook_logs таблицу
📊 Прогресс-трекер навыков CC
Таблица для оценки текущего уровня и понимания что развивать дальше.
| Навык | Базовый | Средний | Эксперт |
|---|---|---|---|
| Написание промптов | Базовый Простые вопросы и задачи | Средний Контекстные промпты с примерами и ограничениями | Эксперт Шаблоны промптов, цепочки, метапромпты |
| CLAUDE.md | Базовый Базовый CLAUDE.md с описанием проекта | Средний Правила, запреты, импорт из rules/ | Эксперт Командный шаблон, обновление по результатам |
| MCP инструменты | Базовый Знает что такое MCP, использует базовые | Средний Настраивает MCP серверы, использует Figma MCP | Эксперт Пишет свои MCP инструменты для команды |
| Управление контекстом | Базовый Знает о длине контекста, использует /compact | Средний Грамотно дозирует контекст, чистит лишнее | Эксперт Context engineering, оптимизация под задачи |
| Git + CC workflow | Базовый Одна ветка + CC для задач | Средний Git worktrees, параллельные задачи | Эксперт Multi-agent, автоматизация через hooks |
| Code review с CC | Базовый Просит CC проверить свой код | Средний CC делает self-review перед PR | Эксперт Автоматическое ревью через hooks + CI |
| Отладка через CC | Базовый Даёт ошибку, CC предлагает решение | Средний Структурированный контекст для CC, быстрый поиск причины | Эксперт CC отлаживает производительность, сложные баги |
| Тестирование через CC | Базовый CC пишет простые unit тесты | Средний TDD с CC, edge cases, тесты безопасности | Эксперт Автоматическая генерация тестов для всего проекта |
| Архитектурные решения | Базовый Следует существующей архитектуре | Средний Обсуждает архитектуру с CC, выбирает паттерны | Эксперт CC как архитектурный советник, проектирует системы |
| Onboarding других | Базовый Сам разобрался, другие — не его задача | Средний Помогает коллегам разобраться с CC | Эксперт Пишет командные CLAUDE.md, создаёт обучение |
🤝 Менторство через CC: старший помогает новичку
Как старший разработчик использует CC для обучения новичков без постоянного присутствия.
- Новичок формулирует задачу — ментор помогает улучшить промпт
- CC генерирует решение — ментор объясняет почему CC так сделал
- Обсуждение альтернатив: "а что если попросить CC иначе?"
- Разбор ошибок CC вместе — учит критическому мышлению
- Ментор описывает задачу в CLAUDE.md временно
- Новичок решает с CC, ментор проверяет результат
- CC знает о задаче и направляет без ментора
- Новичок учится ставить задачи через CLAUDE.md
- Новичок делает PR → CC проводит self-review
- Ментор видит что CC нашёл и что пропустил
- Обсуждение: "CC прав? Почему? Что ещё важно?"
- Постепенно новичок начинает сам находить проблемы
- "Попроси CC объяснить Repository паттерн на примере нашего кода"
- CC объясняет с примерами из реального проекта
- Новичок сразу видит применение, не абстрактный пример
- Ментор уточняет и добавляет нюансы нашего проекта
- Новичок изучил модуль — просит CC помочь задокументировать
- Документация фиксирует понимание и видна менторе
- Ошибки в документации = ошибки в понимании — легко найти
- Формирует привычку документировать всё через CC
- Ментор записывает в CLAUDE.md типичные вопросы новичков
- CC отвечает на эти вопросы даже когда ментора нет
- Новичок работает самостоятельно, ментор проверяет раз в день
- Эффективно: ментор не отвлекается постоянно
Я новый разработчик в команде. Ментор попросил меня разобраться с модулем Billing.
Помоги мне понять:
1. Как работает наш BillingService? Объясни простыми словами
2. Что делает TenantBillingScope и зачем он нужен?
3. Как данные идут от создания подписки до записи в БД?
4. Что может пойти не так в этом модуле?
Покажи примеры на основе реального кода из файла app/Domains/Billing/
После объяснения задай мне 3 вопроса чтобы проверить понимание.