e2e — manage E2E tests

Caution

Before using create, update, review, rules, or status — run /brewcode:e2e install first. The skill checks for at least 3 e2e-* agents and stops with a clear message if they are missing.

Tip

Review cycles are capped at 3 iterations (MAX_CYCLES=3). If issues remain after the third pass, the skill surfaces them to you via AskUserQuestion — you decide whether to continue or accept as-is.

Quick reference

Field	Value
Command	`/brewcode:e2e`
Arguments	`status \| install \| create [prompt] \| update [prompt] \| review [prompt] \| rules [prompt]`
No-arg default	`status` when 3 or more `e2e-*` agents exist, `install` otherwise
Rejected verbs	`uninstall`, `purge`, `upgrade`, `enable`, `disable` — exit 1, no fallback to `install`
Model	opus
Tools	Read, Write, Edit, Glob, Grep, Bash, Task, AskUserQuestion, Skill, WebSearch, WebFetch
Project rules file	`.claude/e2e/e2e-rules.md` (= `config.rulesPath`)

When to use

Goal	Command
First time — analyze project, create 5 agents, generate rules	`/brewcode:e2e install`
Write BDD scenarios + autotests for a new feature	`/brewcode:e2e create "checkout flow with Stripe"`
Sync existing scenarios after code changes	`/brewcode:e2e update "add negative auth scenarios"`
Multi-agent quorum review of scenario/test quality	`/brewcode:e2e review "focus on assertion quality"`
Refresh E2E rules (frameworks update, new patterns)	`/brewcode:e2e rules "add async messaging patterns"`
Read-only infrastructure health check	`/brewcode:e2e status`

Examples

Java / JUnit 5 — full install and first scenario:

/brewcode:e2e install
/brewcode:e2e create "user registration with email verification"
/brewcode:e2e review

Python / pytest — scenario then rules update:

/brewcode:e2e install
/brewcode:e2e create "checkout flow with Stripe payments"
/brewcode:e2e rules "add async messaging patterns"

JS / Playwright — create then patch:

/brewcode:e2e install
/brewcode:e2e create "login and dashboard navigation"
/brewcode:e2e update "add negative scenarios to auth"

Modes

Mode	What happens
`install`	3-5 Explore agents analyze the project; `agent-creator` spawns 5 specialized e2e agents in 2 batches; `e2e-architect` + WebSearch + `e2e-reviewer` generate rules; S6 writes `.claude/e2e/e2e-rules.md` and `.claude/e2e/config.json`
`create`	Prerequisite check → define scope (from prompt or AskUser) → `scenario-analyst` writes BDD → 3-round review cycle → user approves → `automation-tester` writes tests → compile smoke check
`update`	Locate existing artifacts → apply changes via the appropriate e2e agent → 3-round review cycle → summary with diff
`review`	Split scope into parts → 3 parallel reviewers per part → quorum (2/3 consensus) → cross-agent re-check of confirmed findings → report with fix proposals
`rules`	Load the live `.claude/e2e/e2e-rules.md` → WebSearch + `e2e-architect` analysis → `e2e-reviewer` validates the diff → rewrite that same file → optional condensed export to `.claude/rules/e2e-conventions.md`
`status`	Read-only: count `e2e-*` agents, show config (stack, framework, paths), artifact counts, freshness — compares the stamped `content_version` against the running skill’s `CONTENT_VERSION` (falls back to `version` vs `PLUGIN_VERSION` on a pre-`content_version` install)

Those six are the entire mode set. detect-mode.sh rejects uninstall, purge, upgrade, enable and disable with ERROR:e2e has no <verb> mode and exits 1; any other first word is taken as a free-form prompt for install. To remove the setup, delete .claude/agents/e2e-*.md and .claude/e2e/ by hand.

Rules live in your repo

install step S6 merges the plugin’s base rules with the [WEB] and [PROJECT] findings accepted in S5 and writes the result to .claude/e2e/e2e-rules.md. config.rulesPath points there, every generated e2e-* agent loads that path before doing anything, and rules mode reads and rewrites the same file — nothing is ever written back into the plugin.

Why a repo-relative path, not an absolute one

A generated .claude/agents/e2e-*.md is not plugin-owned: ${CLAUDE_PLUGIN_ROOT} is not substituted inside it and no *_PLUGIN_ROOT variable exists there, so a plugin path in an agent resolves to nothing. A resolved absolute cache path is no better — ~/.claude/plugins/cache/claude-brewcode/brewcode/<version>/… embeds the plugin version and dies at the next update. A repo-relative file survives plugin updates, uninstall, clone and CI. The agents stop with a clear message if it is missing, and so does rules mode: it never falls back to the plugin copy, because the agents cannot read it.

Flow

