Brewcode:E2e

<instructions>

E2E Testing

Full-cycle E2E testing orchestration: setup agents, create BDD scenarios, write autotests, quorum review.

Arguments: $ARGUMENTS

---

Phase 0: Parse Arguments

EXECUTE using Bash tool:

bash "${CLAUDE_SKILL_DIR}/scripts/detect-mode.sh" "$ARGUMENTS" && echo "OK" || echo "FAILED"

Output: MODE:xxx and optionally PROMPT:xxx. Store both.

STOP if FAILED -- fix detect-mode.sh before continuing.

---

Phase 1: Display Detection

Output detection result:

Mode: {MODE}
Prompt: {PROMPT or "none"}

---

Phase 2: Load Mode Reference

Read the mode-specific reference file:

Also load core references (always):

• ${CLAUDE_SKILL_DIR}/references/e2e-rules.md -- rules for all agents
• ${CLAUDE_SKILL_DIR}/references/e2e-architecture.md -- architecture reference

STOP if mode reference not found -- report missing file.

---

Phase 3: Execute Mode Flow

Follow the loaded mode reference step by step. Pass PROMPT as context where indicated.

Common patterns across all modes:

Prerequisite Check (all modes except setup and status)

.claude/agents/e2e-*.md count must be >=3. If not -> "Run /brewcode:e2e setup first." STOP. Status mode reports missing infrastructure instead of blocking.

Review Cycle (create, update modes)

MAX_CYCLES=3. Pattern: execute -> reviewer validates -> different agent re-checks -> fix confirmed -> repeat.

Agent Dispatch

All agent work through Task tool. Spawn parallel agents in ONE message when possible.

User Interaction

AskUserQuestion at every key decision point. PROMPT is initial context, not a replacement for confirmation.

---

Error Handling

---

Output Format

# e2e [{MODE}]

## Detection
| Field | Value |
|-------|-------|
| Arguments | `{raw args}` |
| Mode | `{MODE}` |
| Prompt | `{PROMPT or none}` |

## Results
{Mode-specific output}

## Next Steps
- {recommendations based on mode}

</instructions>

Скилл brewcode:e2e и E2E-агенты

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

Цель

Скилл brewcode:e2e + набор E2E-агентов для полного цикла тестирования: анализ → сценарии → автотесты → ревью. Модель: скилл-менеджер делегирует через Task tool.

---

1. Скилл: brewcode:e2e

Расположение (уточнить при планировании)

brewcode/skills/e2e/
├── SKILL.md
├── README.md
├── scripts/
│   └── detect-mode.sh           # Парсинг аргументов: MODE, PROMPT
├── references/
│   ├── e2e-rules.md             # Базовые правила E2E (раздел 3)
│   ├── e2e-architecture.md      # Архитектурные паттерны E2E (раздел 4)
│   ├── agent-template.md        # Шаблон E2E-агентов (адаптация из teams)
│   └── review-checklist.md      # Чеклист ревью тестов и сценариев

Открытые вопросы: нужны ли per-mode/per-agent references? templates/ для сценариев и отчётов?

Frontmatter (черновик)

---
name: brewcode:e2e
description: "TODO: <= 120 символов (optimal ~100), single line, что + 3-5 trigger keywords"
# model, context, allowed-tools, argument-hint — определить при планировании
---

Режимы

Каждый режим принимает опциональный промт. Без промта — уточнение через AskUserQuestion. С промтом — используется как контекст, но план всё равно подтверждается.

Принципы скилла

1. AskUserQuestion всегда — на каждом ключевом этапе. Промт — контекст, не замена подтверждения. 2. Трёхшаговый цикл: Выполнение → Валидация → Перепроверка → Исправление. Повторяется до 0 проблем. 3. Без сценария — не пишем тесты. E2E-тест создаётся исключительно по утверждённому, воспроизводимому вручную сценарию. 4. Делегирование через агентов — скилл только управляет через Task tool.

---

2. Агенты E2E

Расположение, модели, набор инструментов — определить при планировании.

