Подробный разбор основных Commands: полное руководство по 15 слэш-командам

Что вы сможете делать после изучения

Быстро запускать TDD-процесс разработки для создания качественного кода
Создавать систематизированные планы реализации, избегая пропуска ключевых шагов
Проводить комплексный код-ревью и аудит безопасности
Генерировать end-to-end тесты для проверки критических пользовательских сценариев
Автоматически исправлять ошибки сборки, экономя время на отладку
Безопасно удалять мёртвый код, поддерживая кодовую базу в чистоте
Извлекать и переиспользовать паттерны решённых проблем
Управлять состоянием работы и контрольными точками
Проводить комплексную верификацию для готовности кода

Ваши текущие проблемы

В процессе разработки вы можете столкнуться с такими проблемами:

Не знаете, с чего начать — как декомпозировать шаги реализации при новых требованиях?
Низкое покрытие тестами — много кода написано, но тестов недостаточно, качество под вопросом
Накопление ошибок сборки — после изменения кода ошибки типов появляются одна за другой, непонятно, с чего начать исправление
Несистемный код-ревью — при визуальной проверке легко пропустить проблемы безопасности
Повторное решение одних и тех же проблем — наступаете на те же грабли снова и снова

15 слэш-команд Everything Claude Code созданы именно для решения этих проблем.

Основная концепция

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

Команда vs Агент vs Навык

Команда: быстрый вход, который вы вводите непосредственно в Claude Code (например, /tdd, /plan)
Агент: специализированный субагент, вызываемый командой для конкретного выполнения
Навык (Skill): определения рабочих процессов и доменные знания, на которые может ссылаться агент

Одна команда обычно вызывает одного или нескольких агентов, агенты могут ссылаться на связанные навыки.

Обзор команд

15 команд по категориям:

Категория	Команда	Назначение
Процесс разработки	`/plan`	Создание плана реализации
	`/tdd`	Выполнение разработки через тестирование
	`/orchestrate`	Последовательное выполнение нескольких агентов
Качество кода	`/code-review`	Код-ревью
	`/build-fix`	Исправление ошибок сборки
	`/refactor-clean`	Очистка мёртвого кода
	`/verify`	Комплексная верификация
Тестирование	`/e2e`	End-to-end тестирование
	`/test-coverage`	Анализ покрытия тестами
	`/eval`	Управление eval-driven разработкой
Документация и архитектура	`/update-docs`	Синхронизация документации
	`/update-codemaps`	Обновление архитектурной документации
Управление состоянием	`/checkpoint`	Сохранение состояния работы
Обучение и оптимизация	`/learn`	Извлечение переиспользуемых паттернов
Конфигурация	`/setup-pm`	Настройка пакетного менеджера

Команды процесса разработки

/plan: Планирование сложных функций

Назначение: Создание детального плана реализации перед началом кодирования.

Сценарии применения:

Начало разработки новой функции
Проведение значительных архитектурных изменений
Когда требования неясны или размыты
Координированное изменение нескольких файлов/компонентов

Рабочий процесс:

1. Переформулировка требований
   ↓
2. Выявление рисков и зависимостей
   ↓
3. Декомпозиция на конкретные этапы
   ↓
4. Ожидание вашего подтверждения

Ключевая особенность

Агент planner не пишет никакого кода, пока вы явно не подтвердите план.

Пример:

Вы: /plan Мне нужно добавить функцию уведомлений в реальном времени

Claude:
# Implementation Plan: Real-Time Market Resolution Notifications

## Requirements Restatement
- Send notifications when markets resolve
- Support multiple channels (in-app, email, webhook)
- Ensure reliable delivery
- Include market outcome and user's position result

## Implementation Phases
### Phase 1: Database Schema
- Add notifications table
- Add user_notification_preferences table
- Create indexes

### Phase 2: Notification Service
- Create notification queue using BullMQ/Redis
- Implement retry logic
- Create notification templates

...

WAITING FOR CONFIRMATION: Proceed with this plan? (yes/no/modify)

Лучшие практики:

✅ Сначала планируйте сложные функции, затем реализуйте
✅ Внимательно проверяйте риски и зависимости
✅ Выполняйте поэтапно, верифицируя каждый этап
❌ Не пропускайте этап планирования

/tdd: Разработка через тестирование

Назначение: Принудительное выполнение TDD-процесса с обеспечением покрытия тестами ≥ 80%.

Сценарии применения:

Реализация новых функций
Исправление багов (сначала пишем тест, воспроизводящий баг)
Рефакторинг существующего кода
Написание ключевой бизнес-логики

Цикл TDD:

RED → GREEN → REFACTOR → REPEAT

RED:      Написать падающий тест
GREEN:    Написать минимум кода для прохождения теста
REFACTOR: Улучшить код, сохраняя прохождение тестов
REPEAT:   Следующая функция/сценарий

Обязательное требование

Сначала тест, потом код. Нельзя пропускать фазу RED.

Пример:

Вы: /tdd Мне нужна функция расчёта показателя ликвидности рынка

