
Qe Test Execution
- 31 installs
- 433 repo stars
- Updated August 4, 2026
- proffesor-for-testing/agentic-qe
qe test execution is a Claude Code skill for testing & qa.
About
qe test execution is a Claude Code skill for testing & qa. It helps solo builders move faster with AI-assisted development.
- qe test execution
- Testing & QA
- AI-coding skill
Qe Test Execution by the numbers
- 31 all-time installs (skills.sh)
- Ranked #1,347 of 2,153 Testing & QA skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/proffesor-for-testing/agentic-qe --skill qe-test-executionAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 31 |
|---|---|
| repo stars | ★ 433 |
| Last updated | August 4, 2026 |
| Repository | proffesor-for-testing/agentic-qe ↗ |
How do I helps with testing & qa tasks.?
Helps with testing & qa tasks.
Who is it for?
Best when you're working on testing & qa and need structured help with qe test execution.
Skip if: Teams with no testing & qa needs, or anyone wanting a generic chat assistant without this specific workflow.
When should I use this skill?
When you need to helps with testing & qa tasks., or when qe test execution is a claude code skill for testing & qa.
What you get
Structured output aligned to qe test execution: qe test execution, Testing & QA.
Files
QE Test Execution
Purpose
Guide the use of v3's test execution capabilities including parallel orchestration, smart test selection, flaky test handling, and distributed execution across multiple environments.
Activation
- When running test suites
- When optimizing test execution time
- When handling flaky tests
- When setting up CI/CD test pipelines
- When executing tests across environments
Quick Start
# Run all tests with parallelization
aqe test run --parallel --workers 4
# Run affected tests only
aqe test run --affected --since HEAD~1
# Run with retry for flaky tests
aqe test run --retry 3 --retry-delay 1000
# Run specific test types
aqe test run --type unit,integration --exclude e2eAgent Workflow
// Orchestrate test execution
Task("Execute test suite", `
Run the full test suite with:
- 4 parallel workers
- Retry flaky tests up to 3 times
- Generate JUnit report
- Fail fast on critical tests
Report results and any failures.
`, "qe-test-executor")
// Smart test selection
Task("Run affected tests", `
Analyze changes in PR #123 and:
- Identify affected test files
- Run only relevant tests
- Include integration tests for changed modules
- Report coverage delta
`, "qe-test-selector")Execution Strategies
1. Parallel Execution
await testExecutor.runParallel({
suites: ['unit', 'integration'],
workers: 4,
distribution: 'by-file', // or 'by-test', 'by-duration'
isolation: 'process',
sharding: {
enabled: true,
total: 4,
index: process.env.SHARD_INDEX
}
});2. Smart Test Selection
await testExecutor.runAffected({
changes: gitChanges,
selection: {
direct: true, // Tests for changed files
transitive: true, // Tests for dependents
integration: true // Integration tests touching changed code
},
fallback: 'full-suite' // If analysis fails
});3. Flaky Test Handling
await testExecutor.handleFlaky({
detection: {
enabled: true,
threshold: 0.1, // 10% flake rate
window: 100 // Last 100 runs
},
strategy: {
retry: 3,
quarantine: true,
notify: ['#flaky-tests']
}
});Execution Configuration
execution:
parallel:
workers: auto # CPU cores - 1
timeout: 30000
bail: false
retry:
count: 2
delay: 1000
only_failed: true
reporting:
formats: [junit, json, html]
include_timing: true
include_logs: true
environments:
- name: node-18
image: node:18-alpine
- name: node-20
image: node:20-alpineCI/CD Integration
# GitHub Actions example
test:
runs-on: ubuntu-latest
strategy:
matrix:
shard: [1, 2, 3, 4]
steps:
- uses: actions/checkout@v4
- name: Run tests
run: |
aqe test run \
--shard ${{ matrix.shard }}/4 \
--parallel \
--report junit
- name: Upload results
uses: actions/upload-artifact@v4
with:
name: test-results-${{ matrix.shard }}
path: reports/Result Aggregation
interface ExecutionResults {
summary: {
total: number;
passed: number;
failed: number;
skipped: number;
flaky: number;
duration: number;
};
shards: ShardResult[];
failures: TestFailure[];
flakyTests: FlakyTest[];
coverage: CoverageReport;
timing: TimingAnalysis;
}Gotchas
- Full test suites may OOM in containers — the rule "don't run full suite" was violated 20x despite being in CLAUDE.md. Fix: make suite lightweight, don't just add more rules
- Fewer focused agents (3-4) outperform many vague ones (6-8) — always include verification command in each agent prompt
- New model releases can shift agent behavior mid-sprint — rules followed yesterday may be ignored today after model update
- Running all tests in parallel can mask flaky tests — use
--workers=1for initial diagnosis - Session crashes lose all context — save intermediate results to disk, not just memory
Coordination
Primary Agents: qe-test-executor, qe-test-selector, qe-flaky-detector Coordinator: qe-test-execution-coordinator Related Skills: qe-test-generation, qe-coverage-analysis
# =============================================================================
# AQE Skill Evaluation Test Suite: QE Test Execution v1.0.0
# =============================================================================
#
# Comprehensive evaluation suite for the qe-test-execution skill.
# Tests parallel test execution orchestration, smart test selection,
# flaky test handling, and comprehensive result aggregation.
#
# Schema: .claude/skills/.validation/schemas/skill-eval.schema.json
# Validator: .claude/skills/qe-test-execution/scripts/validate-config.json
#
# Coverage:
# - Parallel execution with intelligent distribution
# - Smart test selection (affected tests)
# - Flaky test detection and handling
# - Test result aggregation and reporting
# - CI/CD pipeline integration
#
# =============================================================================
skill: qe-test-execution
version: 1.0.0
description: >
Comprehensive evaluation suite for the qe-test-execution skill.
Tests parallel test execution orchestration, smart test selection based on
code changes, flaky test detection and quarantine, distributed test execution
with sharding, and comprehensive result aggregation across shards.
# =============================================================================
# Multi-Model Configuration
# =============================================================================
models_to_test:
- claude-sonnet-4-6 # Primary (high accuracy expected)
- claude-haiku-4-5 # Fast model (minimum quality floor)
# =============================================================================
# MCP Integration Configuration
# =============================================================================
mcp_integration:
enabled: true
namespace: skill-validation
query_patterns: true
track_outcomes: true
store_patterns: true
share_learning: true
update_quality_gate: true
target_agents:
- qe-learning-coordinator
- qe-queen-coordinator
- qe-test-executor
- qe-flaky-detector
# =============================================================================
# ReasoningBank Learning Configuration
# =============================================================================
learning:
store_success_patterns: true
store_failure_patterns: true
pattern_ttl_days: 90
min_confidence_to_store: 0.7
cross_model_comparison: true
# =============================================================================
# Result Format Configuration
# =============================================================================
result_format:
json_output: true
markdown_report: true
include_raw_output: false
include_timing: true
include_token_usage: true
# =============================================================================
# Environment Setup
# =============================================================================
setup:
required_tools:
- jq
environment_variables:
PARALLEL_WORKERS: "4"
FLAKY_DETECTION: "enabled"
RETRY_COUNT: "3"
fixtures: []
# =============================================================================
# TEST CASES
# =============================================================================
test_cases:
# ---------------------------------------------------------------------------
# CATEGORY: Parallel Execution
# ---------------------------------------------------------------------------
- id: tc001_parallel_test_execution
description: "Orchestrate parallel test execution with optimal distribution"
category: parallel_execution
priority: critical
input:
prompt: |
Orchestrate parallel execution for full test suite:
- 245 unit tests, 89 integration tests, 34 e2e tests
- 4 parallel workers available
- Timeout: 30 seconds per test
DISTRIBUTION STRATEGY:
By file (balanced): Each worker gets ~89 tests
By duration (optimized): Longest tests first to balance execution time
By type (isolated): Workers by test type to manage resources
Which strategy and why?
How would you handle test isolation (DB, file system)?
context:
total_tests: 368
workers: 4
strategy: "by_duration"
isolation: "process"
expected_output:
must_contain:
- "parallel"
- "distribution"
- "worker"
- "execution"
- "isolation"
must_not_contain:
- "sequential"
- "error"
severity_classification: critical
finding_count:
min: 1
validation:
schema_check: true
keyword_match_threshold: 0.8
reasoning_quality_min: 0.75
- id: tc002_test_sharding_ci_cd
description: "Distribute tests across CI/CD pipeline shards"
category: parallel_execution
priority: critical
input:
prompt: |
Design test sharding for GitHub Actions:
- 4 parallel jobs (shards)
- Total 368 tests
- Each shard runs 1/4 of tests
SHARD CONFIGURATION:
Shard 1: Tests 1-92 (unit: 0-50, integration: 0-30, e2e: 0-10)
Shard 2: Tests 93-184
Shard 3: Tests 185-276
Shard 4: Tests 277-368
How would you balance load across shards?
How to aggregate results?
context:
shards: 4
total_tests: 368
balancing: "by_duration"
expected_output:
must_contain:
- "shard"
- "distribute"
- "aggregate"
- "parallel"
must_not_contain:
- "sequential"
- "fail"
severity_classification: critical
validation:
schema_check: true
keyword_match_threshold: 0.8
# ---------------------------------------------------------------------------
# CATEGORY: Smart Test Selection
# ---------------------------------------------------------------------------
- id: tc003_affected_tests_detection
description: "Identify and run only affected tests based on changes"
category: smart_selection
priority: critical
input:
prompt: |
Detect affected tests for PR #456 changes:
CHANGED FILES:
- src/services/UserService.ts
- src/utils/validation.ts
- tests/unit/UserService.test.ts
AFFECTED TESTS:
DIRECT: tests/unit/UserService.test.ts (tests changed file)
TRANSITIVE: tests/unit/ValidationUtils.test.ts (validation.ts changed)
INTEGRATION: tests/integration/UserAPI.test.ts (calls UserService)
DEPENDENT: tests/e2e/UserFlow.test.ts (user flow uses UserService)
SELECT FOR EXECUTION:
- tests/unit/UserService.test.ts (MUST)
- tests/unit/ValidationUtils.test.ts (MUST)
- tests/integration/UserAPI.test.ts (SHOULD)
- tests/e2e/UserFlow.test.ts (COULD)
How would you prioritize?
context:
base_branch: "main"
pr_branch: "feature-user-improvements"
selection_strategy: "transitive"
expected_output:
must_contain:
- "affected"
- "test"
- "detect"
- "transitive"
- "priority"
must_not_contain:
- "all tests"
- "no selection"
severity_classification: critical
validation:
schema_check: true
keyword_match_threshold: 0.8
reasoning_quality_min: 0.75
- id: tc004_test_impact_analysis
description: "Analyze which tests are impacted by code changes"
category: smart_selection
priority: high
input:
prompt: |
For change to authentication module, what tests are impacted?
CHANGE: auth/middleware.ts now requires additional role check
IMPACT ANALYSIS:
1. Tests for auth middleware: 8 tests - DIRECT
2. Tests for endpoints using auth: 42 tests - TRANSITIVE
3. E2E tests using auth: 12 tests - TRANSITIVE
4. Integration tests with external auth: 3 tests - TRANSITIVE
5. Performance tests (baseline): 5 tests - POTENTIALLY
6. Other tests (user management): 0 tests - NOT AFFECTED
ESTIMATED EXECUTION TIME:
- All affected: ~2 minutes
- Just direct: ~30 seconds
- Fallback if analysis fails: ~5 minutes (all tests)
Recommend: Run all affected (65 tests)
context:
change_module: "auth"
impact_scope: "transitive"
expected_output:
must_contain:
- "impact"
- "affected"
- "direct"
- "transitive"
- "estimate"
finding_count:
min: 1
validation:
schema_check: true
keyword_match_threshold: 0.75
# ---------------------------------------------------------------------------
# CATEGORY: Flaky Test Handling
# ---------------------------------------------------------------------------
- id: tc005_flaky_test_detection
description: "Detect flaky tests based on failure patterns"
category: flaky_tests
priority: critical
input:
prompt: |
Analyze test flakiness from last 100 runs:
TEST: UserService.getById() test
- Passed: 85 times
- Failed: 15 times
- Flake rate: 15%
- Failure pattern: Random, no correlation to time or data
TEST: PaymentService.process() test
- Passed: 97 times
- Failed: 3 times
- Flake rate: 3% (acceptable)
- Failure pattern: Only during peak hours (high CPU)
TEST: AuthService.login() test
- Passed: 99 times
- Failed: 1 time
- Flake rate: 1% (not flaky)
ACTIONS:
1. Quarantine UserService test (15% too high)
2. Investigate PaymentService (peak hour pattern)
3. No action on AuthService (1% acceptable)
context:
flakiness_window: "100_runs"
threshold_quarantine: 0.10
expected_output:
must_contain:
- "flaky"
- "test"
- "detect"
- "quarantine"
- "rate"
must_not_contain:
- "no flaky"
- "all stable"
severity_classification: critical
validation:
schema_check: true
keyword_match_threshold: 0.8
reasoning_quality_min: 0.75
- id: tc006_flaky_test_remediation
description: "Provide fixes for flaky tests"
category: flaky_tests
priority: high
input:
prompt: |
Fix flaky test: UserService.getById() (15% flake rate)
ROOT CAUSE ANALYSIS:
- Test uses real database with data cleanup race condition
- Timing-dependent assertions (no proper wait)
- Parallel test execution interferes with state
FIXES (prioritized):
1. IMMEDIATE: Add proper wait/retry for async operations
2. IMMEDIATE: Use test isolation (separate test data per run)
3. SHORT-TERM: Mock external dependencies
4. LONG-TERM: Refactor to eliminate race conditions
CODE EXAMPLES:
```javascript
// BEFORE (flaky)
test('gets user by id', () => {
user = db.insert({name: 'Test'});
result = UserService.getById(user.id);
expect(result.name).toBe('Test');
});
// AFTER (stable)
test('gets user by id', async () => {
const user = await testFixture.createUser({name: 'Test'});
await waitFor(() => UserService.getById(user.id));
expect(result.name).toBe('Test');
});
```
context:
test_name: "UserService.getById"
flake_rate: 0.15
expected_output:
must_contain:
- "fix"
- "flaky"
- "isolation"
- "async"
- "wait"
finding_count:
min: 1
validation:
schema_check: true
keyword_match_threshold: 0.75
# ---------------------------------------------------------------------------
# CATEGORY: Result Aggregation
# ---------------------------------------------------------------------------
- id: tc007_test_result_aggregation
description: "Aggregate results from parallel shards"
category: result_aggregation
priority: critical
input:
prompt: |
Aggregate results from 4 parallel shards:
SHARD 1: 92 tests - 88 passed, 4 failed, 0 skipped
SHARD 2: 92 tests - 92 passed, 0 failed, 0 skipped
SHARD 3: 92 tests - 85 passed, 5 failed, 2 skipped
SHARD 4: 92 tests - 90 passed, 2 failed, 0 skipped
AGGREGATED RESULTS:
- Total: 368 tests
- Passed: 355 (96.5%)
- Failed: 11 (3%)
- Skipped: 2 (0.5%)
- Execution time: 4 minutes 32 seconds
FAILURES:
Shard 1: UserService.test.ts:45, UserService.test.ts:67, ...
Shard 3: PaymentService.test.ts:23, ...
Shard 4: AuthService.test.ts:12, ...
Should merge be blocked? (11 failures)
context:
shards: 4
aggregation_scope: "full"
expected_output:
must_contain:
- "aggregate"
- "result"
- "passed"
- "failed"
- "shard"
must_not_contain:
- "error"
- "incomplete"
severity_classification: critical
validation:
schema_check: true
keyword_match_threshold: 0.8
- id: tc008_junitxml_report_generation
description: "Generate JUnit XML report for CI/CD integration"
category: result_aggregation
priority: high
input:
prompt: |
Generate JUnit XML report from test results:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<testsuites>
<testsuite name="unit" tests="245" failures="4" skipped="0" time="12.34">
<testcase name="UserService::getById" classname="unit" time="0.023"/>
<testcase name="UserService::create" classname="unit" time="0.045">
<failure message="Expected 'John' but got 'Jane'"/>
</testcase>
</testsuite>
<testsuite name="integration" tests="89" failures="5" skipped="2">
...
</testsuite>
</testsuites>
```
How would you structure this for:
1. GitHub Actions integration
2. JUnit report parsing
3. Test history tracking
context:
format: "junit_xml"
include_timing: true
include_failure_details: true
expected_output:
must_contain:
- "JUnit"
- "XML"
- "testcase"
- "failure"
- "report"
finding_count:
min: 1
validation:
schema_check: true
keyword_match_threshold: 0.75
# ---------------------------------------------------------------------------
# CATEGORY: Retry & Recovery
# ---------------------------------------------------------------------------
- id: tc009_test_retry_strategy
description: "Design and implement test retry logic"
category: retry
priority: high
input:
prompt: |
Design retry strategy for flaky tests:
RETRY CONFIG:
- Max retries: 3
- Delay: 1000ms between retries
- Backoff: exponential (1s, 2s, 4s)
- Only failed tests retry
- Don't retry critical failures (syntax errors)
EXAMPLE:
Test 1: FAIL (1st attempt) -> RETRY -> PASS (2nd attempt) = PASS
Test 2: FAIL (all 3 attempts) = FAIL (flaky, quarantine)
Test 3: PASS (1st attempt) = PASS (no retry needed)
How to detect which tests benefit from retry?
How to distinguish flaky from actually broken?
context:
max_retries: 3
strategy: "exponential_backoff"
expected_output:
must_contain:
- "retry"
- "flaky"
- "backoff"
- "strategy"
- "failed"
finding_count:
min: 1
validation:
schema_check: true
keyword_match_threshold: 0.75
# ---------------------------------------------------------------------------
# CATEGORY: Negative Tests
# ---------------------------------------------------------------------------
- id: tc010_test_execution_optimization
description: "Optimize test execution time and resource usage"
category: negative
priority: high
input:
prompt: |
Optimize test suite execution from 5 minutes to < 3 minutes:
ANALYSIS:
- Unit tests: 245 tests, 45 seconds (could be 30s)
- Integration tests: 89 tests, 2 minutes 15 seconds (could be 1m 20s)
- E2E tests: 34 tests, 2 minutes (fixed, must run)
OPTIMIZATION STRATEGIES:
1. Parallel workers: 4x parallelization = ~50% time reduction
2. Smart selection: Run only affected tests (60% reduction for PR)
3. Mocking: Mock external services (30% reduction for integration)
4. Test fixture reuse: Reduce setup/teardown (10% reduction)
5. Resource management: Optimize CPU/memory (5% reduction)
EXPECTED RESULTS:
- Current: 5 minutes
- After optimizations: 1-2 minutes (4x-5x improvement)
How would you measure and track improvements?
context:
current_time_ms: 300000
target_time_ms: 180000
optimization_focus: true
expected_output:
must_contain:
- "optimize"
- "reduce"
- "parallel"
- "improve"
- "measure"
finding_count:
min: 1
validation:
schema_check: true
allow_partial: true
# =============================================================================
# SUCCESS CRITERIA
# =============================================================================
success_criteria:
pass_rate: 0.8
critical_pass_rate: 1.0
avg_reasoning_quality: 0.75
max_execution_time_ms: 300000
cross_model_variance: 0.15
# =============================================================================
# METADATA
# =============================================================================
metadata:
author: "qe-test-executor"
created: "2026-02-02"
last_updated: "2026-02-02"
coverage_target: >
Parallel test execution with distribution strategies (by-file/duration/type),
test sharding for CI/CD with load balancing, smart test selection based on
code changes and transitive dependencies, flaky test detection and quarantine,
test result aggregation across shards, JUnit XML report generation, retry
logic with exponential backoff, and comprehensive test execution optimization
strategies for reducing execution time.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://agentic-qe.dev/schemas/qe-test-execution-output.json",
"title": "AQE Test Execution Skill Output Schema",
"description": "Schema for test execution skill output. Includes parallel execution results, retries, and execution metrics.",
"type": "object",
"required": ["skillName", "version", "timestamp", "status", "trustTier", "output"],
"properties": {
"skillName": {
"type": "string",
"const": "qe-test-execution",
"description": "Must be 'qe-test-execution'"
},
"version": {
"type": "string",
"pattern": "^\\d+\\.\\d+\\.\\d+(-[a-zA-Z0-9]+)?$"
},
"timestamp": {
"type": "string",
"format": "date-time"
},
"status": {
"type": "string",
"enum": ["success", "partial", "failed", "skipped"]
},
"trustTier": {
"type": "integer",
"const": 3
},
"output": {
"type": "object",
"required": ["summary", "results", "metrics"],
"properties": {
"summary": {
"type": "string",
"minLength": 50,
"maxLength": 2000
},
"results": {
"$ref": "#/$defs/executionResults"
},
"parallelization": {
"$ref": "#/$defs/parallelizationConfig"
},
"retries": {
"$ref": "#/$defs/retryReport"
},
"metrics": {
"$ref": "#/$defs/executionMetrics"
},
"failures": {
"type": "array",
"items": {
"$ref": "#/$defs/testFailure"
},
"maxItems": 500
},
"flakyTests": {
"type": "array",
"items": {
"$ref": "#/$defs/flakyTest"
},
"maxItems": 100
},
"shards": {
"type": "array",
"items": {
"$ref": "#/$defs/shardResult"
},
"maxItems": 50
},
"coverage": {
"$ref": "#/$defs/coverageReport"
},
"timing": {
"$ref": "#/$defs/timingAnalysis"
},
"artifacts": {
"type": "array",
"items": {
"$ref": "#/$defs/artifact"
},
"maxItems": 30
}
}
},
"metadata": {
"$ref": "#/$defs/metadata"
},
"validation": {
"$ref": "#/$defs/validationResult"
},
"learning": {
"$ref": "#/$defs/learningData"
}
},
"$defs": {
"executionResults": {
"type": "object",
"required": ["total", "passed", "failed"],
"properties": {
"total": {
"type": "integer",
"minimum": 0
},
"passed": {
"type": "integer",
"minimum": 0
},
"failed": {
"type": "integer",
"minimum": 0
},
"skipped": {
"type": "integer",
"minimum": 0
},
"pending": {
"type": "integer",
"minimum": 0
},
"flaky": {
"type": "integer",
"minimum": 0
},
"passRate": {
"type": "number",
"minimum": 0,
"maximum": 100
},
"status": {
"type": "string",
"enum": ["pass", "fail", "partial"]
},
"testsByType": {
"type": "object",
"properties": {
"unit": { "$ref": "#/$defs/typeSummary" },
"integration": { "$ref": "#/$defs/typeSummary" },
"e2e": { "$ref": "#/$defs/typeSummary" },
"performance": { "$ref": "#/$defs/typeSummary" }
}
}
}
},
"typeSummary": {
"type": "object",
"properties": {
"total": { "type": "integer", "minimum": 0 },
"passed": { "type": "integer", "minimum": 0 },
"failed": { "type": "integer", "minimum": 0 },
"duration": { "type": "integer", "minimum": 0 }
}
},
"parallelizationConfig": {
"type": "object",
"properties": {
"enabled": {
"type": "boolean"
},
"workers": {
"type": "integer",
"minimum": 1,
"maximum": 64
},
"strategy": {
"type": "string",
"enum": ["by-file", "by-test", "by-duration", "by-shard"]
},
"sharding": {
"type": "object",
"properties": {
"enabled": { "type": "boolean" },
"totalShards": { "type": "integer", "minimum": 1 },
"shardIndex": { "type": "integer", "minimum": 0 }
}
},
"isolation": {
"type": "string",
"enum": ["process", "thread", "worker", "container"]
}
}
},
"retryReport": {
"type": "object",
"properties": {
"enabled": {
"type": "boolean"
},
"maxRetries": {
"type": "integer",
"minimum": 0,
"maximum": 10
},
"retryDelay": {
"type": "integer",
"minimum": 0,
"description": "Delay in milliseconds"
},
"testsRetried": {
"type": "integer",
"minimum": 0
},
"successAfterRetry": {
"type": "integer",
"minimum": 0
},
"failedAfterAllRetries": {
"type": "integer",
"minimum": 0
},
"retriedTests": {
"type": "array",
"items": {
"type": "object",
"properties": {
"testId": { "type": "string" },
"attempts": { "type": "integer" },
"finalStatus": { "type": "string", "enum": ["pass", "fail"] }
}
}
}
}
},
"executionMetrics": {
"type": "object",
"required": ["totalDuration"],
"properties": {
"totalDuration": {
"type": "integer",
"minimum": 0,
"description": "Total execution time in milliseconds"
},
"setupDuration": {
"type": "integer",
"minimum": 0
},
"testDuration": {
"type": "integer",
"minimum": 0
},
"teardownDuration": {
"type": "integer",
"minimum": 0
},
"parallelEfficiency": {
"type": "number",
"minimum": 0,
"maximum": 100,
"description": "Parallel efficiency percentage"
},
"testsPerSecond": {
"type": "number",
"minimum": 0
},
"avgTestDuration": {
"type": "integer",
"minimum": 0
},
"maxTestDuration": {
"type": "integer",
"minimum": 0
},
"slowestTests": {
"type": "array",
"items": {
"type": "object",
"properties": {
"name": { "type": "string" },
"duration": { "type": "integer" }
}
},
"maxItems": 10
},
"memoryUsage": {
"type": "object",
"properties": {
"peak": { "type": "integer" },
"average": { "type": "integer" }
}
}
}
},
"testFailure": {
"type": "object",
"required": ["testId", "name", "error"],
"properties": {
"testId": {
"type": "string"
},
"name": {
"type": "string",
"maxLength": 500
},
"file": {
"type": "string"
},
"suite": {
"type": "string"
},
"error": {
"type": "string",
"maxLength": 5000
},
"stackTrace": {
"type": "string",
"maxLength": 10000
},
"type": {
"type": "string",
"enum": ["assertion", "timeout", "error", "setup", "teardown"]
},
"duration": {
"type": "integer",
"minimum": 0
},
"retryCount": {
"type": "integer",
"minimum": 0
},
"screenshot": {
"type": "string",
"description": "Path to failure screenshot"
},
"diff": {
"type": "object",
"properties": {
"expected": { "type": "string" },
"actual": { "type": "string" }
}
}
}
},
"flakyTest": {
"type": "object",
"required": ["testId", "name", "flakinessRate"],
"properties": {
"testId": {
"type": "string"
},
"name": {
"type": "string"
},
"file": {
"type": "string"
},
"flakinessRate": {
"type": "number",
"minimum": 0,
"maximum": 1,
"description": "Rate of flaky behavior (0-1)"
},
"recentRuns": {
"type": "integer",
"minimum": 1
},
"failures": {
"type": "integer",
"minimum": 0
},
"quarantined": {
"type": "boolean"
},
"lastFailure": {
"type": "string",
"format": "date-time"
},
"failureReasons": {
"type": "array",
"items": { "type": "string" }
}
}
},
"shardResult": {
"type": "object",
"required": ["shardIndex", "status"],
"properties": {
"shardIndex": {
"type": "integer",
"minimum": 0
},
"status": {
"type": "string",
"enum": ["pass", "fail", "running", "pending"]
},
"tests": {
"type": "integer",
"minimum": 0
},
"passed": {
"type": "integer",
"minimum": 0
},
"failed": {
"type": "integer",
"minimum": 0
},
"duration": {
"type": "integer",
"minimum": 0
},
"worker": {
"type": "string"
}
}
},
"coverageReport": {
"type": "object",
"properties": {
"statement": {
"type": "number",
"minimum": 0,
"maximum": 100
},
"branch": {
"type": "number",
"minimum": 0,
"maximum": 100
},
"function": {
"type": "number",
"minimum": 0,
"maximum": 100
},
"line": {
"type": "number",
"minimum": 0,
"maximum": 100
},
"delta": {
"type": "object",
"properties": {
"statement": { "type": "number" },
"branch": { "type": "number" },
"function": { "type": "number" },
"line": { "type": "number" }
},
"description": "Coverage change from previous run"
}
}
},
"timingAnalysis": {
"type": "object",
"properties": {
"percentiles": {
"type": "object",
"properties": {
"p50": { "type": "integer" },
"p75": { "type": "integer" },
"p90": { "type": "integer" },
"p95": { "type": "integer" },
"p99": { "type": "integer" }
}
},
"distribution": {
"type": "array",
"items": {
"type": "object",
"properties": {
"range": { "type": "string" },
"count": { "type": "integer" }
}
}
},
"criticalPath": {
"type": "array",
"items": {
"type": "string"
},
"description": "Tests on the critical path"
}
}
},
"artifact": {
"type": "object",
"required": ["type", "path"],
"properties": {
"type": {
"type": "string",
"enum": ["report", "junit", "coverage", "screenshot", "video", "log"]
},
"path": { "type": "string", "maxLength": 500 },
"format": {
"type": "string",
"enum": ["json", "xml", "html", "md", "lcov", "png", "mp4"]
},
"description": { "type": "string" }
}
},
"metadata": {
"type": "object",
"properties": {
"executionTimeMs": { "type": "integer", "minimum": 0 },
"framework": {
"type": "string",
"enum": ["jest", "vitest", "mocha", "pytest", "junit", "playwright", "cypress"]
},
"agentId": { "type": "string", "pattern": "^qe-[a-z][a-z0-9-]*$" },
"environment": {
"type": "string",
"enum": ["development", "staging", "production", "ci"]
},
"nodeVersion": { "type": "string" },
"platform": { "type": "string" }
}
},
"validationResult": {
"type": "object",
"properties": {
"schemaValid": { "type": "boolean" },
"contentValid": { "type": "boolean" },
"confidence": { "type": "number", "minimum": 0, "maximum": 1 },
"warnings": { "type": "array", "items": { "type": "string" } },
"errors": { "type": "array", "items": { "type": "string" } }
}
},
"learningData": {
"type": "object",
"properties": {
"patternsDetected": { "type": "array", "items": { "type": "string" } },
"reward": { "type": "number", "minimum": 0, "maximum": 1 },
"optimizationSuggestions": {
"type": "array",
"items": { "type": "string" }
}
}
}
}
}
{
"skillName": "qe-test-execution",
"skillVersion": "1.0.0",
"requiredTools": [
"jq"
],
"optionalTools": [],
"schemaPath": "schemas/output.json",
"requiredFields": [
"skillName",
"status",
"output",
"output.summary",
"output.results",
"output.metrics"
],
"requiredNonEmptyFields": [
"output.summary"
],
"mustContainTerms": [
"test",
"execution"
],
"mustNotContainTerms": [
"TODO",
"placeholder",
"FIXME"
],
"enumValidations": {
".status": [
"success",
"partial",
"failed",
"skipped"
]
}
}
Related skills
FAQ
What does qe test execution do?
qe test execution is a Claude Code skill for testing & qa.
When should I use qe test execution?
When you need to helps with testing & qa tasks., or when qe test execution is a claude code skill for testing & qa.
What are the main capabilities?
qe test execution; Testing & QA; AI-coding skill.