Открытые вопросы: нужны e2e-data-engineer, e2e-infra? Модели и disallowedTools — определить при планировании.

Шаблон агентов

Источник: brewcode/skills/teams/references/agent-template.md — скопировать и адаптировать под E2E.

Обязательные элементы: Mission / Domain / Character / Last Updated | Immutable Traits (Name, Base Role) | Task Acceptance Protocol | Domain Instructions | Colleagues (таблица E2E-команды)

Дополнительные требования:

• Самокритичность: агент проверяет результат перед отдачей менеджеру.
• Загрузка правил: агенты, пишущие или ревьюящие код, загружают e2e-rules.md до начала работы. Если файл не найден — стоп, сообщить менеджеру.
• Eager по умолчанию — загружать и валидировать до начала работы. lazy только если указано явно.
• Создание: через Task(subagent_type="brewcode:agent-creator"), батчами по 3-4. Agent description <= 100 chars (optimal ~80), single line, role + 2-3 triggers, no <example> blocks.

---

3. Правила E2E (references/e2e-rules.md)

При setup: WebSearch лучших практик → структурировать полный набор. Правила: короткие, конкретные, actionable. При режиме `rules`: обновить по опыту проекта, перепроверить все источники.

Сценарии

Тестовые данные

Интеграция

Ассерты

Архитектура (подробнее в e2e-architecture.md)

Процесс

---

4. Архитектура E2E (references/e2e-architecture.md)

┌─────────────────────────────────────────────┐
│  Test Classes (по доменам)                  │
│  extends BaseE2E / BaseDomainE2E            │
│  содержат: @ParameterizedTest + шаги        │
├─────────────────────────────────────────────┤
│  Steps Layer (бизнес-шаги)                  │
│  переиспользуемые across tests              │
│  Given/When/Then шаги                       │
├─────────────────────────────────────────────┤
│  Verification Layer (assertion steps)       │
│  строгие проверки, полное сравнение         │
├─────────────────────────────────────────────┤
│  Data Layer                                 │
│  генерация / хранение / подготовка данных   │
│  через API (не прямая запись в БД)          │
├─────────────────────────────────────────────┤
│  Support Layer                              │
│  KafkaSupport, DatabaseSupport, HttpSupport │
├─────────────────────────────────────────────┤
│  Config Layer                               │
│  credentials, endpoints, timeouts           │
└─────────────────────────────────────────────┘

e2e-architect адаптирует архитектуру под стек проекта. Этот документ — отправная точка.

---

5. Детализация режимов

5.1 setup

Цель: подготовить проект — создать агентов, правила, документацию. Промт: уточняет scope. Примеры: "focus on payment domain", "only API tests", "use Playwright + Jest".

1. Проверка статуса: если настроено — предложить другой режим 2. Анализ проекта (3-5 Explore-агентов параллельно): структура, тесты, стек, API, инфраструктура 3. AskUserQuestion: результат анализа, scope, подтверждение плана 4. Создание E2E-агентов через agent-creator (батчами) 5. WebSearch лучших практик + анализ архитектуры → правила 6. Валидация правил (e2e-reviewer) 7. Фиксация документации, AskUserQuestion: итог 8. Опционально: краткие правила в .claude/rules/

5.2 create

Цель: создать E2E-сценарии и тесты. Промт: что тестируем. Примеры: "checkout flow with 3D Secure", "user registration and email verification".

1. AskUserQuestion: scope 2. Анализ системы (3-5 Explore параллельно) 3. Создание сценариев (e2e-scenario-analyst) 4. Валидация сценариев (e2e-reviewer) → перепроверка → исправление 5. AskUserQuestion: одобрение сценариев 6. Написание тестов (e2e-automation-tester) 7. Ревью тестов (e2e-reviewer) → цикл до 0 проблем 8. AskUserQuestion: итог

5.3 update

Цель: улучшить существующие сценарии/тесты. Промт: что улучшить. Примеры: "add negative scenarios to payment tests", "refactor auth steps to use new API".

Аналогично create, но начинается с поиска существующих артефактов.

5.4 review

