Больше фичей Claude Code

Стартовая точка

Считаем, что путь новичка пройден: Claude Code установлен, Atlassian MCP подключён, агент видит задачи в Jira и страницы в Confluence. Если нет — сначала туда, тут мы только наращиваем.

Фундамент: каркас, эталонный тест и CLAUDE.md

Инициализируй пустое Playwright-репо — npm init playwright@latest: это ставит раннер @playwright/test, которым потом гоняются спеки (npx playwright test). Разложи трёхслойную архитектуру: pom/ (локаторы), steps/ (действия), assertions/ (проверки). Напиши один аккуратный тест руками — агент копирует стиль образца: дашь один грамотный тест, получишь десять таких же.

Далее в корне проекта нам нужен CLAUDE.md — постоянная память проекта: где какой слой лежит, конвенции именования, и правила, которые агент не должен нарушать (грабли из прошлых прогонов). Без этого файла агент путает слои и может сломать архитектуру проекта.

Дай агенту глаза — Playwright

Дай агенту браузер — Playwright. Теперь он может открыть живую страницу, собрать реальные локаторы и data-testid, увидеть обязательные поля. По умолчанию бери Playwright CLI (@playwright/cli): водит браузер так же, как MCP, но заметно дешевле по токенам — в контекст падает только вывод команды, а не снапшот страницы на каждый шаг. MCP оставь для точечных интерактивных сценариев.

npm install -g @playwright/cli@latest

Подключи TMS — Qase MCP

Чтобы агент не плодил дубли и сверялся с уже существующими тест-кейсами, дай ему доступ к TMS (системе управления тестами) через MCP. Для примера — Qase: у него есть официальный рабочий MCP-сервер. Подойдёт MCP любой TMS, подключается так же.

claude mcp add qase --env QASE_API_TOKEN=<твой-токен> -- npx -y @qase/mcp-server

Где взять токен, вариант через .mcp.json и что агент умеет с TMS — в статье «Как подключить TMS-систему».

Настройки и разрешения: settings.json

По умолчанию агент спрашивает разрешение на каждое потенциально опасное действие. Чтобы не тыкать «да» сто раз, но и не раздавать всё подряд, настрой разрешения в settings.json. Файл бывает двух видов — отличаются тем, где лежат:

• .claude/settings.json — в корне проекта, общий для команды (коммитится в репозиторий);
• ~/.claude/settings.json — в твоей домашней папке (~), личный, только для тебя на этой машине.

Разумный дефолт для этого сетапа: разрешить безопасное без спроса (читать репо, запросы в MCP, прогон тестов), а разрушительное оставить за подтверждением (rm, git push, миграции БД).

Пример settings.json

