Integrated orchestrator that uses this project's Spec as the mandatory verification criterion and the ui-proto screen flow as an auxiliary criterion to automatically split/combine/execute/verify/supplement E2E scenarios.
Overview
peach-team-devIt is called at the point when development is finished. If the request is Spec/proto compliance verification, integrated flow, or pre-release verification, first perform E2E scope analysis. Depending on scenario splitting, suite composition, QA independence, and browser/data preparation complexity, single-agent / role-queue / agent-team select one of the following and handle the following in one pass.
peach-team-dev If it is called by an automatic chain and the handoff contract contains E2E preflight results, reuse the same tab/context. Do not ask the user again about an already prepared Chrome Beta/CDP/tab/session. If it is a standalone call, or there is no handoff, or the handoff is invalid, perform the existing mandatory gate and its own preflight.
- (if needed) E2E environment setup
- Load verification criteria (Spec mandatory + ui-proto optional)
- Automatic splitting of unit scenarios
- Automatic generation of integrated suite
- Execution + mismatch classification
- Automatic supplement/automatic delegation loop (Ralph loop 5/10 times)
For general verification, use only this skill. Existing peach-e2e-setup, peach-e2e-scenario, peach-e2e-suiteis retained only as Tier 2 for standalone step-by-step calls requiring single-scenario reruns, failure debugging, manual subdivision, and environment checks. This skill integrates those three steps while fixing the verification criterion to Spec and using ui-proto as an auxiliary criterionis the key differentiator.
If agent-team is appropriate but there is no actual team tool, report before starting that it will switch to a generic role-queue.
Development-verification delivery flow
peach-team-e2e는 peach-team-dev It is the subsequent delivery verification step. In usage experience, the two skills are one development-verification flow, but roles and contexts are separated for verification independence.
peach-team-dev 완료 산출
- 구현 코드
- TDD/lint/build 결과
- API-Store Contract Gate 결과
- TEST_ID 구현 상태 매핑
- E2E handoff contract
- E2E 잔여 리스크
peach-team-e2e 검증
- handoff contract 재사용
- 사용자 흐름 실행
- ui-proto/Spec 부합 판정
- 미스매치 분류
- 시나리오 오류 자동 보완
- TEST_ID 검증 상태 갱신
- 명확한 코드 문제는 peach-team-dev로 위임
This skill does not directly modify this project's code. Only code problems with clear Spec or ui-proto grounds are references/delegation-policy.md on the basis of peach-team-devdelegated to
Responsibility boundary between TDD and E2E
team-e2e는 User experience verificationis solely responsible. Logic branch verification is the responsibility of backend/store TDD.
| Area | Responsibility | Target |
|---|---|---|
| TDD (unit/integration) | Does the logic work as intended | Branch functions, DAO, data transformation. peach-gen-backend/peach-gen-storeHandled by the TDD gate |
| E2E (team-e2e) | Does it work exactly as the user sees it | Externally visible results of UI flow, interaction, and business rules |
Operational rules:
- If, within a unit scenario, direct DB access (both read and write), migration, or server/app restart is found, separate it into a fixture/suite Step or
peach-db-queryand then proceed. - In the ambiguous area of ui-proto/Spec, if it is judged that "this must be verified in TDD," do not drag it into the supplementation loop; instead, recommend adding TDD on the backend/store side.
- When classifying mismatches, "logic bugs" are not fixed directly by team-e2e; instead,
peach-team-devdelegate to. If the Spec/proto basis is clear and the safety conditions are met, automatically delegate without user confirmation. - In accordance with the completion criteria for each TEST_ID in the Spec, leave the verification evidence and residual risks in the completion report.
- QA verdict
APPROVED / CONDITIONAL / REJECTEDis the review verdict.
TEST_ID verification reporting rules:
| E2E result | Report status | Criteria |
|---|---|---|
| Not run | Before verification | Not yet E2E or equivalent verification |
| Partially passed | Partially verified | Only some scenarios passed or only part of the scope was verified |
| All passed | Verification complete | Confirm E2E/QA evidence for the relevant TEST_ID |
| Unable to verify | Unable to verify | Unable to verify due to environment/permission/data/Mock limitations |
| Blocked | Blocked | Progress blocked due to conflicting criteria, absence of execution conditions, or repeated failures |
Key differentiator — externalization of verification criteria
Existing E2E verified only "whether the code works." This skill verifies **"whether it matches the planning intent."**
| Verification item | Primary criteria | Secondary criteria |
|---|---|---|
| Screen layout, component placement | ui-proto screen | (if none, Spec) |
| User interaction flow | ui-proto screen | Spec |
| Business rules (validation, permissions, branching) | Spec | (if none, unable to verify → report) |
| Data accuracy (API response values) | Spec | (if none, unable to verify → report) |
| Error/exception handling | Spec | - |
Core principles: Spec is a mandatory criterion. If ui-proto exists, use it as a supplementary criterion for screens/flows, and if the criteria are ambiguous, report it.
If a requirement not in the Spec is discovered, do not modify the code; instead, classify it as DECISION_REQUIRED.
ui-proto is essentially a Mock, so it may not be 100% implemented. Only the visual flow + interaction sequence are based on ui-proto criteria; data accuracy is based on Spec criteria.
Inputs
/peach-team-e2e spec=<경로> [proto=<경로>] [handoff=<경로>] [model=opus|sonnet|haiku] [team=force|off]
# 옵션
# spec=<경로> 본 프로젝트 Spec 파일 경로 (필수)
# proto=<경로> ui-proto 태스크 폴더 절대 경로 (화면/흐름 기준)
# handoff=<경로> team-dev 자동 chain 또는 수동 재개 시 전달된 handoff contract
# model=... 서브에이전트 모델 override (기본 sonnet)
# team=force|off 실제 agent-team 강제 시도 / 실제 agent-team 비활성화
| Argument | Role |
|---|---|
spec |
Required. This project's docs/spec/...Spec file path |
proto |
Optional. Absolute path to the task folder in the ui-proto repository |
handoff |
Optional. peach-team-devhandoff contract generated by. In automatic chain calls, it may be passed as input context |
model |
Optional. Subagent model override |
team |
Optional override. The default is automatic analysis, and team=forceforces an attempt to create an actual agent-team, and team=offprohibits an actual agent-team |
proto If there is no argument, this project's docs/spec/...is used as the only verification criterion.
Spec-only mode indicates reliability as 중간. Business rules and data results can be verified, but since there is no ui-proto, visual/layout conformance verification is limited. If the Spec has 화면 흐름 요약, use it as the scenario splitting criterion.
Preconditions
peach-team-devas the state where this development is complete (or equivalent code exists)- This project's
docs/spec/{년}/{월}/...Spec file exists in - If the E2E environment is not set up, enter automatic setup (e2e/ folder, Chrome Beta CDP, etc.)
forced gate
./e2e.sh statusto check the tab list, and before the user specifies the execution tab, do not start the execution command (./e2e.sh run,agent-browser eval, tab switching).- 단,
peach-team-devis called as an automatic chain and the handoff contract hase2e_taband a valid preflight result, use those values. In this case, do not ask the user again about Chrome Beta/CDP/tab/session. - For tasks where Google login, OAuth, admin console, payment, or maintaining an existing Chrome Beta profile session is essential, proceed only up to scenario generation/analysis, and start actual execution after user confirmation.
agent-browserIf debugging is abnormal, do not bypass the browser at the OS level (open -a, another browser, another profile path).- For login/second-factor authentication, guide the user to complete authentication first in the fixed Chrome Beta profile.
Workflow
Reference Selection
| Situation | reference to read |
|---|---|
| Automatic team composition analysis | references/runtime-team-selection.md |
| Select Claude/Codex execution mode | references/runtime-adapter.md |
| E2E environment not set up | references/e2e-setup-흡수.md |
| Reuse team-dev automatic chain/handoff | ../peach-team-dev/references/dev-e2e-chain.md |
| Load Spec/proto verification criteria | references/검증기준-로드.md |
| Write/verify unit scenarios | references/scenario-dev-agent.md, references/scenario-qa-agent.md |
| Generate/run integration suite | references/suite-dev-agent.md, references/suite-qa-agent.md |
| Classify failure causes | references/미스매치-분류.md |
| Delegate code fixes | references/delegation-policy.md |
| QA judgment/completion report | references/qa-policy.md |
0. Input validation
Runtime mode selection
First, references/runtime-team-selection.md와 references/runtime-adapter.mdread and determine team composition and execution mode.
| Condition | Mode |
|---|---|
| Claude Code team tools available | Claude team mode |
| Codex subagent tools available | Codex subagent team mode |
| No subagent tools | generic role-queue |
| Claude Code but team features disabled | After guiding team mode activation, check whether generic role-queue is possible |
skills.shis an installation method and does not determine whether agent teams can be used in Codex. If the Codex runtime has spawn_agent, wait_agent, send_input subagent tools such as this, Codex subagent team mode can be used. Only when there are no subagent tools, run with generic role-queue.
If the user specifies team-e2e, 팀 e2e, 최종 검증, first perform E2E scope analysis. Depending on scenario splitting, suite composition, QA independence, and browser/data preparation complexity, single-agent / role-queue / agent-team Choose one of the following. agent-team is appropriate, but if not possible, report the reason for switching to generic role-queue or single-agent before starting.
Verify verification criteria availability
spec 인자 있음 + proto 인자 있음 → 표준 검증 모드 (Spec + ui-proto)
spec 인자 있음 + proto 인자 없음 → Spec-only 검증 모드
spec 인자 없음 + 단일 시나리오 재실행/디버깅 요청 → Tier 2 스킬 안내
spec 인자 없음 + 통합/부합 검증 요청 → 검증 중단, peach-gen-spec 또는 Spec 보강 안내
When entering Spec-only verification mode, leave the following in the completion report.
- Verification confidence:
중간 - Strong verification: business rules, data accuracy, errors/exceptions
- Weak verification: screen layout, component placement, detailed interaction flow
- Reinforcement recommendation: for a new complex screen,
peach-team-ui-protothen re-verify after writing
If there is no Spec, do not proceed with standard E2E based only on natural language criteria or proto. First, /peach-gen-speccreate a Spec with or reinforce the existing Spec, then re-enter.
Check Handoff contract
handoff If there is an argument or automatic chain input context, first verify the following.
| Item | Action |
|---|---|
spec_path |
Current spec if different from the argument, report as criteria conflict |
proto_path |
Current proto if different from the argument, prioritize user confirmation or Spec criteria |
base_url, api_url |
If different from the current execution target, re-confirm |
e2e_tab |
If a value exists and the CDP connection is valid, skip re-asking the tab specification gate |
browser_context |
Chrome Beta/CDP/login_session이 readyIf so, reuse preflight |
created_data, test_scope |
Reflect in scenario fixture and suite verification scope |
dev_result |
Use TDD/lint/build/Contract Gate results as the basis for failure classification |
If the handoff contract is absent or invalid, treat it as a standalone call and perform the existing mandatory gate.
Request to re-run E2E standalone without a Spec
When the user requests to re-run standalonean already-created E2E scenario or suite, do not add an exception mode to this skill. Guide to the following Tier 2 skill.
| Request | Guidance skill | Purpose |
|---|---|---|
| Unit scenario re-run/auto-fix | peach-e2e-scenario |
Run existing scenario, check selector/wait/syntax errors |
| Integration suite re-run | peach-e2e-suite |
Run existing suite md, check failed Steps and logs |
| Check failure cause in browser | peach-e2e-browse |
Explore screen state, DOM, console, network |
| E2E environment check | peach-e2e-setup |
Check e2e folder, Chrome Beta, CDP connection |
This path is for checking technical execution errors. To judge Spec compliance, business rules, permissions/state/data accuracy, re-enter peach-team-e2e spec=<경로>.
1. E2E environment setup (if needed)
e2e/, agent-browser, Chrome Beta, CDP connection. Do not auto-install tools; guide the user. For project-internal E2E infrastructure deployment and CDP connection procedures, follow references/e2e-setup-흡수.md.
handoff contract의 browser_contextIf valid, treat this step as reused and leave preflight_reused: truein the completion report.
2. Load verification criteria
The standard verification mode reads this project's Spec and the proto screen folder together and checks for discrepancies. Spec-only mode uses only this project's Spec as the basis, but reports the limits of visual verification and confidence 중간reports. For detailed procedures, follow references/검증기준-로드.md.
3. Team composition diagram
e2e-scenario-dev ──→ e2e-scenario-qa
│ │
└──→ e2e-suite-dev ──→ e2e-suite-qa
│
└──→ 실행 + 미스매치 분류
│
└──→ (분류 결과 기반 보완 루프)
| Role | Responsibility | references |
|---|---|---|
| e2e-scenario-dev | Automatic splitting + authoring of unit scenarios | references/scenario-dev-agent.md |
| e2e-scenario-qa | Unit scenario syntax + standalone execution verification | references/scenario-qa-agent.md |
| e2e-suite-dev | Unit scenario combination + suite md generation | references/suite-dev-agent.md |
| e2e-suite-qa | Suite execution + ui-proto/Spec compliance verification | references/suite-qa-agent.md |
The orchestrator (this skill) receives the results of each role and distributes them to the next stage.
4. Team creation and task registration
In Claude team mode, create the team as follows. Even in the Codex environment, if the agent-team from team-by-analysis results is appropriate and spawn_agent, wait_agent, send_input if there is a means to create/wait for/hand off subagents such as the same, separate e2e-scenario-dev, e2e-scenario-qa, e2e-suite-dev, and e2e-suite-qa into actual separate workers.
Standalone sequential execution is used when the analysis shows a small scale, when tools are unavailable, or when the user specifies team=off. The generic role-queue is a mode that executes the same order as a role checklist without actual team tools.
TeamCreate: team_name="[기능명]-e2e-team"
TaskCreate:
1. "단위 시나리오 분할 작성" (owner: e2e-scenario-dev)
2. "단위 시나리오 검증" (blockedBy: Task1, owner: e2e-scenario-qa)
3. "통합 suite 생성" (blockedBy: Task2, owner: e2e-suite-dev)
4. "통합 suite 실행 + 부합 검증" (blockedBy: Task3, owner: e2e-suite-qa)
5. Automatic splitting of unit scenarios
Split scenarios by user action unit based on the verification criteria. The criteria are single responsibility, indication of data dependencies, reusability, and failure isolation.
The SoT for the unit scenario authoring principles (single responsibility/self-preparation of initial data/independent execution/reusable/failure isolation) is peach-e2e-scenario/SKILL.md the "Unit Scenario Authoring Principles" section. team-e2e follows these principles when making splitting decisions. For agent workflow details after splitting, follow references/scenario-dev-agent.md와 references/scenario-qa-agent.md.
6. Automatic generation of integration suite
Combine unit scenarios by business flow unit to generate docs/e2e-suite/{한글카테고리}/{NN}-{스위트명}.md. For folder/numbering rules and the gradual migration policy, follow peach-e2e-suite/references/suite-scenario-파일구조.mdas the SoT.
When composing a suite, unit .js files are treated as reusable parts and are not modified directly in the suite. The SoT for the unit reuse principles is peach-e2e-suite/SKILL.md the "Unit Scenario Reuse Principles" section. For the suite structure and the validation point authoring agent workflow, follow references/suite-dev-agent.md와 references/suite-qa-agent.md.
7. Execution + mismatch classification
While sequentially executing the suite md, compare the result of each Step against the verification criteria.
On failure, classify into 5 categories.
| Classification | Cause | Handling |
|---|---|---|
| (a) Spec business rule violation | This project's code behaves differently from the Spec | When safety conditions are met, along with handoff context, peach-team-dev automatic delegation |
| (b) Differs from ui-proto screen flow | This project's screen is implemented differently from ui-proto | When safety conditions are met, along with handoff context, peach-team-dev mode=ui Automatic delegation |
| (c) Error in the scenario itself | Selector/logic error in the scenario code | Scenario fix (e2e-scenario auto-fix pattern) |
| (d) Suite configuration error | Step order, data transfer, fixture, verification point combination error | After fixing the suite md, rerun from the failure point |
| (e) Environment issue | Server, browser, tab, session, port, data preparation issue | manual_retry_countrecord as such and, if needed, escalate for user confirmation |
| (f) Ambiguous criteria | Insufficient or conflicting Spec/proto basis | User confirmation or criteria reinforcement |
Classification decision:
- Differs from the behavior specified in the verification criteria (ui-proto/Spec) → (a) or (b)
- Selector/wait/syntax/logic in the unit scenario file is wrong → (c)
- The unit scenario is correct but the suite's Step order, data transfer, fixture, or verification points are wrong → (d)
- Browser/server/session/port/fixture preparation issue → (e)
- Verification criteria are insufficient or conflicting → (f)
For details, see references/미스매치-분류.md reference.
8. Remediation loop (Ralph loop 5/10 times)
Depending on the classification result, (a)/(b), if the safety conditions are met, are automatically delegated with the handoff context to peach-team-devis automatically delegated, and (c) performs scenario auto-fix. (d) fixes the suite md and reruns from the failure point. (e) is recorded as a Manual Retry and rerun after environment correction, or escalated for user confirmation. (f) branches to user confirmation or peach-gen-spec reinforcement. Ralph Loop and Manual Retry are recorded separately. After QA REJECTED, artifact fixes and re-verification are recorded as Ralph Loop, and reruns after correcting the environment such as browser/server/session/port are recorded as Manual Retry. Automatic delegation conditions are references/delegation-policy.md, and the iteration cap and completion report criteria follow references/qa-policy.md.
QA decision handling
QA는 APPROVED / CONDITIONAL / REJECTED It is judged in 3 stages. For the meaning of the decision, remediation loop, and completion report fields, follow references/qa-policy.md.
Completion
After all verifications pass, collect the unit scenario execution results, integration suite path, mismatch history, and verification criteria compliance results.
SendMessage(shutdown_request) → 모든 팀원에게
TeamDelete → 팀 정리
In the generic role-queue, instead of the above team cleanup step, leave the execution history and artifact paths in the completion report.
Completion report format
The completion report follows the fields of references/qa-policy.md. If it is an automatic chain call, chain_source, handoff_used, preflight_reused, e2e_result, failure_classificationmust be included. Spec-only mode must include verification limitations and post-reinforcement recommendations.
Examples
# === 표준 모드 (proto 사용) ===
# proto 경로로 검증 기준 자동 로드
/peach-team-e2e spec=docs/spec/2026/05/example.md proto=<PROTO_REPO>/src/modules-task/2604/260427-<initial>-goods
# opus 모델로 서브에이전트 실행
/peach-team-e2e spec=docs/spec/2026/05/example.md proto=<PROTO_REPO>/.../260427-<initial>-goods model=opus
# === Spec-only 모드 ===
# proto 없이 docs/spec/... 만 사용
/peach-team-e2e spec=docs/spec/2026/05/example.md
Tool role division
| Purpose | Tool |
|---|---|
| Unit scenario execution | ./e2e.sh run |
| Verification point check | agent-browser eval |
| Code verification | Read, Grep |
| DB verification | peach-db-query or direct SELECT |
| iframe verification | ./e2e/pwc.sh eval (fallback) |
Related skills
peach-team-dev— main development (preceding step of this skill)peach-e2e-setup— E2E environment standalone setup (Tier 2)peach-e2e-scenario— Write/run/rerun/auto-fix unit scenarios standalone (Tier 2)peach-e2e-suite— Generate/run/rerun integrated suite md standalone (Tier 2)peach-e2e-browse— Browser navigation/debugging (assistive during verification)
This skill shares the same guide pattern as the above 4 e2e-* skills shares the same guide pattern. The true SoT is the scenario code pattern (
peach-e2e-scenario/references/) and the e2e infrastructure code (peach-e2e-setup/references/). Tier 2 skills and this skill use the same pattern through two invocation methods.browse/scenario/suiteis not a merge target but a connection target. Since lifecycles differ, Tier 2 standalone invocability is maintained.
| skill | lifecycle |
|---|---|
peach-e2e-browse |
One-off exploration/debugging |
peach-e2e-scenario |
Repeatable unit regression verification |
peach-e2e-suite |
Business flow unit integration verification |
peach-team-e2e |
Final conformance verification against Spec/ui-proto |
Core principles
- Verification criteria are externalized to Spec mandatory + ui-proto assistive(going beyond code behavior verification to verify conformance with planning intent)
- For business/data/permissions/state/exceptions, Spec is primary; for screens/flows, if proto exists, use proto as an assistive criterion
- Mismatches are classified into 5 categories (Spec violation / proto mismatch / scenario error / suite configuration error / ambiguous criteria)
- Code fixes are automatically delegated to
peach-team-devwhen safety conditions are met, and only ambiguous criteria are reported to the user - Scenario fixes use 3 auto-fixes (peach-e2e-scenario pattern)
- For suite configuration errors, modify the suite md and rerun from the failure point
- Ralph loop cap 5/10 times (based on change size)
- If verification criteria are absent or ambiguous, report to the user, forced progression prohibited