Multi Agent E2e Validation

Name: Multi Agent E2e Validation
Author: terrylica

terrylica/cc-skills

120 installs
62 repo stars
Updated August 3, 2026
terrylica/cc-skills

Use multi-agent-e2e-validation for development tasks

About

multi-agent-e2e-validation: A skill for development. This provides functionality for development workflows.

multi-agent-e2e-validation

Multi Agent E2e Validation by the numbers

120 all-time installs (skills.sh)
+1 installs in the week ending Jul 27, 2026 (Skillselion tracking)
Ranked #2,832 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
Data as of Aug 4, 2026 (Skillselion catalog sync)

npx skills add https://github.com/terrylica/cc-skills --skill multi-agent-e2e-validation

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/terrylica/cc-skills/multi-agent-e2e-validation.svg)](https://skillselion.com/skills/terrylica/cc-skills/multi-agent-e2e-validation)

Installs	120
repo stars	★ 62
Last updated	August 3, 2026
Repository	terrylica/cc-skills ↗

What it does

Use multi-agent-e2e-validation for development tasks

Files

SKILL.mdMarkdownGitHub ↗

Multi-Agent E2E Validation

Self-Evolving Skill: This skill improves through use. If instructions are wrong, parameters drifted, or a workaround was needed — fix this file immediately, don't defer. Only update for real, reproducible issues.

Overview

Prescriptive workflow for spawning parallel validation agents to comprehensively test database refactors. Successfully identified 5 critical bugs (100% system failure rate) in QuestDB migration that would have shipped in production.

When to Use This Skill

Use this skill when:

Database refactors (e.g., v3.x file-based → v4.x QuestDB)
Schema migrations requiring validation
Bulk data ingestion pipeline testing
System migrations with multiple validation layers
Pre-release validation for database-centric systems

Key outcomes:

Parallel agent execution for comprehensive coverage
Structured validation reporting (VALIDATION_FINDINGS.md)
Bug discovery with severity classification (Critical/Medium/Low)
Release readiness assessment

Core Methodology

1. Validation Architecture (3-Layer Model)

Layer 1: Environment Setup

Container orchestration (Colima/Docker)
Database deployment and schema application
Connectivity validation (ILP, PostgreSQL, HTTP ports)
Configuration file creation and validation

Layer 2: Data Flow Validation

Bulk ingestion testing (CloudFront → QuestDB)
Performance benchmarking against SLOs
Multi-month data ingestion
Deduplication testing (re-ingestion scenarios)
Type conversion validation (FLOAT→LONG casts)

Layer 3: Query Interface Validation

High-level query methods (get_latest, get_range, execute_sql)
Edge cases (limit=1, cross-month boundaries)
Error handling (invalid symbols, dates, parameters)
Gap detection SQL compatibility

2. Agent Orchestration Pattern

Sequential vs Parallel Execution:

Agent 1 (Environment) → [SEQUENTIAL - prerequisite]
  ↓
Agent 2 (Bulk Loader) → [PARALLEL with Agent 3]
Agent 3 (Query Interface) → [PARALLEL with Agent 2]

Dependency Rule: Environment validation must pass before data flow/query validation

Dynamic Todo Management:

Start with high-level plan (ADR-defined phases)
Prune completed agents from todo list
Grow todo list when bugs discovered (e.g., Bug #5 found by Agent 3)
Update VALIDATION_FINDINGS.md incrementally

3. Validation Script Structure

Each agent produces:

1. Test Script (e.g., test_bulk_loader.py)

5+ test functions with clear pass/fail criteria
Structured output (test name, result, details)
Summary report at end

2. Artifacts (logs, config files, evidence) 3. Findings Report (bugs, severity, fix proposals)

Example Test Structure:

def test_feature(conn):
    """Test 1: Feature description"""
    print("=" * 80)
    print("TEST 1: Feature description")
    print("=" * 80)

    results = {}

    # Test 1a: Subtest name
    print("\n1a. Testing subtest:")
    result_1a = perform_test()
    print(f"   Result: {result_1a}")
    results["subtest_1a"] = result_1a == expected_1a

    # Summary
    print("\n" + "-" * 80)
    all_passed = all(results.values())
    print(f"Test 1 Results: {'✓ PASS' if all_passed else '✗ FAIL'}")
    for test_name, passed in results.items():
        print(f"  - {test_name}: {'✓' if passed else '✗'}")

    return {"success": all_passed, "details": results}

4. Bug Classification and Tracking

Severity Levels:

🔴 Critical: 100% system failure (e.g., API mismatch, timestamp corruption)
🟡 Medium: Degraded functionality (e.g., below SLO performance)
🟢 Low: Minor issues, edge cases

Bug Report Format:

#### Bug N: Descriptive Name (**SEVERITY** - Status)

**Location**: `file/path.py:line`

**Issue**: One-sentence description

**Impact**: Quantified impact (e.g., "100% ingestion failure")

**Root Cause**: Technical explanation

**Fix Applied**: Code changes with before/after

**Verification**: Test results proving fix

**Status**: ✅ FIXED / ⚠️ PARTIAL / ❌ OPEN

5. Release Readiness Decision Framework

Go/No-Go Criteria:

BLOCKER = Any Critical bug unfixed
SHIP = All Critical bugs fixed + (Medium bugs acceptable OR fixed)
DEFER = >3 Medium bugs unfixed OR any High-severity bug

Example Decision:

5 Critical bugs found → all fixed ✅
1 Medium bug (performance 55% below SLO) → acceptable ✅
Verdict: RELEASE READY

Workflow: Step-by-Step

Step 1: Create Validation Plan (ADR-Driven)

Input: ADR document (e.g., ADR-0002 QuestDB Refactor) Output: Validation plan with 3-7 agents

Plan Structure:

## Validation Agents

### Agent 1: Environment Setup

- Deploy QuestDB via Docker
- Apply schema.sql
- Validate connectivity (ILP, PG, HTTP)
- Create .env configuration

### Agent 2: Bulk Loader Validation

- Test CloudFront → QuestDB ingestion
- Benchmark performance (target: >100K rows/sec)
- Validate deduplication (re-ingestion test)
- Multi-month ingestion test

### Agent 3: Query Interface Validation

- Test get_latest() with various limits
- Test get_range() with date boundaries
- Test execute_sql() with parameterized queries
- Test detect_gaps() SQL compatibility
- Test error handling (invalid inputs)

Step 2: Execute Agent 1 (Environment)

Directory Structure:

tmp/e2e-validation/
  agent-1-env/
    test_environment_setup.py
    questdb.log
    config.env
    schema-check.txt

Validation Checklist:

✅ Container running
✅ Ports accessible (9009 ILP, 8812 PG, 9000 HTTP)
✅ Schema applied without errors
✅ .env file created

Step 3: Execute Agents 2-3 in Parallel

Agent 2: Bulk Loader

tmp/e2e-validation/
  agent-2-bulk/
    test_bulk_loader.py
    ingestion_benchmark.txt
    deduplication_test.txt

Agent 3: Query Interface

tmp/e2e-validation/
  agent-3-query/
    test_query_interface.py
    gap_detection_test.txt

Execution:

# Terminal 1
cd tmp/e2e-validation/agent-2-bulk
uv run python test_bulk_loader.py

# Terminal 2
cd tmp/e2e-validation/agent-3-query
uv run python test_query_interface.py

Step 4: Document Findings in VALIDATION_FINDINGS.md

Template:

# E2E Validation Findings Report

**Validation ID**: ADR-XXXX
**Branch**: feat/database-refactor
**Date**: YYYY-MM-DD
**Target Release**: vX.Y.Z
**Status**: [BLOCKED / READY / IN_PROGRESS]

## Executive Summary

E2E validation discovered **N critical bugs** that would have caused [impact]:

| Finding | Severity | Status | Impact       | Agent   |
| ------- | -------- | ------ | ------------ | ------- |
| Bug 1   | Critical | Fixed  | 100% failure | Agent 2 |

**Recommendation**: [RELEASE READY / BLOCKED / DEFER]

## Agent 1: Environment Setup - [STATUS]

...

## Agent 2: [Name] - [STATUS]

...

Step 5: Iterate on Fixes

For each bug:

1. Document in VALIDATION_FINDINGS.md with 🔴/🟡/🟢 severity 2. Apply fix to source code 3. Re-run failing test 4. Update bug status to ✅ FIXED 5. Commit with semantic message (e.g., fix: correct timestamp parsing in CSV ingestion)

Example Fix Commit:

git add src/gapless_crypto_clickhouse/collectors/questdb_bulk_loader.py
git commit -m "fix: prevent pandas from treating first CSV column as index

BREAKING CHANGE: All timestamps were defaulting to epoch 0 (1970-01)
due to pandas read_csv() auto-indexing. Added index_col=False to
preserve first column as data.

Fixes #ABC-123"

Step 6: Final Validation and Release Decision

Run all tests:

/usr/bin/env bash << 'SKILL_SCRIPT_EOF'
cd tmp/e2e-validation
for agent in agent-*; do
    echo "=== Running $agent ==="
    cd $agent
    uv run python test_*.py
    cd ..
done
SKILL_SCRIPT_EOF

Update VALIDATION_FINDINGS.md status:

Count Critical bugs: X fixed, Y open
Count Medium bugs: X fixed, Y open
Apply decision framework
Update Status field to ✅ RELEASE READY or ❌ BLOCKED

Real-World Example: QuestDB Refactor Validation

Context: Migrating from file-based storage (v3.x) to QuestDB (v4.0.0)

Bugs Found:

1. 🔴 Sender API mismatch - Used non-existent Sender.from_uri() instead of Sender.from_conf() 2. 🔴 Type conversion - number_of_trades sent as FLOAT, schema expects LONG 3. 🔴 Timestamp parsing - pandas treating first column as index → epoch 0 timestamps 4. 🔴 Deduplication - WAL mode doesn't provide UPSERT semantics (needed DEDUP ENABLE UPSERT KEYS) 5. 🔴 SQL incompatibility - detect_gaps() used nested window functions (QuestDB unsupported)

Impact: Without this validation, v4.0.0 would ship with 100% data corruption and 100% ingestion failure

Outcome: All 5 bugs fixed, system validated, v4.0.0 released successfully

Common Pitfalls

1. Skipping Environment Validation

❌ Bad: Assume Docker/database is working, jump to data ingestion tests ✅ Good: Agent 1 validates environment first, catches port conflicts, schema errors early

2. Serial Agent Execution

❌ Bad: Run Agent 2, wait for completion, then run Agent 3 ✅ Good: Run Agent 2 & 3 in parallel (no dependency between them)

3. Manual Test Reporting

❌ Bad: Copy/paste test output into Slack/email ✅ Good: Structured VALIDATION_FINDINGS.md with severity, status, fix tracking

4. Ignoring Medium Bugs

❌ Bad: "Performance is 55% below SLO, but we'll fix it later" ✅ Good: Document in VALIDATION_FINDINGS.md, make explicit go/no-go decision

5. No Re-validation After Fixes

❌ Bad: Apply fix, assume it works, move on ✅ Good: Re-run failing test, update status in VALIDATION_FINDINGS.md

Resources

scripts/

Not applicable - validation scripts are project-specific (stored in tmp/e2e-validation/)

references/

example_validation_findings.md - Complete VALIDATION_FINDINGS.md template
agent_test_template.py - Template for creating validation test scripts
bug_severity_classification.md - Detailed severity criteria and examples

assets/

Not applicable - validation artifacts are project-specific

---

Troubleshooting

Issue	Cause	Solution
Container not starting	Colima/Docker not running	Run `colima start` before Agent 1
Port conflicts	Ports already in use	Stop conflicting containers or use different ports
Schema application fails	Invalid SQL syntax	Check schema.sql for database-specific compatibility
Agent 2/3 fail without Agent 1	Environment not validated	Ensure Agent 1 completes before starting Agent 2/3
Test script import errors	Missing dependencies	Run `uv pip install` in agent directory
Bug status not updating	VALIDATION_FINDINGS.md stale	Manually refresh status after each fix
Parallel agents interference	Shared resources conflict	Ensure agents use isolated directories
Decision unclear	Severity mixed Critical/Medium	Apply Go/No-Go criteria strictly per documentation

Post-Execution Reflection

After this skill completes, reflect before closing the task:

0. Locate yourself. — Find this SKILL.md's canonical path before editing. 1. What failed? — Fix the instruction that caused it. 2. What worked better than expected? — Promote to recommended practice. 3. What drifted? — Fix any script, reference, or dependency that no longer matches reality. 4. Log it. — Evolution-log entry with trigger, fix, and evidence.

Do NOT defer. The next invocation inherits whatever you leave behind.

#!/usr/bin/env python3
# ruff: noqa: F821
"""
Agent N: [Agent Name] Validation

Tests [brief description of what this agent validates]:
1. [Test 1 name]
2. [Test 2 name]
3. [Test 3 name]
4. [Test 4 name]
5. [Test 5 name]
"""

import sys
from pathlib import Path

# Add src to path for imports
project_root = Path(__file__).parent.parent.parent.parent
sys.path.insert(0, str(project_root / "src"))

# ruff: noqa: E402, F401
from your_module import YourClass  # Replace with actual imports


def test_feature_1(connection_or_resource):
    """Test 1: [Feature name]"""
    print("=" * 80)
    print("TEST 1: [Feature name]")
    print("=" * 80)

    results = {}

    # Test 1a: [Subtest name]
    print("\n1a. Testing [specific aspect]:")
    result = perform_test_1a()
    print(f"   Result: {result}")
    print(f"   Expected: {expected_value}")
    results["subtest_1a"] = result == expected_value

    # Test 1b: [Another subtest]
    print("\n1b. Testing [another aspect]:")
    result = perform_test_1b()
    print(f"   Result: {result}")
    results["subtest_1b"] = validate_result(result)

    # Summary
    print("\n" + "-" * 80)
    all_passed = all(results.values())
    print(f"Test 1 Results: {'✓ PASS' if all_passed else '✗ FAIL'}")
    for test_name, passed in results.items():
        print(f"  - {test_name}: {'✓' if passed else '✗'}")

    return {"success": all_passed, "details": results}


def test_feature_2(connection_or_resource):
    """Test 2: [Another feature name]"""
    print("\n" + "=" * 80)
    print("TEST 2: [Another feature name]")
    print("=" * 80)

    results = {}

    # Test 2a: [Subtest name]
    print("\n2a. Testing [specific aspect]:")
    try:
        result = perform_test_2a()
        print(f"   ✓ Success: {result}")
        results["subtest_2a"] = True
    except Exception as e:
        print(f"   ✗ Failed: {e}")
        results["subtest_2a"] = False

    # Summary
    print("\n" + "-" * 80)
    all_passed = all(results.values())
    print(f"Test 2 Results: {'✓ PASS' if all_passed else '✗ FAIL'}")
    for test_name, passed in results.items():
        print(f"  - {test_name}: {'✓' if passed else '✗'}")

    return {"success": all_passed, "details": results}


def test_error_handling(connection_or_resource):
    """Test 3: Error handling (invalid inputs)"""
    print("\n" + "=" * 80)
    print("TEST 3: Error handling (invalid inputs)")
    print("=" * 80)

    results = {}

    # Test 3a: Invalid input type
    print("\n3a. Testing invalid input:")
    try:
        result = perform_operation_with_invalid_input()
        print(f"   ✗ Should have raised error but returned: {result}")
        results["invalid_input"] = False
    except ValueError as e:
        print(f"   ✓ Correctly raised ValueError: {e}")
        results["invalid_input"] = True
    except Exception as e:
        print(f"   ? Unexpected error type: {type(e).__name__}: {e}")
        results["invalid_input"] = False

    # Summary
    print("\n" + "-" * 80)
    all_passed = all(results.values())
    print(f"Test 3 Results: {'✓ PASS' if all_passed else '✗ FAIL'}")
    for test_name, passed in results.items():
        print(f"  - {test_name}: {'✓' if passed else '✗'}")

    return {"success": all_passed, "details": results}


def main():
    """Run all validation tests"""
    print("\n" + "=" * 80)
    print("AGENT N: [AGENT NAME] VALIDATION")
    print("=" * 80)

    all_results = {}

    try:
        # Initialize connection or resource
        connection = initialize_connection()

        # Test 1: [Feature 1]
        all_results["test_1_feature_1"] = test_feature_1(connection)

        # Test 2: [Feature 2]
        all_results["test_2_feature_2"] = test_feature_2(connection)

        # Test 3: Error handling
        all_results["test_3_error_handling"] = test_error_handling(connection)

        # Summary
        print("\n" + "=" * 80)
        print("VALIDATION SUMMARY")
        print("=" * 80)

        all_passed = all(result["success"] for result in all_results.values())

        for test_name, test_result in all_results.items():
            status = "✓ PASS" if test_result["success"] else "✗ FAIL"
            print(f"  {test_name}: {status}")

        print(f"\n{'✓ ALL TESTS PASSED' if all_passed else '✗ SOME TESTS FAILED'}")
        print("=" * 80)

        return 0 if all_passed else 1

    except Exception as e:
        print(f"\n✗ FATAL ERROR: {e}")
        import traceback

        traceback.print_exc()
        return 1


if __name__ == "__main__":
    sys.exit(main())

Skill: Multi-Agent E2E Validation

Bug Severity Classification

Severity Levels

🔴 Critical

Definition: Bugs that cause 100% system failure or complete data corruption

Criteria:

System cannot start or deploy
100% of operations fail
Complete data loss or corruption
Security vulnerability allowing unauthorized access
API incompatibility preventing all usage

Examples:

Using non-existent API method (Sender.from_uri() doesn't exist)
All timestamps defaulting to epoch 0 (100% data corruption)
Type mismatch causing broken pipe (FLOAT→LONG cast failure)
SQL syntax incompatibility (nested window functions crash)
Schema application failure preventing database initialization

Go/No-Go Impact: BLOCKER - Cannot ship with any unfixed Critical bugs

Time to Fix: Immediate (must fix before release)

---

🟡 Medium

Definition: Bugs that cause degraded functionality or below-SLO performance

Criteria:

System works but performs significantly below SLO (>30% deviation)
Partial feature failure (some cases work, some don't)
Non-critical data quality issues
Degraded user experience but system usable
Workarounds available but not ideal

Examples:

Performance 55% below SLO target (47K vs 100K rows/sec)
Query works but 30% slower than expected
Gap detection works but misses edge cases
Partial test failures due to data quality (not code bugs)
Deduplication requires manual intervention

Go/No-Go Impact: CONDITIONAL - Can ship if ≤3 Medium bugs OR explicitly accepted

Time to Fix: Before next minor version (unless explicitly deferred)

---

🟢 Low

Definition: Minor issues, edge cases, or cosmetic problems

Criteria:

Rare edge cases that don't affect normal operation
Cosmetic issues (formatting, logging)
Non-essential features with minor bugs
Documentation gaps or typos
Minor performance variations (<10% deviation)

Examples:

Error message formatting inconsistent
Debug logging too verbose
Edge case timezone handling issue
Non-critical validation missing
Minor test flakiness

Go/No-Go Impact: NON-BLOCKING - Track for future release

Time to Fix: Next patch or minor version

---

Classification Decision Tree

Does the bug prevent system startup or deployment?
├─ YES → 🔴 Critical
└─ NO → Continue

Does the bug cause 100% failure of a core feature?
├─ YES → 🔴 Critical
└─ NO → Continue

Does the bug cause complete data corruption?
├─ YES → 🔴 Critical
└─ NO → Continue

Does the bug cause >30% performance degradation below SLO?
├─ YES → 🟡 Medium
└─ NO → Continue

Does the bug affect normal user workflows?
├─ YES → 🟡 Medium
└─ NO → Continue

Does the bug only affect rare edge cases or cosmetics?
├─ YES → 🟢 Low
└─ NO → Re-evaluate (might be Medium)

---

Real-World Examples from QuestDB Refactor

🔴 Critical Bug: Sender API Mismatch

Impact: 100% ingestion failure - system completely non-functional Evidence: AttributeError: type object 'Sender' has no attribute 'from_uri' Why Critical: Zero functionality - cannot ingest any data Fix Priority: Immediate blocker

🔴 Critical Bug: Timestamp Parsing

Impact: 100% data corruption - all timestamps at epoch 0 (1970-01-01) Evidence: Database query shows 70,784 rows in 1970-01 instead of 2024-01 Why Critical: Data completely unusable for time-series analysis Fix Priority: Immediate blocker

🔴 Critical Bug: Deduplication Design Flaw

Impact: Zero-gap guarantee violated - duplicates created on re-ingestion Evidence: 44,640 duplicate rows created (expected 0) Why Critical: Core correctness SLO violated Fix Priority: Immediate blocker

🟡 Medium Bug: Performance Below SLO

Impact: 47K rows/sec achieved vs 100K target (53% below SLO) Evidence: Benchmark shows consistent 47K rows/sec across multiple runs Why Medium: System works, but slower than designed Fix Priority: Deferred (acceptable for v4.0.0, address in v4.1.0)

🟢 Low Bug: Test Timezone Comparison

Impact: Test fails with tz-naive vs tz-aware comparison Evidence: TypeError in test code (not production code) Why Low: Affects test only, not production functionality Fix Priority: Fix during test development

---

Severity Assessment Checklist

When triaging a new bug, ask:

[ ] Can the system start/deploy? (No → Critical)
[ ] Does any core feature work? (No → Critical)
[ ] Is data integrity compromised? (Yes → Critical)
[ ] Can users accomplish their goals? (No → Critical, Partially → Medium)
[ ] Is performance >30% below SLO? (Yes → Medium)
[ ] Is there a reasonable workaround? (No → increase severity)
[ ] Does this affect production code? (No → Low)
[ ] Is this an edge case? (Yes → Low)

---

Dispute Resolution

If severity classification is unclear:

1. Default to Higher Severity: When in doubt, escalate (Low→Medium, Medium→Critical) 2. Get Second Opinion: Ask another engineer or team lead 3. Run Go/No-Go Test: If unsure whether to ship, assume Critical and investigate 4. Document Rationale: Explain why a bug was downgraded (e.g., "Downgraded to Medium because workaround exists")

Example dispute:

Initial Classification: 🔴 Critical (performance 55% below SLO)
Disputed Classification: 🟡 Medium (system works, just slower)
Resolution: 🟡 Medium + explicit go/no-go decision documented
Rationale: "System functional, deduplication fixed restores correctness SLO, performance can be addressed in v4.1.0"

Skill: Multi-Agent E2E Validation

E2E Validation Findings Report

Validation ID: ADR-XXXX Branch: feat/your-feature-branch Date: YYYY-MM-DD Target Release: vX.Y.Z Status: [⏳ IN_PROGRESS / ✅ RELEASE_READY / ❌ BLOCKED]

---

Executive Summary

E2E validation of [feature/refactor name] discovered N critical bugs that would have caused [impact summary]:

Finding	Severity	Status	Impact	Agent
Bug 1 Name	🔴 Critical	✅ Fixed	100% [specific failure]	Agent X
Bug 2 Name	🔴 Critical	✅ Fixed	Data corruption	Agent Y
Bug 3 Name	🟡 Medium	⚠️ Partial	Below SLO performance	Agent Z

Recommendation: [RELEASE_READY / BLOCKED / DEFERRED]

Rationale: [Explain go/no-go decision based on bugs found and fixed]

---

Agent 1: [Environment Setup] - [✅ PASS / ❌ FAIL]

Validation: [Brief description of what this agent validates]

Results

✅ [Success criterion 1]
✅ [Success criterion 2]
❌ [Failure criterion] (if applicable)

Artifacts

tmp/e2e-validation/agent-1-name/artifact1.log
tmp/e2e-validation/agent-1-name/artifact2.txt

Verdict: [Environment setup fully operational / Issues found]

---

Agent 2: [Data Flow] - [✅ PASS / ❌ FAIL]

Validation: [Brief description of what this agent validates]

Critical Bugs Found & Fixed

Bug 1: [Descriptive Name] (CRITICAL - [Status])

Location: src/path/to/file.py:line_number

Issue: [One-sentence description of the problem]

Evidence:

[Error message, stack trace, or query results demonstrating the bug]

Impact: [Quantified impact - e.g., "100% ingestion failure", "Data corruption affecting X% of records"]

Root Cause: [Technical explanation of why this happened]

Fix Applied:

# BROKEN (before fix)
old_code_here()

# FIXED (after fix)
new_code_here()

Verification:

[Test results showing the fix works]
Test: [Test name]
Expected: [Expected outcome]
Actual: [Actual outcome] ✅

Status: [✅ FIXED / ⚠️ PARTIAL / ❌ OPEN]

---

Bug 2: [Descriptive Name] (MEDIUM - [Status])

[Same structure as Bug 1]

---

Test Results Summary

Test	Result	Details
Test 1: [Name]	✅ PASS	[Brief description of results]
Test 2: [Name]	❌ FAIL	[Brief description of failure]
Test 3: [Name]	⚠️ PARTIAL	[Brief description of partial success]

Overall: X/Y PASS, Z/Y FAIL (M blockers)

---

Agent 3: [Query Interface] - [✅ PASS / ❌ FAIL]

Validation: [Brief description of what this agent validates]

Test Results

Test	Result	Details
Test 1: [Method name]	✅ PASS	[Brief results]
Test 2: [Method name]	✅ PASS	[Brief results]
Test 3: [Method name]	⚠️ PARTIAL	[Brief results - explain why partial]

Critical Discovery: [Any new bugs found, or confirmation that interfaces work]

Verdict: [Query interface functional / Issues found]

---

Validation Logs

Agent 1 Logs

See: tmp/e2e-validation/agent-1-name/test_output.log

Agent 2 Logs

See: tmp/e2e-validation/agent-2-name/test_output.log

Agent 3 Logs

See: tmp/e2e-validation/agent-3-name/test_output.log

---

Release Decision Matrix

Critical Bugs: X found, Y fixed, Z open Medium Bugs: A found, B fixed, C open Low Bugs: D found, E fixed, F open

Decision Criteria:

BLOCKER = Any Critical bug unfixed
SHIP = All Critical bugs fixed + (Medium bugs acceptable OR fixed)
DEFER = >3 Medium bugs unfixed OR any High-severity bug

Status: [✅ RELEASE_READY / ❌ BLOCKED / ⏸️ DEFERRED]

Next Steps: 1. [Action item 1] 2. [Action item 2] 3. [Action item 3]

---

Appendix: Full Test Outputs

[Optional: Include full test outputs if needed for detailed analysis]

Related skills

Lark Openapi ExplorerInstantly explore, test, and generate calls against the full Lark (Feishu) OpenAPI surface without leaving their agent workflow.493k

Lark EventConsume real-time events from Lark/Feishu as structured NDJSON streams inside AI agent workflows.387k16k

Lark Openapi ExplorerWhen an existing Lark/Feishu skill or CLI command cannot fulfill a specific requirement and they need to discover and invoke the exact native OpenAPI endpoint.386k16k

Just ScrapeQuickly search, crawl, extract structured JSON, or monitor web pages without writing custom scraping code.245k41

Lark AppsQuery the current visibility and permission scope of a Lark (Feishu) app without writing HTTP client code.235k16k

Design An InterfaceGenerate multiple radically different interface or API designs in parallel before committing to one.188k198k

Backend & APIsbackendintegrations

About

Multi Agent E2e Validation by the numbers

Add your badge

What it does

Files

Multi-Agent E2E Validation

Overview

When to Use This Skill

Core Methodology

1. Validation Architecture (3-Layer Model)

2. Agent Orchestration Pattern

3. Validation Script Structure

4. Bug Classification and Tracking

5. Release Readiness Decision Framework

Workflow: Step-by-Step

Step 1: Create Validation Plan (ADR-Driven)

Step 2: Execute Agent 1 (Environment)

Step 3: Execute Agents 2-3 in Parallel

Step 4: Document Findings in VALIDATION_FINDINGS.md

Step 5: Iterate on Fixes

Step 6: Final Validation and Release Decision

Real-World Example: QuestDB Refactor Validation

Common Pitfalls

1. Skipping Environment Validation

2. Serial Agent Execution

3. Manual Test Reporting

4. Ignoring Medium Bugs

5. No Re-validation After Fixes

Resources

scripts/

references/

assets/

Troubleshooting

Post-Execution Reflection

Bug Severity Classification

Severity Levels

🔴 Critical

🟡 Medium

🟢 Low

Classification Decision Tree

Real-World Examples from QuestDB Refactor

🔴 Critical Bug: Sender API Mismatch

🔴 Critical Bug: Timestamp Parsing

🔴 Critical Bug: Deduplication Design Flaw

🟡 Medium Bug: Performance Below SLO

🟢 Low Bug: Test Timezone Comparison

Severity Assessment Checklist

Dispute Resolution

Evolution Log

2026-02-26: Initial Evolution Log

Purpose

How to Use

E2E Validation Findings Report

Executive Summary

Agent 1: [Environment Setup] - [✅ PASS / ❌ FAIL]

Results

Artifacts

Agent 2: [Data Flow] - [✅ PASS / ❌ FAIL]

Critical Bugs Found & Fixed

Bug 1: [Descriptive Name] (CRITICAL - [Status])

Bug 2: [Descriptive Name] (MEDIUM - [Status])

Test Results Summary

Agent 3: [Query Interface] - [✅ PASS / ❌ FAIL]

Test Results

Validation Logs

Agent 1 Logs

Agent 2 Logs

Agent 3 Logs

Release Decision Matrix

Appendix: Full Test Outputs

Related skills

This week in AI coding