{
  "permissions": {
    "allow": [
      "Read(./**)",
      "Bash(npm test:*)",
      "Bash(npx playwright test:*)",
      "Bash(playwright-cli:*)",
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "mcp__mcp-atlassian",
      "mcp__qase"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(npm run migrate:*)"
    ],
    "deny": [
      "Bash(rm:*)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Правило — это Инструмент(шаблон): Bash(git push:*) ловит любую команду, начинающуюся с git push; * — джокер. Приоритет: deny → ask → allow (запрет всегда сильнее). Целый MCP-сервер открывается одной строкой mcp__<имя-сервера> — поэтому здесь без спроса разрешены инструменты, подключённые на прошлых шагах: playwright-cli, MCP Atlassian и Qase.

Создай субагентов и раздай работу

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

• Confluence → описание фичи и бизнес-правила;
• фронт-репо (через glab) → форма, поля, data-testid;
• бэк-репо (через glab) → API, контракты, валидации;
• TMS → существующие тест-кейсы, чтобы не дублировать.

Все отдают результат оркестратору. Параллельно — быстрее, и каждый агент не засоряет общий контекст лишним.

Как создать. Каждый субагент — это Markdown-файл с YAML-фронтматтером. Два способа:

• Команда /agents — интерактивный мастер прямо в Claude Code: задаёшь имя, описание, инструменты и модель, файл создаётся сам. Самый простой путь.
• Вручную — положи .md-файл в одну из папок:
  • .claude/agents/ — в корне проекта, общий для команды (коммитится);
  • ~/.claude/agents/ — личный, на все твои проекты.

В фронтматтере обязательны name и description — по description оркестратор понимает, когда звать агента. Тело файла — это системный промпт субагента. Минимальный «сборщик контекста» из Confluence — файл .claude/agents/context-confluence.md:

---
name: context-confluence
description: Ищет описание фичи в Confluence. Use when нужно собрать требования по фиче.
---

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

Дальше просто попроси оркестратор: «собери контекст по фиче X — Confluence, фронт- и бэк-репо, TMS — параллельно». Он сам раздаст работу подходящим субагентам по их description.

Удешеви субагентов — модель и инструменты

Сбор контекста (читать, искать) — простая работа, мощная модель тут избыточна. У субагента во фронтматтере есть два опциональных поля, которые срезают расход:

• model — поставь дешёвую и быструю, например haiku. Оркестратор остаётся на мощной модели (Opus), а четыре «сборщика» бегают на Haiku — это заметно экономит токены без потери качества на таких подзадачах.
• tools — сузь доступ ровно до нужного (здесь — только MCP Atlassian). Так агент не лезет куда не просили и не тратит токены на лишние инструменты.

Тот же context-confluence, но уже «дешёвый»:

---
name: context-confluence
description: Ищет описание фичи в Confluence. Use when нужно собрать требования по фиче.
model: haiku
tools: mcp__mcp-atlassian
---

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

Сделай так для всех четырёх «сборщиков» — и параллельный сбор контекста обойдётся в разы дешевле, чем если бы всё тянула одна дорогая по стоимости модель.

Собери боевой skill — /generate-test

Всё, что собрано на прошлых шагах (память, браузер, MCP, субагенты), пора склеить в один повторяемый воркфлоу — skill. Это команда, которую агент запускает сам по описанию или ты — вручную через /generate-test.

Что такое skill. Это папка с файлом SKILL.md внутри. Имя папки = имя команды. Лежит в одном из двух мест:

• .claude/skills/<имя>/ — в проекте, общий для команды (коммитится);
• ~/.claude/skills/<имя>/ — личный, на все твои проекты.

Как создать. Сделай папку и положи в неё SKILL.md:

mkdir -p .claude/skills/generate-test

SKILL.md — это YAML-фронтматтер + инструкции в Markdown:

• description — самое важное. Это единственное, что агент видит, решая, пора ли грузить skill. Пиши что делает и когда применять (с примерами фраз-триггеров).
• allowed-tools (опц.) — ограничить, чем skill может пользоваться.
• Тело файла — пошаговые инструкции: агент выполняет их, когда skill активирован.

Как подключить ранее созданных субагентов. Прямо в теле SKILL.md называешь субагентов по имени — оркестратор сам раздаст им работу по фазе сбора контекста. Никакого особого синтаксиса: skill — это инструкция оркестратору, а он уже знает про агентов из .claude/agents/.

---
name: generate-test
description: Генерирует Playwright e2e-тест по названию фичи. Use when пользователь просит «напиши тест на ...», «сделай е2е», «автотест на X».
allowed-tools: Read, Write, Edit, Bash, Task
---

# Generate Test

## Фаза 1. Сбор контекста — параллельно, субагентами
Запусти разом и дождись всех:
- **context-confluence** → описание фичи и бизнес-правила;
- **context-front** → поля формы и `data-testid` (через `glab`);
- **context-back** → API, контракты, валидации (через `glab`);
- **context-tms** → существующие кейсы в Qase, чтобы не дублировать.
Чего критично не хватает — спроси пользователя, не выдумывай.

## Фаза 2. Живая валидация (playwright-cli)
Открой страницу через playwright-cli, собери реальные локаторы
и обязательные поля, сверь лейблы опций с кодом.

## Фаза 3. Генерация (по слоям, стиль — из эталонного теста)
POM → steps → assertions → spec.

## Фаза 4. Запуск и починка
Прогони спек через `npx playwright test`, читай ошибку,
чини по CLAUDE.md. Зелёный прогон — переходи к Фазе 5.

## Фаза 5. Верификация (зелёный ≠ корректный)
Перечитай тест: проверяет ли он то, что описано в требованиях
(Фаза 1), а не просто «не падает». Сверь ассерты с бизнес-правилами,
убедись, что нет ложно-зелёного (пустой ожидаемый результат,
закомментированная проверка). Сомнительное — покажи пользователю.

Поправь пути и имена под свой проект — и /generate-test Авторизация запускает весь воркфлоу одной командой.

Готово — запусти и заверни в плагин

Skill работает. Запускать можно по-разному:

• По названию фичи — агент сам найдёт описание в Confluence и соберёт контекст:

  /generate-test Авторизация

• По ID готового тест-кейса в TMS — агент вытащит шаги и ожидаемый результат прямо из Qase через MCP и сгенерирует автотест по ним:

  /generate-test QASE-123

• Без явной команды — по description агент подхватит skill, когда попросишь «напиши тест на …».

Агент сам пройдёт все фазы: соберёт контекст субагентами, сверится с живой страницей через Playwright, сгенерирует тест по слоям, прогонит его и проверит, что зелёный — по делу (Фаза 5).

Что должно получиться на выходе — спек поверх трёхслойной архитектуры (детали скрыты в pom/steps/assertions, как в эталонном тесте):

import { test } from '@playwright/test';
import { loginSteps } from '../steps/login.steps';
import { loginAssertions } from '../assertions/login.assertions';

test('успешный вход по валидным данным', async ({ page }) => {
  await loginSteps.open(page);
  await loginSteps.submit(page, 'user@company.com', 'correct-horse');
  await loginAssertions.onDashboard(page);
});

Тонкий, читаемый спек — вся механика в слоях. Именно поэтому в «Фундаменте» мы задавали стиль эталонным тестом: агент копирует его, а не изобретает свой.

Дальше упакуй /generate-test, конвенции из CLAUDE.md, субагентов (а если настроишь хуки — см. дополнительные шаги — то и их) в плагин и раздай команде через маркетплейс. Теперь не только у тебя — у всех QA одной командой генерится тест в общей архитектуре.

Несколько фич разом — git worktree

Нужно генерить тесты на несколько фич сразу? Не держи их в одной сессии — дай каждому агенту git worktree: свою изолированную копию репозитория на отдельной ветке, без конфликтов с остальными.

Руками плодить папки не нужно — попроси самого агента: «заведи worktree под фичу auth и работай в нём». Под капотом это просто:

git worktree add ../repo-auth -b tests/auth   # агент делает сам

Дальше в каждом worktree — своя сессия Claude Code и свой /generate-test. Несколько фич = несколько сессий на изолированных ветках.

Автоматизируй рутину — хук

Чтобы не запускать линт руками после каждой генерации, повесь хук на событие: после того как агент изменил файл (Edit/Write), автоматически гнать по нему eslint --fix. Конфиг — в settings.json, рядом с разрешениями:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx eslint --fix"
          }
        ]
      }
    ]
  }
}