Claude (tdd-guide agent):
## Step 1: Define Interface (SCAFFOLD)
```typescript
export interface MarketData {
  totalVolume: number
  bidAskSpread: number
  activeTraders: number
  lastTradeTime: Date
}

Step 2: Write Failing Test (RED)

typescript

test('should return high score for liquid market', () => {
  const market = { ... }
  expect(calculateLiquidityScore(market)).toBeGreaterThan(80)
})

Step 3: Run Tests - Verify FAIL

bash

npm test lib/liquidity.test.ts
FAIL ✕ should return high score for liquid market
  Error: Not implemented

Step 4: Implement Minimal Code (GREEN)

typescript

export function calculateLiquidityScore(market: MarketData): number {
  // Код реализации...
}

Step 5: Run Tests - Verify PASS

bash

npm test lib/liquidity.test.ts
PASS ✓ should return high score for liquid market

Step 6: Refactor (IMPROVE)

// Улучшение структуры кода...

Step 7: Verify Tests Still Pass

bash

npm test lib/liquidity.test.ts
PASS ✓ all tests passing

Step 8: Check Coverage

Coverage: 100% ✅ (Target: 80%)


**Лучшие практики**:
- ✅ Сначала определяйте интерфейс
- ✅ Реализуйте только после падения теста
- ✅ Тестируйте сразу после написания каждой функции
- ✅ Верифицируйте прохождение тестов до и после рефакторинга
- ✅ Покрытие ≥ 80% (критический код 100%)
- ❌ Не пишите много кода перед тестированием
- ❌ Не пропускайте фазу RED
- ❌ Не тестируйте детали реализации

---

### /orchestrate: Последовательное выполнение агентов

**Назначение**: Автоматизация выполнения последовательных рабочих процессов с несколькими агентами.

**Сценарии применения**:
- Полная разработка функции (planner → tdd-guide → code-reviewer → security-reviewer)
- Процесс исправления багов (explorer → tdd-guide → code-reviewer)
- Аудит безопасности (security-reviewer → code-reviewer → architect)

**Типы рабочих процессов**:

| Тип процесса | Последовательность агентов |
| --- | --- |
| `feature` | planner → tdd-guide → code-reviewer → security-reviewer |
| `bugfix` | explorer → tdd-guide → code-reviewer |
| `refactor` | architect → code-reviewer → tdd-guide |
| `security` | security-reviewer → code-reviewer → architect |

**Пример**:

Вы: /orchestrate feature "Добавить функцию аутентификации пользователей"

Claude:

ORCHESTRATION REPORT

Workflow: feature Task: Добавить функцию аутентификации пользователей Agents: planner → tdd-guide → code-reviewer → security-reviewer

SUMMARY

Успешно реализована функция аутентификации пользователей, включая регистрацию, вход и управление сессиями.

AGENT OUTPUTS

Planner: Создан план реализации из 4 этапов TDD Guide: Реализован сервис аутентификации, покрытие 95% Code Reviewer: Найдено 3 проблемы высокого приоритета, исправлены Security Reviewer: Аудит безопасности пройден, уязвимостей нет

FILES CHANGED

src/services/auth.ts
src/api/auth/route.ts
tests/auth.test.ts
...

TEST RESULTS

PASS: 24/24 tests (100%)

SECURITY STATUS

✅ No vulnerabilities found

RECOMMENDATION

✅ SHIP - Ready for production


**Лучшие практики**:
- ✅ Используйте orchestrate для сложных функций
- ✅ Обеспечьте чёткую документацию передачи между агентами
- ✅ Выполняйте независимые проверки параллельно (code-reviewer и security-reviewer)
- ❌ Не используйте orchestrate для простых задач

---

## Команды качества кода

### /code-review: Код-ревью

**Назначение**: Комплексная проверка незакоммиченного кода на проблемы безопасности и качества.

**Сценарии применения**:
- Перед коммитом кода
- Перед мержем PR
- После завершения разработки функции

**Проверяемые элементы**:

| Категория | Что проверяется | Серьёзность |
| --- | --- | --- |
| **Безопасность** | Захардкоженные ключи, SQL-инъекции, XSS, отсутствие валидации ввода | CRITICAL |
| **Качество кода** | Функции > 50 строк, файлы > 800 строк, глубина вложенности > 4 | HIGH |
| **Лучшие практики** | Паттерны мутации, console.log, отсутствие тестов, TODO/FIXME | MEDIUM |

**Пример**:

Вы: /code-review

Claude (code-reviewer agent):

Code Review Report

Security Issues (CRITICAL)

🔴 [HIGH] Hardcoded API key File: src/api/github.ts:15 Issue: GitHub token is hardcoded Fix: Move to environment variable

Code Quality (HIGH)

🟡 [MEDIUM] Function exceeds 50 lines File: src/utils/formatter.ts:62 Lines: 78 Issue: FormatLargeData function is too long Fix: Split into smaller functions

Best Practices (MEDIUM)

🟢 [LOW] TODO comment File: src/services/user.ts:45 Issue: TODO: Add rate limiting Fix: Implement or remove comment

SUMMARY

CRITICAL: 1 (Must fix before commit) HIGH: 2 (Should fix) MEDIUM: 3 (Nice to have)

❌ BLOCKED - Critical security issues found


::: danger Правило блокировки коммита

При обнаружении проблем уровня **CRITICAL** или **HIGH** коммит блокируется.

:::

---

### /build-fix: Исправление ошибок сборки

**Назначение**: Последовательное исправление ошибок TypeScript и сборки.

**Сценарии применения**:
- Сбой `npm run build`
- Ошибки типов TypeScript
- Ошибки компиляции

**Рабочий процесс**:

Запуск сборки ↓
Парсинг вывода ошибок, сортировка по серьёзности ↓
Последовательное исправление:
- Показ контекста ошибки
- Объяснение проблемы
- Предложение решения
- Применение исправления
- Повторный запуск сборки ↓
Генерация сводки исправлений


**Пример**:

Вы: /build-fix

Claude (build-error-resolver agent):

Fixing Build Errors

Running build: npm run build Found 5 errors

Error 1: Type 'string' is not assignable to type 'number'

File: src/calculator.ts:15

typescript

const result = add("10", "20")  // Error

Issue: add function expects numbers, received strings Fix: Convert to numbers

typescript

const result = add(Number("10"), Number("20"))

✅ Fixed. Re-running build...

Error 2: Cannot find module './utils'

File: src/index.ts:3 Issue: Import path is incorrect Fix: Change to './utils/helper'

typescript

import { helper } from './utils/helper'

✅ Fixed. Re-running build...

...

SUMMARY

Errors Fixed: 5 Errors Remaining: 0 Build Status: ✅ PASS


::: tip Безопасность прежде всего

Исправляйте по одной ошибке за раз, чтобы не внести новые проблемы.

:::

---

### /refactor-clean: Очистка мёртвого кода

**Назначение**: Безопасное выявление и удаление неиспользуемого кода.

**Сценарии применения**:
- В кодовой базе много неиспользуемых файлов и экспортов
- Снижение нагрузки на поддержку
- Повышение читаемости кода

**Рабочий процесс**:

Запуск инструментов анализа мёртвого кода
- knip: поиск неиспользуемых экспортов и файлов
- depcheck: поиск неиспользуемых зависимостей
- ts-prune: поиск неиспользуемых TypeScript экспортов ↓
Генерация комплексного отчёта ↓
Классификация по серьёзности
- SAFE: тестовые файлы, неиспользуемые утилиты
- CAUTION: API-роуты, компоненты
- DANGER: конфигурационные файлы, точки входа ↓
Последовательное удаление (сначала тесты) ↓
Генерация сводки очистки


**Пример**:

Вы: /refactor-clean

Claude (refactor-cleaner agent):

Dead Code Analysis

Tools Run

✅ knip: Found 12 unused exports
✅ depcheck: Found 5 unused dependencies
✅ ts-prune: Found 8 unused TypeScript exports

Classification

SAFE (Can delete)

src/utils/old-helper.ts - Unused utility function
src/components/Button.tsx - Not used anywhere
lodash - Unused dependency

CAUTION (Review first)

src/api/users.ts - Only used in tests
@types/node - May be used in build scripts

DANGER (Do not delete)

src/index.ts - Main entry point
tsconfig.json - Configuration file

Deletion Plan

Run full test suite first: ✅ Tests passing (98% coverage)

Deleting SAFE items...

Removing src/utils/old-helper.ts ✅ Tests still passing
Removing src/components/Button.tsx ✅ Tests still passing
Removing lodash from package.json ✅ Tests still passing

SUMMARY

Files deleted: 12 Dependencies removed: 5 Tests still passing: ✅


::: warning Сначала тесты

**Перед удалением кода обязательно запустите тесты**, чтобы убедиться, что существующая функциональность не нарушена.

:::

---

### /verify: Комплексная верификация

**Назначение**: Запуск полной проверки кода.

**Сценарии применения**:
- Перед коммитом кода
- Перед мержем PR
- При подготовке к релизу

**Проверяемые элементы** (по порядку):

1. **Проверка сборки** - запуск команды сборки
2. **Проверка типов** - запуск TypeScript checker
3. **Проверка Lint** - запуск linter
4. **Тестовый набор** - запуск всех тестов, отчёт о покрытии
5. **Аудит Console.log** - поиск console.log в исходных файлах
6. **Статус Git** - показ незакоммиченных изменений

**Пример**:

Вы: /verify pre-pr

Claude:

Verification Report

VERIFICATION: ✅ PASS

Build: ✅ OK Types: ✅ OK (0 errors) Lint: ✅ OK (0 issues) Tests: ✅ 142/145 passed, 98% coverage Secrets: ✅ OK (0 found) Logs: ⚠️ 3 console.logs found

Console.log locations:

src/utils/logger.ts:15 (intentional logger)
src/api/webhook.ts:42 (debug, remove before commit)
src/services/auth.ts:89 (debug, remove before commit)

Ready for PR: ⚠️ YES (remove debug logs)

Files modified since last commit:

src/api/webhook.ts (new)
src/services/auth.ts (modified)
tests/auth.test.ts (modified)


**Параметры**:
- `quick` - только сборка + проверка типов
- `full` - все проверки (по умолчанию)
- `pre-commit` - проверки, связанные с коммитом
- `pre-pr` - полная проверка + сканирование безопасности

---

## Команды тестирования

### /e2e: End-to-end тестирование

**Назначение**: Генерация и запуск end-to-end тестов с использованием Playwright.

**Сценарии применения**:
- Тестирование критических пользовательских сценариев (вход, транзакции, оплата)
- Верификация end-to-end интеграции многошаговых процессов
- Тестирование UI-взаимодействий и навигации
- Подготовка к production-деплою

**Рабочий процесс**:

Анализ пользовательского сценария, выявление тестовых случаев ↓
Генерация Playwright-тестов (с использованием Page Object паттерна) ↓
Запуск тестов в нескольких браузерах (Chrome, Firefox, Safari) ↓
Захват скриншотов, видео, трейсов при сбоях ↓
Генерация отчёта с результатами и артефактами ↓
Выявление нестабильных тестов и предложение исправлений


**Пример**:

Вы: /e2e Протестировать процесс поиска и просмотра рынка

Claude (e2e-runner agent):

E2E Test Generation: Market Search and View Flow

Test Scenario Identified

User Journey: Market Search → View Results → Click Market → View Details

Generated Test Code

typescript

import { test, expect } from '@playwright/test'
import { MarketsPage } from '../../pages/MarketsPage'

test('user can search markets and view details', async ({ page }) => {
  const marketsPage = new MarketsPage(page)
  await marketsPage.goto()

  // Perform search
  await marketsPage.searchMarkets('election')
  await page.waitForResponse(resp =>
    resp.url().includes('/api/markets/search') && resp.status() === 200
  )

  // Verify results
  const marketCards = marketsPage.marketCards
  await expect(marketCards.first()).toBeVisible()

  // Click on first result
  await marketCards.first().click()

  // Verify market details page loads
  await expect(page).toHaveURL(/\/markets\/[a-z0-9-]+/)
  await expect(page.locator('[data-testid="market-name"]')).toBeVisible()
})

Running Tests

bash

npx playwright test tests/e2e/markets/search-and-view.spec.ts

✓ [chromium] user can search markets and view details (4.2s)
✓ [chromium] search with no results shows empty state (1.8s)

2 passed (6.0s)

Artifacts generated:
- artifacts/search-results.png
- artifacts/market-details.png
- playwright-report/index.html

Test Report

╔══════════════════════════════════════════════════════╗ ║ Status: ✅ ALL TESTS PASSED ║ ║ Total: 2 tests ║ ║ Passed: 2 (100%) ║ ║ Flaky: 0 ║ ╚══════════════════════════════════════════════════════╝


**Быстрые команды**:

```bash
# Запуск всех E2E тестов
npx playwright test

