api-e2e-engineer

Validates implementations through staged API, E2E, and browser testing with confidence scoring.

2|1|Updated Mar 7, 2026
One-click install
npx skills add https://github.com/AutoByteus/autobyteus-agents --skill api-e2e-engineer-autobyteus
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: api-e2e-engineer
Source: https://github.com/AutoByteus/autobyteus-agents/tree/main/agent-teams/software-engineering-team/agents/api-e2e-engineer/skills/api-e2e-engineer
Command: npx skills add https://github.com/AutoByteus/autobyteus-agents --skill api-e2e-engineer-autobyteus

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Proving that a reviewed implementation actually meets approved requirements requires more than running existing tests. This Skill provides a staged, evidence-driven validation workflow that investigates current API/E2E coverage, maintains durable tests, executes repository and realistic system checks, and classifies residual risks and failures truthfully. ## Core Features & Use Cases - Coverage Investigation: Maps requirements and acceptance criteria to changed boundaries, inventories existing durable tests, and decides which to keep, update, replace, or remove. - Staged Execution with Confidence Scoring: Runs repository checks from narrowest to broadest scope, then scores validation confidence across seven mandatory categories with percentage anchors before deciding on broader validation. - Browser-Preferred Desktop Validation: Validates web-equivalent Electron/desktop behavior through the project's browser development path, reserving actual desktop execution for shell-specific last-resort evidence. - Use Case: After a code review passes on a new authentication flow, use this Skill to inventory existing E2E tests, add durable coverage for the changed session boundary, execute the suites, run a browser journey for the login flow, and produce an execution coverage report with a 95% confidence decision. ## Quick Start Use the api-e2e-engineer skill to validate the reviewed implementation against the approved requirements and produce the coverage investigation and execution report.

Frequently Asked Questions about api-e2e-engineer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I validate an implementation against approved requirements with E2E tests?▼

Start by writing a coverage investigation that maps requirements and acceptance criteria to changed boundaries, then execute repository checks from narrowest to broadest scope. Score confidence across mandatory categories and run broader browser or live validation only when it materially closes a confidence gap.

How to decide whether browser E2E testing is needed after API tests pass?▼

Browser validation is required when material uncertainty remains around user journeys, UI state, authentication, sessions, or frontend/backend contract integration. It is unnecessary when valid repository or API coverage already exercises the real changed boundary directly, and that reasoning must be recorded explicitly.

How should Electron desktop apps be tested without launching the full application?▼

Distinguish web-equivalent renderer behavior from shell-specific behavior like IPC bridges and window management. Validate web-equivalent behavior through the project's browser development path, and reserve actual desktop execution as a last resort for shell-specific behavior that cannot be proven otherwise.

When should existing tests be removed as stale or obsolete?▼

Remove a durable test only after recording the obsolete assertion, the upstream evidence showing the behavior was intentionally removed, and the replacement coverage or explicit no-replacement rationale. Never delete tests whose validity cannot be decided from approved artifacts; route those as requirement gaps instead.

What happens when E2E validation is blocked by missing dependencies?▼

On a blocked result, do not hand off to another team member or fabricate success. Preserve the reports, logs, and temporary evidence, then ask the user for the exact missing dependency, stating what was attempted and how work resumes.