Как это работает: после каждого Edit/Write Claude Code отдаёт хуку JSON события на stdin; jq достаёт оттуда путь изменённого файла и передаёт его в eslint --fix. Агент правит код — хук молча причёсывает, ты видишь только результат.

Чинить до зелёного — /loop

Сгенерированный тест редко зеленеет с первого раза. Вместо ручного «запусти — почини — снова» запусти /loop: агент сам повторяет цикл — прогоняет тест, читает ошибку, правит по CLAUDE.md и собранному контексту, и так пока не позеленеет (или пока не упрётся в то, что требует тебя).

/loop прогони сгенерированный тест и чини, пока не станет зелёным

Готовые рецепты лупов (с условием выхода и проверками) — в каталоге Loops!.

Держи сессию в порядке — /compact и /rewind

Сбор контекста и параллельная работа быстро раздувают контекст-окно — и агент начинает «тупеть» и терять детали. Два инструмента держат сессию в форме:

• /compact — сжимает историю, не бросая сессию: суть остаётся, мусор уходит, окно дышит.
• /rewind — откат к чекпоинту, если агент ушёл не туда. Неудачный прогон не надо разгребать руками — вернулся на шаг назад и переформулировал.

Не жди, пока агент начнёт путаться: чем чище контекст, тем точнее ответы.