# Запуск конкретного тестового файла
npx playwright test tests/e2e/markets/search.spec.ts

# Запуск в headed режиме (видно браузер)
npx playwright test --headed

# Отладка тестов
npx playwright test --debug

# Просмотр отчёта
npx playwright show-report

Лучшие практики:

✅ Используйте Page Object Model для улучшения поддерживаемости
✅ Используйте атрибуты data-testid в качестве селекторов
✅ Ожидайте ответы API, а не произвольные таймауты
✅ Тестируйте критические пользовательские сценарии
❌ Не используйте хрупкие селекторы (CSS-классы меняются)
❌ Не тестируйте детали реализации

/test-coverage: Анализ покрытия тестами

Назначение: Анализ покрытия тестами и генерация недостающих тестов.

Сценарии применения:

Покрытие ниже 80%
Необходимо дополнить тесты

Рабочий процесс:

1. Запуск тестов с покрытием
   ↓
2. Анализ отчёта о покрытии (coverage/coverage-summary.json)
   ↓
3. Выявление файлов с покрытием ниже порога 80%
   ↓
4. Для каждого файла с недостаточным покрытием:
   - Анализ непротестированных путей кода
   - Генерация unit-тестов для функций
   - Генерация интеграционных тестов для API
   ↓
5. Верификация прохождения новых тестов
   ↓