Цель: мультиагентное ревью с quorum. Промт: scope. Примеры: "review only auth e2e tests", "focus on assertion quality".

1. AskUserQuestion: что ревьюим 2. Разделить scope на части 3. На каждую часть — 3 параллельных e2e-reviewer (quorum 2/3) 4. Ревью сценариев: соответствие тестов и сценариев 5. Перепроверка. Проблема подтверждена если 2 из 3 согласны 6. AskUserQuestion: результат, предложение исправлений

5.5 rules

Цель: создать/обновить правила E2E. Промт: фокус. Примеры: "add rules for async messaging tests", "research Playwright best practices".

1. Загрузить текущие правила, проверить актуальность 2. WebSearch актуальных практик для стека (с учётом промта) 3. e2e-architect: анализ проекта, закономерности 4. Обновление правил с перепроверкой источников 5. AskUserQuestion: diff правил, подтверждение 6. Опционально: summary в .claude/rules/ по запросу

При обновлении — все источники перепроверять. Правила: короткие, конкретные, actionable.

5.6 status

Цель: проверка состояния E2E-инфраструктуры. Промт: фильтр вывода. Примеры: "show only missing agents", "check rules freshness".

---

6. Технические ориентиры

Направляющие принципы, не финальные решения.

Создание агентов:

• Через Task(subagent_type="brewcode:agent-creator") — не вручную
• Батчами по 3-4 (параллельно)
• После создания — оптимизация через Skill(skill="brewtools:text-optimize")
• Шаблон из brewcode/skills/teams/references/agent-template.md

Создание скилла:

• Через Task(subagent_type="brewcode:skill-creator")
• Паттерны: Progressive Disclosure, Reference Splitting, Mode Switcher (detect-mode.sh)
• ${CLAUDE_SKILL_DIR} в SKILL.md, $BC_PLUGIN_ROOT в промтах агентов
• Маркер **EXECUTE** using Bash tool: + && echo "OK" || echo "FAILED"

Правила и документация:

• Полный набор → references/e2e-rules.md (для агентов)
• Архитектура → references/e2e-architecture.md
• Опционально: e2e-avoid.md и e2e-best-practice.md в .claude/rules/ по запросу
• При вынесении в .claude/rules/ — дедупликация обязательна

Валидация: каждый артефакт валидируется после создания. Финальное ревью всего результата. Все находки ревью перепроверяются перед исправлением.

---

7. Открытые вопросы (решить при планировании)

E2E Testing

End-to-end testing orchestration: setup agents, create BDD scenarios, write autotests, review with quorum.

Overview

E2E orchestrates the full end-to-end testing lifecycle. Setup analyzes your project and creates 5 specialized agents (architect, scenario-analyst, automation-tester, manual-tester, reviewer). Create generates BDD scenarios and corresponding autotests with review cycles. Review runs quorum-based quality checks (3 reviewers, 2/3 consensus). Stack-agnostic -- works with Java, Python, JS/TS, and others.

Quick Start

/brewcode:e2e setup                         # 1. Analyze project, create agents, generate rules
/brewcode:e2e create "checkout flow"         # 2. BDD scenarios + autotests
/brewcode:e2e review                         # 3. Quorum review (3 reviewers, 2/3 consensus)

Modes

Agents (created by setup)

Key Principles

• No scenario, no test -- tests only from approved BDD scenarios
• Three-step cycle -- execute, validate (different agent), re-check, fix
• Quorum review -- 3 reviewers, finding confirmed if 2/3 agree
• Review loops capped at 3 iterations, then user decides
• Stack-agnostic architecture with 6 layers: Test Classes, Steps, Verification, Data, Support, Config

Documentation

Full docs: e2e

<!-- TEMPLATE for agent-creator. Fill {PLACEHOLDERS} based on project analysis. Model: opus (default, confirmed by user during setup). Placement: .claude/agents/{agent-name}.md Agent frontmatter (name, description, model, tools) is added by agent-creator on top. -->

{AGENT_NAME}

Mission: {one sentence} Domain: {area of responsibility} Character: {brief characteristic -- CAN change during update} Last Updated: {ISO_DATE}