Parse arguments
detect-mode.sh extracts MODE and optional PROMPT from $ARGUMENTS. An unsupported verb prints ERROR: and exits 1; the skill reports that line verbatim and stops, never falling back to install.
Load mode reference
Reads references/mode-{MODE}.md plus the plugin’s baseline e2e-rules.md and e2e-architecture.md. Missing reference = hard stop with a clear message.
Prerequisite check
All modes except install and status verify at least 3 e2e-* agents exist in .claude/agents/. If not, the skill instructs you to run install first.
Discovery phase
3-5 Explore agents analyze the target area in parallel — source structure, existing tests, framework conventions, API contracts.
Core work — BDD to autotest
scenario-analyst produces Gherkin scenarios; automation-tester converts approved scenarios to framework-specific autotests; e2e-architect enforces the layered test architecture (Test Classes → Steps → Verification → Data → Support → Config).
Review cycle (max 3 rounds)
A different agent reviews every artifact against the rules. Confirmed findings (2/3 quorum in review mode) get cross-checked before fixing. After 3 rounds, unresolved issues surface to you.
User approval + summary
AskUserQuestion at every key decision point (scope, scenario list, final diff). Output: structured report with Detection → Results → Next Steps.

Delegation

Why the rule exists

A big task handed to one agent = an agent gone for an hour: you cannot observe it, cannot correct it, and it usually drifts off-target.

One subagent = ONE bounded unit — here, ONE feature’s tests or ONE review part: roughly 5 files, roughly 10 steps. “Write the whole suite” is never one task; it is split into N tasks fired in ONE message. In review mode, an oversized part is split before the reviewers go out, not handed whole to one agent.

Every spawn prompt carries six fields. A bare one-line task is never enough:

Field	Content
GOAL	the overall task and why it exists — the point beyond the file edit
ROLE	what this agent owns; what it must NOT touch
SCOPE	exact paths/commands in bounds + explicit out-of-bounds
CONTEXT	what is already done, by whom, what runs in parallel — trimmed to what THIS agent needs
CONSUMER	who or what uses the result next, and the shape it must fit
DONE	acceptance criteria + the exact report shape you want back

A feature agent is told that install already landed the framework, the e2e-* roster and e2e-rules.md (follow them, do not re-decide), that the BDD scenarios are approved, and that siblings own the shared page objects — reuse, never redefine. Its CONSUMER is the review cycle plus a green CI run, so it reports blockers instead of quarantining a test. The same brief lives in every references/mode-*.md file, so each mode’s own fan-out inherits it.

Every spawn brief also tells the agent, verbatim, to find the closest well-built existing test before writing a new one and take its principles — additive to the rules above, never instead.

Internals

Agents created by install

Agent	Model	Role
`e2e-architect`	opus	Defines patterns, creates rules and conventions
`e2e-scenario-analyst`	opus	Writes detailed BDD scenarios from system analysis
`e2e-automation-tester`	opus	Converts approved scenarios to autotests
`e2e-manual-tester`	sonnet	Verifies system via UI/API, finds exploratory bugs
`e2e-reviewer`	opus	READ-ONLY: reviews quality, rule compliance, coverage

Each one opens with a Rules Loading Protocol: read .claude/e2e/e2e-rules.md (project-relative), stop immediately if it is not there. Each also carries a permanent Etalon-first line in its Domain Instructions: before writing a test or page object, find the closest well-built existing one in this repo and take its principles — additive to e2e-rules.md and project conventions, never a replacement.

Every generated agent, plus config.json and e2e-rules.md, closes with a standard metadata stamp — doc_type, version, content_version, generated_by, last_updated. content_version is the field status and rules actually compare for staleness; earlier installs stamped version only, so a content change to this skill could never be detected as stale.

Test architecture layers (stack-agnostic)

Layer	Purpose	Example
Test Classes	Domain-specific, parameterized	`CheckoutE2ETest extends BasePaymentE2E`
Steps	Business-language reusable steps	`givenUserIsAuthorized("admin")`
Verification	Strict assertion steps	`thenOrderStatusIs(COMPLETED)`
Data	Test data generation via API	`createTestUser(role: "buyer")`
Support	Technical integration utilities	`KafkaSupport`, `DatabaseSupport`
Config	Environment settings	Credentials, endpoints, timeouts

Quorum rules (review mode)

Agreement	Classification
2-3 reviewers flag same issue	Confirmed finding — fixed
Only 1 reviewer flags	Unconfirmed — noted, not auto-fixed
All 3 agree clean	Clean

Error handling

Condition	Action
Unsupported verb (`uninstall`, `purge`, `upgrade`, `enable`, `disable`)	`detect-mode.sh` exits 1; report the `ERROR:` line verbatim and stop
`.claude/e2e/e2e-rules.md` missing	Stop — “Run `/brewcode:e2e install` first”. Never falls back to the plugin’s baseline copy
Agents missing (non-install/status)	Stop — “Run `/brewcode:e2e install` first”
Config missing (non-install)	Stop — “Run `/brewcode:e2e install` first”
Review cycle limit (3) reached	`AskUserQuestion` with remaining issues
Compilation fails after fix	Report to user, suggest manual intervention
Agent refuses task	Re-assign to colleague, max 2 retries

🤖

Updating plugins

Use /brewtools:plugin-update to check and update the brewcode plugin suite in one command. See the FAQ for details.