6. Отображение метрик покрытия до и после

Пример:

Вы: /test-coverage

Claude:
# Test Coverage Analysis

Running tests with coverage...
npm test --coverage

## Coverage Report

File                      | % Stmts | % Branch | % Funcs | % Lines
--------------------------|---------|----------|---------|--------
src/services/auth.ts       |   92    |   88     |   100   |   91
src/utils/formatter.ts     |   65    |   50     |   75    |   63  ⚠️
src/api/users.ts          |   100   |   100    |   100   |   100
src/components/Button.tsx  |   45    |   30     |   50    |   44  ⚠️

Overall                   |   78    |   72     |   85    |   76  ⚠️

Target: 80%
Current: 76% ❌ Need to improve

## Generating Missing Tests

### File: src/utils/formatter.ts (65% coverage)
Untested paths:
- FormatCurrency with negative values
- FormatDate with custom locale
- TruncateText with long strings

Generating tests...
```typescript
describe('formatter', () => {
  it('should format negative currency', () => {
    expect(formatCurrency(-100)).toBe('-$100.00')
  })

  it('should format date with custom locale', () => {
    expect(formatDate(new Date(), 'ja-JP')).toMatch('2024年')
  })

  it('should truncate long text', () => {
    expect(truncateText('a'.repeat(100), 10)).toBe('aaaaaaaaaa...')
  })
})

File: src/components/Button.tsx (45% coverage)

Untested paths:

Disabled state
Loading state
onClick handler

Generating tests...

After Adding Tests

Running tests again...

File	% Stmts	% Branch	% Funcs	% Lines
src/services/auth.ts	92	88	100	91
src/utils/formatter.ts	100	95	100	99 ✅
src/api/users.ts	100	100	100	100
src/components/Button.tsx	95	90	100	94 ✅

Overall | 95 | 92 | 100 | 94 ✅

Target: 80% Current: 94% ✅ EXCEEDED

Summary: +12 tests added, Coverage: 76% → 94%


---

### /eval: Разработка на основе оценок

**Назначение**: Управление рабочим процессом eval-driven разработки.

**Сценарии применения**:
- Разработка на основе оценок (EDD)
- Приёмочное тестирование функций
- Регрессионное тестирование

**Подкоманды**:

- `define <name>` - создание нового определения eval
- `check <name>` - запуск и проверка evals
- `report <name>` - генерация полного отчёта
- `list` - отображение всех evals

**Пример - Определение Eval**:

Вы: /eval define user-auth

Claude: Создание определения eval...

.claude/evals/user-auth.md:

EVAL: user-auth

Created: 2026-01-25

Capability Evals

[ ] User can register with email and password
[ ] User can login with correct credentials
[ ] User cannot login with wrong password
[ ] User can reset password via email

Regression Evals

[ ] Existing users can still login
[ ] Session tokens still work
[ ] OAuth login still works

Success Criteria

pass@3 > 90% for capability evals
pass^3 = 100% for regression evals

Пожалуйста, заполните конкретные критерии оценки...


**Пример - Проверка Eval**:

Вы: /eval check user-auth

Claude: Запуск evals...

EVAL CHECK: user-auth

Capability: 2/4 passing Regression: 2/3 passing Status: IN PROGRESS

Capability Results: ✅ User can register with email and password ✅ User can login with correct credentials ❌ User cannot login with wrong password (fails intermittently) ❌ User can reset password via email (not implemented)

Regression Results: ✅ Existing users can still login ✅ Session tokens still work ❌ OAuth login still works (test failing due to rate limit)

RECOMMENDATION: NEEDS WORK - Fix password validation and implement password reset


**Пример - Отчёт Eval**:

Вы: /eval report user-auth

Claude: Генерация комплексного отчёта...

EVAL REPORT: user-auth

Generated: 2026-01-25

CAPABILITY EVALS

[login-credentials-pass]: PASS (pass@2) - required retry [login-wrong-pass-fail]: FAIL - see notes [password-reset-pass]: FAIL - not implemented

REGRESSION EVALS

METRICS

Capability pass@1: 50% Capability pass@3: 100% Regression pass^3: 100%

NOTES

Password validation test is flaky due to timing issue. Need to implement password reset flow.

RECOMMENDATION

NEEDS WORK - Complete password reset implementation


---

## Команды документации и архитектуры

### /update-docs: Синхронизация документации

**Назначение**: Синхронизация документации из исходного кода.

**Сценарии применения**:
- Обновление документации после изменений кода
- Поддержание синхронизации документации с кодом

**Рабочий процесс**:

Чтение секции scripts в package.json
- Генерация справочной таблицы скриптов
- Извлечение описаний из комментариев ↓
Чтение .env.example
- Извлечение всех переменных окружения
- Документирование назначения и формата ↓
Генерация docs/CONTRIB.md
- Рабочий процесс разработки
- Доступные скрипты
- Настройка окружения
- Процедуры тестирования ↓
Генерация docs/RUNBOOK.md
- Процедуры деплоя
- Мониторинг и алерты
- Частые проблемы и решения
- Процедуры отката ↓
Выявление устаревшей документации
- Поиск документов, не изменявшихся 90+ дней
- Список для ручной проверки ↓
Отображение сводки изменений


::: tip Единый источник истины

package.json и .env.example являются единственным источником истины.

:::

---

### /update-codemaps: Обновление архитектурной документации

**Назначение**: Анализ структуры кодовой базы и обновление архитектурной документации.

**Сценарии применения**:
- После изменения структуры кода
- Необходимость обновления архитектурной документации

**Рабочий процесс**:

Сканирование всех исходных файлов на импорты, экспорты и зависимости ↓
Генерация компактных codemaps:
- codemaps/architecture.md - общая архитектура
- codemaps/backend.md - структура бэкенда
- codemaps/frontend.md - структура фронтенда
- codemaps/data.md - модели данных и схемы ↓
Расчёт процента изменений относительно предыдущей версии ↓
Если изменения > 30%, запрос подтверждения пользователя перед обновлением ↓
Добавление временной метки актуальности для каждого codemap ↓
Сохранение отчёта в .reports/codemap-diff.txt


**Пример**:

Вы: /update-codemaps

Claude: Анализ структуры кодовой базы...

Scanning 156 files... Found 89 imports and 124 exports

Codemap Diff

Previous version: 2026-01-20 Current version: 2026-01-25 Diff: 12% (under 30% threshold)

✅ Safe to update

Updated Codemaps

codemaps/architecture.md

Updated module dependencies
Added new services: auth, notifications
Removed deprecated modules: legacy-db

codemaps/backend.md

Updated API routes structure
Added middleware documentation

codemaps/frontend.md

Updated component hierarchy
Added new pages: profile, settings

codemaps/data.md

Updated database schemas
Added new tables: users, sessions

Summary: 4 codemaps updated, 12% change


---

## Команды управления состоянием

### /checkpoint: Сохранение состояния работы

**Назначение**: Создание или верификация контрольных точек в рабочем процессе.

**Сценарии применения**:
- Сохранение важных этапов разработки
- Поддержка отката и отслеживания прогресса

**Подкоманды**:

- `create <name>` - создание именованной контрольной точки
- `verify <name>` - верификация контрольной точки
- `list` - отображение всех контрольных точек
- `clear` - удаление старых контрольных точек (сохраняются последние 5)

**Пример**:

Вы: /checkpoint create feature-start

Claude:

Creating Checkpoint: feature-start

Running /verify quick...

Build: ✅ OK Types: ✅ OK

Creating checkpoint...

✅ Checkpoint "feature-start" created ├─ Timestamp: 2026-01-25-14:30 ├─ Git SHA: abc1234 └─ Status: Clean (no uncommitted changes)

Вы: /checkpoint verify feature-start

Claude: CHECKPOINT COMPARISON: feature-start

Files changed: 5 Tests: +3 passed / -0 failed Coverage: +5% / -0% Build: PASS

Changes since checkpoint: ✅ src/services/auth.ts (modified) ✅ tests/auth.test.ts (added) ✅ src/components/Login.tsx (added)


**Рабочий процесс**:

[Начало] → /checkpoint create "feature-start" | [Реализация] → /checkpoint create "core-done" | [Тестирование] → /checkpoint verify "core-done" | [Рефакторинг] → /checkpoint create "refactor-done" | [PR] → /checkpoint verify "feature-start"


---

## Команды обучения и оптимизации

### /learn: Извлечение переиспользуемых паттернов

**Назначение**: Анализ текущей сессии и извлечение паттернов, которые можно сохранить как skill.

**Сценарии применения**:
- После решения нетривиальной проблемы
- Обнаружение переиспользуемых паттернов решения ошибок
- Документирование специфичных для проекта соглашений

**Что извлекается**:

1. **Паттерны решения ошибок**
   - Какая ошибка произошла?
   - Какова корневая причина?
   - Как исправили?
   - Можно ли переиспользовать для похожих ошибок?

2. **Техники отладки**
   - Неочевидные шаги отладки
   - Эффективные комбинации инструментов
   - Диагностические паттерны

3. **Обходные решения**
   - Особенности библиотек
   - Ограничения API
   - Исправления для конкретных версий

4. **Специфичные для проекта паттерны**
   - Обнаруженные соглашения кодовой базы
   - Принятые архитектурные решения
   - Паттерны интеграции

**Пример**:

Вы: /learn

Claude:

Extracting Patterns from Session

Reviewing session history...

Found 3 extractable patterns:

Pattern 1: Supabase Auth Session Recovery

Type: Error Resolution Reusability: High (affects all auth endpoints)

Problem

After user logs in, subsequent API calls fail with 401 Unauthorized.

Root Cause

Supabase session cookie is not being sent to backend API due to CORS configuration.

Solution

typescript

// Configure Supabase with correct URL
const supabase = createClient(
  import.meta.env.VITE_SUPABASE_URL,
  import.meta.env.VITE_SUPABASE_ANON_KEY,
  {
    auth: {
      storageKey: 'my-app-auth',
      autoRefreshToken: true,
      detectSessionInUrl: true,
    },
  }
)

When to Use

Trigger: Auth endpoints returning 401 unexpectedly

Pattern 2: Playwright Test Flakiness Fix

Type: Debugging Technique Reusability: Medium (affects async UI tests)

Problem

Test "user can click submit button" fails intermittently with timeout.

Root Cause

Button is disabled initially due to async validation, but test doesn't wait.

Solution

typescript

// Use explicit wait with predicate
await page.waitForSelector('[data-testid="submit-btn"]:not(:disabled)', {
  timeout: 10000
})

// Then click
await page.locator('[data-testid="submit-btn"]').click()

When to Use

Trigger: Test timing issues with async UI state

Do you want to save these patterns? (yes/no/modify)


::: tip Принцип фокусировки

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

:::

---

## Команды конфигурации

### /setup-pm: Настройка пакетного менеджера

**Назначение**: Настройка предпочтительного пакетного менеджера для проекта или глобально.

**Сценарии применения**:
- Определение текущего используемого пакетного менеджера
- Установка глобальных или проектных предпочтений

**Приоритет определения**:

1. Переменная окружения: `CLAUDE_PACKAGE_MANAGER`
2. Конфигурация проекта: `.claude/package-manager.json`
3. package.json: поле `packageManager`
4. Lock-файлы: package-lock.json, yarn.lock, pnpm-lock.yaml, bun.lockb
5. Глобальная конфигурация: `~/.claude/package-manager.json`
6. Fallback: первый доступный пакетный менеджер

**Приоритет поддерживаемых пакетных менеджеров**: pnpm > bun > yarn > npm

**Пример**:

```bash
# Определение текущего пакетного менеджера
node scripts/setup-package-manager.js --detect