Immutable Traits (do NOT change during update)

• Name: {AGENT_NAME}
• Base Role: {role -- if role doesn't fit, delete agent and create a new one}

Scope Constraint

This agent accepts tasks ONLY from /brewcode:e2e skill context. Tasks from other skills/contexts -- refuse with explanation.

Rules Loading Protocol

Before starting ANY task: 1. Read rules: $BC_PLUGIN_ROOT/skills/e2e/references/e2e-rules.md 2. If file not found -- STOP immediately, report: "E2E rules not found at expected path" 3. Keep rules in context throughout task execution

Task Acceptance Protocol

Before accepting ANY task:

Self-Check Protocol

Before returning results: 1. Re-read relevant rules from e2e-rules.md 2. Check own output against each applicable rule 3. If violations found -- fix before returning 4. Include "Self-Check: PASS" or list of self-corrections in output

Domain Instructions

{Domain-specific instructions -- filled by agent-creator}

Colleagues

{table -- filled when creating the team}

Layered E2E Test Architecture

Stack-agnostic reference for e2e-architect and e2e-automation-tester agents.

Architecture Diagram

┌─────────────────────────────────────────────┐
│  Test Classes (by domain)                   │
│  extends BaseE2E / BaseDomainE2E            │
│  contains: parameterized tests + steps      │
├─────────────────────────────────────────────┤
│  Steps Layer (business steps)               │
│  reusable across tests                      │
│  Given/When/Then steps                      │
├─────────────────────────────────────────────┤
│  Verification Layer (assertion steps)       │
│  strict checks, full comparison             │
├─────────────────────────────────────────────┤
│  Data Layer                                 │
│  generation / storage / preparation         │
│  via API (not direct DB writes)             │
├─────────────────────────────────────────────┤
│  Support Layer                              │
│  KafkaSupport, DatabaseSupport, HttpSupport │
│  technical integration utilities            │
├─────────────────────────────────────────────┤
│  Config Layer                               │
│  test environment settings                  │
│  credentials, endpoints, timeouts           │
└─────────────────────────────────────────────┘

Key Architecture Requirements

Layer Details

Test Classes

Purpose: Domain-specific test scenarios. Each class covers one bounded context or feature area.

Naming: {Domain}{Feature}E2ETest (e.g. PaymentRefundE2ETest)

Depends on: Steps, base classes only.

class OrderCreationE2ETest extends BaseOrderE2E:

    @ParameterizedTest(dataSets: standardOrders)
    @DisplayName("Order is created and confirmed for {orderType}")
    test createOrder(orderType, expectedStatus):
        // GIVEN
        steps.givenAuthenticatedUser("buyer")
        steps.givenProductAvailable(orderType.productId)
        // WHEN
        steps.whenUserCreatesOrder(orderType)
        // THEN
        verify.thenOrderHasStatus(expectedStatus)

Steps Layer

Purpose: Business-readable actions. Each method is one logical step in domain language.

Naming: {Domain}Steps (e.g. OrderSteps, PaymentSteps)

Depends on: Verification, Data, Support layers.

class OrderSteps:

    @Step("User creates order of type {orderType}")
    whenUserCreatesOrder(orderType):
        payload = orderData.buildOrderPayload(orderType)
        response = httpSupport.post("/api/orders", payload)
        context.storeOrderId(response.body.id)

Verification Layer

Purpose: Assertion logic isolated from test flow. Strict checks with full object comparison.

Naming: {Domain}Verification (e.g. OrderVerification)

Depends on: Support layer (to fetch actual state), Config (timeouts).

class OrderVerification:

    @Step("Order has status {expectedStatus}")
    thenOrderHasStatus(expectedStatus):
        orderId = context.getOrderId()
        actual = httpSupport.get("/api/orders/{orderId}")
        assertThat(actual.status)
            .describedAs("Order %s status", orderId)
            .isEqualTo(expectedStatus)

Data Layer

Purpose: Test data generation, preparation, and cleanup. All mutations through API, never direct DB writes.

Naming: {Domain}Data (e.g. OrderData, UserData)

Depends on: Support layer only.

class OrderData:

    buildOrderPayload(orderType):
        return OrderPayload(
            type: orderType,
            items: generateItems(orderType),
            timestamp: now()
        )

    prepareTestProduct(productId):
        httpSupport.post("/api/admin/products", defaultProduct(productId))

Support Layer

Purpose: Technical integration wrappers. One class per technology. Stateless where possible.

Naming: {Technology}Support (e.g. HttpSupport, KafkaSupport, DatabaseSupport)

Depends on: Config layer only.

class KafkaSupport:

    constructor(config):
        this.bootstrapServers = config.get("kafka.bootstrap-servers")
        this.consumer = createConsumer(this.bootstrapServers)

    consumeMessages(topic, timeout):
        return this.consumer.poll(topic, timeout)

    publishMessage(topic, key, payload):
        this.producer.send(topic, key, serialize(payload))

Config Layer

Purpose: Environment-specific settings. Single source of truth for endpoints, credentials, timeouts.

Naming: TestConfig, E2EConfig, or framework-specific config file.

Depends on: Nothing. This is the bottom layer.

class TestConfig:

    baseUrl = env("BASE_URL", "http://localhost:8080")
    dbHost = env("DB_HOST", "localhost")
    kafkaServers = env("KAFKA_SERVERS", "localhost:9092")
    defaultTimeout = duration("30s")
    retryAttempts = 3

Stack Mapping

Dependency Rules

Test Classes
    |
    v
Steps Layer
    |
    +------+------+
    |             |
    v             v
Verification   Data Layer
    |             |
    +------+------+
           |
           v
    Support Layer
           |
           v
    Config Layer

Allowed dependencies (top-down only):

Forbidden:

E2E Testing Rules

Reference rules for E2E test development. Each category contains actionable rules with review questions for validation.

---

Scenarios

Rules governing what constitutes a valid E2E scenario.

---

Test Data

Rules for test data creation and management.

---

Integration

Rules for system integration within E2E tests.

---

Assertions

Rules for assertion quality and strictness.

---

Architecture

Rules for test code organization and layering.

---

Process

Rules for the development and review workflow.

Mode: CREATE

Create BDD scenarios and E2E autotests for a target area.

C0: Prerequisite Check

Check .claude/agents/e2e-*.md count. If <3 → "Run /brewcode:e2e setup first." STOP. Read .claude/e2e/config.json for stack, framework, paths.

C1: Scope Definition

If PROMPT is non-empty → use as initial context, skip to C2 with brief confirmation. If PROMPT is empty → AskUserQuestion: "What flow/area to create E2E tests for?" Provide examples: "checkout flow with 3D Secure", "user registration and email verification"

C2: Target Analysis

Spawn 3-5 Explore agents in ONE message:

C3: Scenario Creation

Task(subagent_type assigned to e2e-scenario-analyst):

• Input: analysis from C2, scope from C1, rules from config.rulesPath
• Output: BDD scenarios in markdown format

Scenario format:

---
title: "{Descriptive title}"
priority: high|medium|low
tags: [domain, feature]
status: draft
---

Given: {precondition with specific values}
When: {action with specific parameters}
Then: {expected outcome with concrete checks}
And: {additional verifications}

Location: {config.scenarioDir}/{domain}/ (e.g., .claude/e2e/scenarios/checkout/)

C4: Scenario Review Cycle (MAX_CYCLES=3)

cycle = 0
while cycle < 3:
  1. Task(e2e-reviewer): validate scenarios against rules
  2. If no issues → break
  3. Task(e2e-automation-tester): re-check reviewer findings (cross-domain verification)
  4. Confirmed issues → Task(e2e-scenario-analyst): fix
  5. cycle++
if cycle == 3 and issues remain:
  AskUserQuestion: "Review cycle limit reached. {N} issues remain: {list}. Continue anyway?"

C5: User Approval

AskUserQuestion: present all scenarios in table format.

Options: "Approve all" / "Approve with changes" / "Reject — redo"

• If "changes" → AskUser for feedback → back to C3
• If "reject" → back to C1
• Update approved scenarios: status: approved

C6: Test Automation

Task(e2e-automation-tester):

• Input: approved scenarios, architecture from $BC_PLUGIN_ROOT/skills/e2e/references/e2e-architecture.md, rules, config
• MUST load rules and architecture refs before writing code
• Each test file references its source scenario (comment/annotation)
• Follow layered architecture: Test → Steps → Verification → Data → Support → Config
• Location: {config.testSourceDir}/{domain}/

C7: Test Review Cycle (MAX_CYCLES=3)

Same pattern as C4:

cycle = 0
while cycle < 3:
  1. Task(e2e-reviewer): review tests against rules + architecture
  2. If no issues → break
  3. Task(e2e-scenario-analyst): re-check findings (different agent = cross-domain)
  4. Confirmed issues → Task(e2e-automation-tester): fix
  5. cycle++
if cycle == 3 → AskUser with remaining issues

C8: Smoke Validation

Compile/syntax check (stack-dependent):

• Java: mvn compile -pl {module} or gradle compileTestJava
• Python: python -m py_compile {file}
• JS/TS: npx tsc --noEmit or npx playwright test --list
• C#: dotnet build

If fails → Task(e2e-automation-tester): fix compilation errors. Re-check once.

C9: Final Summary

AskUserQuestion with:

• Scenarios created (count, paths)
• Tests created (count, paths)
• Review cycles used
• Traceability: every approved scenario → >=1 test
• Next steps: "Run tests" / /brewcode:e2e review / /brewcode:e2e create "next flow"

Mode: REVIEW

Multi-agent quorum review of E2E scenarios and tests.

R0: Prerequisite Check

Check .claude/agents/e2e-*.md count. If <3 → "Run /brewcode:e2e setup first." STOP. Read .claude/e2e/config.json for stack, framework, paths.

R1: Scope Definition

If PROMPT is non-empty → use as review filter (e.g., "only auth tests", "focus on assertion quality"). If PROMPT is empty → AskUserQuestion: "What to review?" Options: "All scenarios + tests" / "Only scenarios" / "Only tests" / "Specific domain: ___"

R2: Artifact Scan

1. Scan {config.scenarioDir}/ for scenarios 2. Scan {config.testSourceDir}/ for E2E tests 3. If no artifacts found → "No E2E artifacts found. Run /brewcode:e2e create first." STOP.

R3: Scope Splitting

Split review scope into parts by test file or scenario group. Each part should be reviewable independently.

R4: Quorum Review (3x reviewer per part)

For each part, spawn 3 e2e-reviewer agents in parallel via Task tool:

Per reviewer prompt:
- Load rules from {config.rulesPath}
- Review assigned files
- Check against ALL rule categories (S, D, I, A, R, P)
- Use Review Question column from rules as checklist
- Output: findings table with severity (critical/high/medium/low)

Quorum consensus (2/3):

Merge findings across all 3 reviewers per part.

R5: Cross-Agent Re-check

For confirmed findings only:

• Task(e2e-automation-tester OR e2e-scenario-analyst): re-check confirmed findings
• Different agent type than reviewer = cross-domain verification
• Verify each finding is real and actionable
• May downgrade severity or mark as false positive

For unconfirmed findings:

• Include in report as "unconfirmed — single reviewer"
• Do NOT auto-fix unconfirmed findings

R6: Results Report

AskUserQuestion with full results:

Review Summary

Confirmed Findings

Unconfirmed Findings

Traceability Check

Options:

• "Fix confirmed issues" → spawn appropriate agents to fix, then re-review fixed files only
• "Export report" → write to .claude/e2e/reports/{date}_review.md
• "Done" → end

Mode: RULES

Create, update, and improve E2E testing rules.

L0: Prerequisite Check

Check .claude/agents/e2e-*.md count. If <3 -> "Run /brewcode:e2e setup first." STOP. Read .claude/e2e/config.json.

L1: Load Current Rules

1. Read base rules: ${CLAUDE_SKILL_DIR}/references/e2e-rules.md 2. Read project rules (if exists): .claude/rules/e2e-conventions.md 3. Check freshness: compare lastSetup date from config with current date 4. Present current state:

L2: Research + Analysis

If PROMPT provided -> use as research focus (e.g., "add async patterns", "Playwright best practices"). If empty -> general improvement based on detected stack.

Parallel: 1. Task(WebSearch): search best practices for {config.stack} E2E testing {PROMPT context}

• Search 2-3 queries, collect actionable rules

2. Task(e2e-architect or architect): analyze project patterns

• Look for recurring issues, anti-patterns, conventions specific to this project

L3: Rules Update

Merge findings into rules:

• Web-sourced rules -> marked with [WEB] tag
• Project-derived rules -> marked with [PROJECT] tag
• Existing rules preserved unless explicitly superseded

Task(e2e-reviewer or reviewer): validate updated rules

• Check for contradictions
• Check for duplicates
• Check actionability (each rule must be checkable)

L4: User Approval

AskUserQuestion with diff of changes:

Rules Diff

Options:

• "Apply all changes"
• "Select changes" -> AskUser per change
• "Cancel"

L5: Export (Optional)

AskUserQuestion: "Export updated rules to project?" Options:

• "Update .claude/rules/e2e-conventions.md" -> write/update with key rules (~20-30 lines)
• "Update base rules only" -> update e2e-rules.md in plugin (dev mode only)
• "Both"
• "Skip"

Update config.json lastSetup date.

Summary: rules added/modified/removed, sources breakdown.

Mode: SETUP

Setup E2E testing infrastructure: analyze project, create agents, generate rules.

S0: Prerequisites Check

S1: Existing Setup Check

Check .claude/agents/e2e-*.md count.

• If >=3 agents exist: AskUserQuestion: "E2E agents already configured ({N} found). What to do?"

Options: "Reconfigure from scratch" / "Keep and continue to rules" / "Cancel"

• If "Keep": skip to S5
• If "Cancel": STOP

S2: Project Analysis

Spawn 3-5 Explore agents in ONE message via Task tool:

Consolidate into analysis summary.

S3: User Confirmation

AskUserQuestion with analysis results + proposed agent roster:

Options: "Approve roster" / "Modify agents" / "Cancel"

S4: Agent Creation

Create agents via agent-creator in 2 batches:

Batch 1 (3 agents, parallel):

• e2e-architect
• e2e-scenario-analyst
• e2e-automation-tester

Each via: Task(subagent_type="brewcode:agent-creator") Include: agent-template from $BC_PLUGIN_ROOT/skills/e2e/references/agent-template.md, project analysis, colleague table. Agent description <= 100 chars (optimal ~80), single line, role + 2-3 triggers, no <example> blocks.

Batch 2 (2 agents, parallel):

• e2e-manual-tester
• e2e-reviewer (disallowedTools: Write, Edit, Bash)

After each batch: AskUser "Optimize agent prompts with text-optimizer?" If yes, run Skill(skill="brewtools:text-optimize") per agent file.

S5: Rules Generation

1. Task(subagent_type="brewcode:architect"): analyze project patterns + WebSearch best practices for detected stack 2. Merge findings with base rules from ${CLAUDE_SKILL_DIR}/references/e2e-rules.md 3. Task(subagent_type="brewcode:reviewer"): validate generated rules

S6: Config Persistence

Create .claude/e2e/config.json:

{
  "stack": "{detected}",
  "testFramework": "{detected}",
  "testSourceDir": "{detected or user-specified}",
  "scenarioDir": ".claude/e2e/scenarios",
  "agents": ["e2e-architect", "e2e-scenario-analyst", "e2e-automation-tester", "e2e-manual-tester", "e2e-reviewer"],
  "rulesPath": "plugin://brewcode/skills/e2e/references/e2e-rules.md",
  "lastSetup": "{ISO_DATE}"
}

Optionally generate .claude/rules/e2e-conventions.md (~20-30 lines) with key rules. AskUser: "Export key E2E rules to .claude/rules/?" Options: "Yes" / "No"

S7: Final Summary

AskUserQuestion with:

• Agents created (count + list)
• Rules status
• Config path
• Recommended next step: /brewcode:e2e create "your first flow"

Mode: STATUS

Read-only status check of E2E testing infrastructure.

T1: Agent Scan

Scan .claude/agents/e2e-*.md:

• Count agents found
• List each with: name, model (from frontmatter), last modified date

T2: Rules Scan

Scan for E2E rules:

• ${CLAUDE_SKILL_DIR}/references/e2e-rules.md — exists? rule count?
• .claude/rules/e2e-*.md — project-level rules? count?

T3: Config Check

Read .claude/e2e/config.json:

• If not found → report "Not configured. Run /brewcode:e2e setup."
• If found → extract: stack, testFramework, testSourceDir, scenarioDir, lastSetup

T4: Artifact Scan

Scan configured paths:

• Scenarios at {config.scenarioDir}/: count, list by domain/directory
• Per scenario: title (from frontmatter), status (draft/approved/automated), priority
• Tests at {config.testSourceDir}/: count E2E test files
• Pattern: files matching *E2E*, *e2e*, *EndToEnd* or in e2e subdirectory

T5: Output Status Table

# E2E Status

## Infrastructure
| Component | Status | Details |
|-----------|--------|---------|
| Agents | {N}/5 configured | {list} |
| Base rules | {exists/missing} | {N} rules |
| Project rules | {exists/missing} | {N} rules |
| Config | {exists/missing} | stack: {X}, framework: {Y} |

## Artifacts
| Type | Count | Location |
|------|-------|----------|
| Scenarios (draft) | {N} | {path} |
| Scenarios (approved) | {N} | {path} |
| Scenarios (automated) | {N} | {path} |
| Test files | {N} | {path} |

## Freshness
| Item | Last Updated |
|------|-------------|
| Config | {date} |
| Last scenario | {date} |
| Last test | {date} |

## Recommendations
- {if agents < 5}: "Missing agents. Run `/brewcode:e2e setup`."
- {if scenarios with status=approved but no test}: "Approved scenarios without tests. Run `/brewcode:e2e create`."
- {if config.lastSetup > 30 days}: "Setup is stale. Consider `/brewcode:e2e rules` to refresh."

No AskUserQuestion — purely informational output.

Mode: UPDATE

Update existing E2E scenarios and tests.

U0: Prerequisite Check

Check .claude/agents/e2e-*.md count. If <3 → "Run /brewcode:e2e setup first." STOP. Read .claude/e2e/config.json for stack, framework, paths.

U1: Scope Definition

If PROMPT is non-empty → use as update context. If PROMPT is empty → AskUserQuestion: "What to update?" Provide examples: "add negative scenarios to payment tests", "refactor auth steps to use new API", "update data layer for new schema"

U2: Find Existing Artifacts

1. Scan {config.scenarioDir}/ for existing scenarios 2. Scan {config.testSourceDir}/ for existing E2E tests 3. Match scope from U1 to found artifacts

Present to user:

AskUserQuestion: "Found {N} scenarios and {M} tests matching scope. Confirm update targets?"

U3: Apply Updates

Based on update type:

Spawn appropriate agent(s) via Task tool.

U4: Review Cycle (MAX_CYCLES=3)

Same pattern as CREATE mode C4/C7:

cycle = 0
while cycle < 3:
  1. Task(e2e-reviewer): validate changes against rules
  2. If no issues → break
  3. Task(different agent): re-check reviewer findings (cross-domain verification)
  4. Confirmed issues → Task(original agent): fix
  5. cycle++
if cycle == 3 and issues remain:
  AskUserQuestion: "Review cycle limit reached. {N} issues remain: {list}. Continue anyway?"

U5: Final Summary

AskUserQuestion with:

• Files modified (diff summary: added/changed/removed lines)
• Scenarios updated/added
• Tests updated/added
• Traceability check: every approved scenario still has >=1 test
• Next: /brewcode:e2e review recommended after significant changes