# Установка глобального предпочтения
node scripts/setup-package-manager.js --global pnpm

# Установка проектного предпочтения
node scripts/setup-package-manager.js --project bun

# Список доступных пакетных менеджеров
node scripts/setup-package-manager.js --list

Конфигурационные файлы:

Глобальная конфигурация (~/.claude/package-manager.json):

json

{
  "packageManager": "pnpm"
}

Проектная конфигурация (.claude/package-manager.json):

json

{
  "packageManager": "bun"
}

Переменная окружения переопределяет все методы определения:

bash

# macOS/Linux
export CLAUDE_PACKAGE_MANAGER=pnpm

# Windows (PowerShell)
$env:CLAUDE_PACKAGE_MANAGER = "pnpm"

Комбинированные рабочие процессы

Полный цикл разработки функции

1. /plan "Добавить функцию аутентификации пользователей"
   ↓ Создание плана реализации
2. /tdd "Реализовать сервис аутентификации"
   ↓ TDD-разработка
3. /test-coverage
   ↓ Обеспечение покрытия ≥ 80%
4. /code-review
   ↓ Код-ревью
5. /verify pre-pr
   ↓ Комплексная верификация
6. /checkpoint create "auth-feature-done"
   ↓ Сохранение контрольной точки
7. /update-docs
   ↓ Обновление документации
8. /update-codemaps
   ↓ Обновление архитектурной документации

Процесс исправления багов

1. /checkpoint create "bug-start"
   ↓ Сохранение текущего состояния
2. /orchestrate bugfix "Исправить ошибку входа"
   ↓ Автоматизированный процесс исправления
3. /test-coverage
   ↓ Обеспечение покрытия тестами
4. /verify quick
   ↓ Верификация исправления
5. /checkpoint verify "bug-start"
   ↓ Сравнение с контрольной точкой

Процесс аудита безопасности

1. /orchestrate security "Аудит платёжного процесса"
   ↓ Процесс проверки с приоритетом безопасности
2. /e2e "Тестирование платёжного процесса"
   ↓ End-to-end тестирование
3. /code-review
   ↓ Код-ревью
4. /verify pre-pr
   ↓ Комплексная верификация

Краткая справочная таблица команд

Команда	Основное назначение	Вызываемый агент	Результат
`/plan`	Создание плана реализации	planner	Поэтапный план
`/tdd`	TDD-разработка	tdd-guide	Тесты + реализация + покрытие
`/orchestrate`	Последовательное выполнение агентов	несколько агентов	Комплексный отчёт
`/code-review`	Код-ревью	code-reviewer, security-reviewer	Отчёт о безопасности и качестве
`/build-fix`	Исправление ошибок сборки	build-error-resolver	Сводка исправлений
`/refactor-clean`	Очистка мёртвого кода	refactor-cleaner	Сводка очистки
`/verify`	Комплексная верификация	Bash	Отчёт верификации
`/e2e`	End-to-end тестирование	e2e-runner	Playwright-тесты + артефакты
`/test-coverage`	Анализ покрытия	Bash	Отчёт покрытия + недостающие тесты
`/eval`	Eval-driven разработка	Bash	Отчёт о статусе eval
`/checkpoint`	Сохранение состояния	Bash + Git	Отчёт о контрольной точке
`/learn`	Извлечение паттернов	continuous-learning skill	Файл skill
`/update-docs`	Синхронизация документации	doc-updater agent	Обновление документации
`/update-codemaps`	Обновление архитектуры	doc-updater agent	Обновление codemap
`/setup-pm`	Настройка пакетного менеджера	Node.js скрипт	Определение пакетного менеджера

Предупреждения о типичных ошибках

❌ Не пропускайте этап планирования

Для сложных функций начало кодирования без плана приводит к:

Пропуску важных зависимостей
Несогласованности архитектуры
Неправильному пониманию требований

✅ Правильный подход: Используйте /plan для создания детального плана, дождитесь подтверждения перед реализацией.

❌ Не пропускайте фазу RED в TDD

Если сначала писать код, а потом тесты — это уже не TDD.

✅ Правильный подход: Строго следуйте циклу RED → GREEN → REFACTOR.

❌ Не игнорируйте CRITICAL-проблемы в /code-review

Уязвимости безопасности могут привести к утечке данных, финансовым потерям и другим серьёзным последствиям.

✅ Правильный подход: Исправьте все проблемы уровня CRITICAL и HIGH перед коммитом.

❌ Не удаляйте код без тестирования

Анализ мёртвого кода может давать ложные срабатывания, прямое удаление может сломать функциональность.

✅ Правильный подход: Запускайте тесты перед каждым удалением, убедитесь, что существующая функциональность не нарушена.

❌ Не забывайте использовать /learn

Если не извлекать паттерны после решения нетривиальных проблем, придётся решать те же проблемы заново.

✅ Правильный подход: Регулярно используйте /learn для извлечения переиспользуемых паттернов и накопления знаний.

Итоги урока

15 слэш-команд Everything Claude Code обеспечивают полную поддержку рабочего процесса разработки:

Процесс разработки: /plan → /tdd → /orchestrate
Качество кода: /code-review → /build-fix → /refactor-clean → /verify
Тестирование: /e2e → /test-coverage → /eval
Документация и архитектура: /update-docs → /update-codemaps
Управление состоянием: /checkpoint
Обучение и оптимизация: /learn
Конфигурация: /setup-pm

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

Анонс следующего урока

В следующем уроке мы изучим Подробный разбор основных Agents.
Вы узнаете:
Обязанности и сценарии применения 9 специализированных агентов
Когда вызывать какого агента
Способы взаимодействия между агентами
Как настраивать конфигурацию агентов

Приложение: Справочник исходного кода

Нажмите, чтобы развернуть расположение исходного кода

Дата обновления: 2026-01-25

Функция	Путь к файлу	Строки
Команда TDD	`commands/tdd.md`	1-327
Команда Plan	`commands/plan.md`	1-114
Команда Code Review	`commands/code-review.md`	1-41
Команда E2E	`commands/e2e.md`	1-364
Команда Build Fix	`commands/build-fix.md`	1-30
Команда Refactor Clean	`commands/refactor-clean.md`	1-29
Команда Learn	`commands/learn.md`	1-71
Команда Checkpoint	`commands/checkpoint.md`	1-75
Команда Verify	`commands/verify.md`	1-60
Команда Test Coverage	`commands/test-coverage.md`	1-28
Команда Setup PM	`commands/setup-pm.md`	1-81
Команда Update Docs	`commands/update-docs.md`	1-32
Команда Orchestrate	`commands/orchestrate.md`	1-173
Команда Update Codemaps	`commands/update-codemaps.md`	1-18
Команда Eval	`commands/eval.md`	1-121
Определение плагина	`.claude-plugin/plugin.json`	1-28

Ключевые константы:

Целевое покрытие TDD: 80% (критический код 100%) - commands/tdd.md:293-300

Ключевые функции:

Цикл TDD: RED → GREEN → REFACTOR - commands/tdd.md:40-47
Механизм ожидания подтверждения Plan - commands/plan.md:96
Уровни серьёзности Code Review: CRITICAL, HIGH, MEDIUM - commands/code-review.md:33

Подробный разбор основных Commands: полное руководство по 15 слэш-командам ​

Что вы сможете делать после изучения ​

Ваши текущие проблемы ​

Основная концепция ​

Обзор команд ​

Команды процесса разработки ​

/plan: Планирование сложных функций ​

/tdd: Разработка через тестирование ​

Step 2: Write Failing Test (RED) ​

Step 3: Run Tests - Verify FAIL ​

Step 4: Implement Minimal Code (GREEN) ​

Step 5: Run Tests - Verify PASS ​

Step 6: Refactor (IMPROVE) ​

Step 7: Verify Tests Still Pass ​

Step 8: Check Coverage ​

ORCHESTRATION REPORT ​

SUMMARY ​

AGENT OUTPUTS ​

FILES CHANGED ​

TEST RESULTS ​

SECURITY STATUS ​

RECOMMENDATION ​

Code Review Report ​

Security Issues (CRITICAL) ​

Code Quality (HIGH) ​

Best Practices (MEDIUM) ​

SUMMARY ​

Fixing Build Errors ​

Error 1: Type 'string' is not assignable to type 'number' ​

Error 2: Cannot find module './utils' ​

SUMMARY ​

Dead Code Analysis ​

Tools Run ​

Classification ​

SAFE (Can delete) ​

CAUTION (Review first) ​

DANGER (Do not delete) ​

Deletion Plan ​

SUMMARY ​

Verification Report ​

E2E Test Generation: Market Search and View Flow ​

Test Scenario Identified ​

Generated Test Code ​

Running Tests ​

Test Report ​

/test-coverage: Анализ покрытия тестами ​

File: src/components/Button.tsx (45% coverage) ​

After Adding Tests ​

EVAL: user-auth ​

Capability Evals ​

Regression Evals ​

Success Criteria ​

EVAL CHECK: user-auth ​

EVAL REPORT: user-auth ​

CAPABILITY EVALS ​

REGRESSION EVALS ​

METRICS ​

NOTES ​

RECOMMENDATION ​

Codemap Diff ​

Updated Codemaps ​

Creating Checkpoint: feature-start ​

Claude: CHECKPOINT COMPARISON: feature-start ​

Extracting Patterns from Session ​

Pattern 1: Supabase Auth Session Recovery ​

Problem ​

Root Cause ​

Solution ​

When to Use ​

Pattern 2: Playwright Test Flakiness Fix ​

Problem ​

Root Cause ​

Solution ​

When to Use ​

Комбинированные рабочие процессы ​

Полный цикл разработки функции ​

Процесс исправления багов ​

Процесс аудита безопасности ​

Краткая справочная таблица команд ​

Предупреждения о типичных ошибках ​

Подробный разбор основных Commands: полное руководство по 15 слэш-командам

Что вы сможете делать после изучения

Ваши текущие проблемы

Основная концепция

Обзор команд

Команды процесса разработки

/plan: Планирование сложных функций

/tdd: Разработка через тестирование

Step 2: Write Failing Test (RED)

Step 3: Run Tests - Verify FAIL

Step 4: Implement Minimal Code (GREEN)

Step 5: Run Tests - Verify PASS

Step 6: Refactor (IMPROVE)

Step 7: Verify Tests Still Pass

Step 8: Check Coverage

ORCHESTRATION REPORT

SUMMARY

AGENT OUTPUTS

FILES CHANGED

TEST RESULTS

SECURITY STATUS

RECOMMENDATION

Code Review Report

Security Issues (CRITICAL)

Code Quality (HIGH)

Best Practices (MEDIUM)

SUMMARY

Fixing Build Errors

Error 1: Type 'string' is not assignable to type 'number'

Error 2: Cannot find module './utils'

SUMMARY

Dead Code Analysis

Tools Run

Classification

SAFE (Can delete)

CAUTION (Review first)

DANGER (Do not delete)

Deletion Plan

SUMMARY

Verification Report

E2E Test Generation: Market Search and View Flow

Test Scenario Identified

Generated Test Code

Running Tests

Test Report

/test-coverage: Анализ покрытия тестами

File: src/components/Button.tsx (45% coverage)

After Adding Tests

EVAL: user-auth

Capability Evals

Regression Evals

Success Criteria

EVAL CHECK: user-auth

EVAL REPORT: user-auth

CAPABILITY EVALS

REGRESSION EVALS

METRICS

NOTES

RECOMMENDATION

Codemap Diff

Updated Codemaps

Creating Checkpoint: feature-start

Claude: CHECKPOINT COMPARISON: feature-start

Extracting Patterns from Session

Pattern 1: Supabase Auth Session Recovery

Problem

Root Cause

Solution

When to Use

Pattern 2: Playwright Test Flakiness Fix

Problem

Root Cause

Solution

When to Use

Комбинированные рабочие процессы

Полный цикл разработки функции

Процесс исправления багов

Процесс аудита безопасности

Краткая справочная таблица команд

Предупреждения о типичных ошибках