What is test-executor?

The Test Executor skill automates the end-to-end testing lifecycle for Go projects, handling everything from execution and coverage analysis to detailed result interpretation. It helps developers maintain high code quality by providing actionable insights, identifying uncovered code paths, and ensuring all tests pass before critical milestones like commits or pull requests.

When should I use test-executor?

test-executor is useful in the following scenarios: • Automated Regression Testing: Execute full test suites immediately after code modifications or refactoring to ensure existing functionality remains intact. • Quality Gate Enforcement: Monitor and report on test coverage against specific thresholds (e.g., 90%) to maintain project health and coding standards. • Pre-Commit/Pre-PR Validation: Generate comprehensive testing status reports and summaries to verify readiness before merging code into the main branch. • Root Cause Analysis: Deeply analyze test failures and panics to provide developers with clear explanations and specific recommendations for fixes. • Performance Benchmarking: Run and capture Go benchmarks to track execution time and memory allocations, ensuring performance stability.

name	test-executor
description	Executes tests, analyzes test results, checks test coverage, and provides comprehensive testing status overview. Primarily for Go projects. Activates after implementing/modifying code to verify correctness, or when explicitly requested to assess test suite health.
allowed-tools	[Bash, Read, Glob, Grep, AskUserQuestion]

Test Executor Skill

Purpose

Execute tests, analyze results comprehensively, and provide actionable insights about testing status of Go projects.

Activation Triggers

Automatic Activation

After implementing or modifying code
After refactoring critical modules
When preparing to commit changes

Manual Activation

User explicitly requests test execution
User asks about test coverage status
Before creating pull requests

Core Responsibilities

Test Execution: Run tests using appropriate commands (go test, make test)
Coverage Analysis: Calculate and report test coverage for ./internal/... packages
Result Interpretation: Analyze results, identify failures, provide clear explanations
Status Reporting: Deliver comprehensive summaries with actionable recommendations

Test Execution Process

Phase 1: Identify Test Scope

Check project structure
- Determine which packages to test
- Identify coverage calculation scope
- Check for Makefile or custom test commands
Project-specific settings
- This project: Focus on ./internal/..., exclude cmd/panos
- Coverage threshold: 90%
- Test command: make test or go test ./...

Phase 2: Run Tests with Coverage

Execute tests
```
go test ./internal/... -coverprofile=coverage.out -covermode=atomic
```
- Capture both test results and coverage data
- Note test failures, panics, or timeout issues
Generate coverage report
```
go tool cover -func=coverage.out
```
- Calculate total coverage percentage
- Identify uncovered or poorly covered packages
Run benchmarks (if requested)
```
go test -bench=. -benchmem ./...
```
- Capture performance metrics (ns/op, allocations, memory)

Phase 3: Analyze Results

For each test execution, provide:

1. Executive Summary

Total tests run / passed / failed
Overall coverage percentage
Comparison to threshold (90% for this project)
Quick verdict: ✅ All passing, ⚠️ Issues found, ❌ Critical failures

2. Detailed Breakdown

Package-by-package coverage report
List of failed tests with error messages
Uncovered code sections (if coverage < 90%)

3. Actionable Recommendations

Specific tests that need attention
Suggestions for improving coverage
Performance concerns from benchmarks (if applicable)
Next steps for the developer

Phase 4: Report Results

Use structured format (in Japanese, だ・である調):

## テスト実行結果

### 📊 サマリー
- 実行テスト数: X件
- 成功: Y件 ✅
- 失敗: Z件 ❌
- カバレッジ: W% (閾値: 90%)
- 総合評価: [verdict]

### 📦 パッケージ別カバレッジ
[package-by-package breakdown]

### ⚠️ 注意が必要な項目
[issues and concerns]

### 💡 推奨アクション
[specific recommendations]

Quality Standards

Accuracy: Report exact numbers from test output, never estimate
Completeness: Cover all aspects (unit tests, coverage, benchmarks if run)
Clarity: Use clear formatting with emojis for visual scanning
Actionability: Always provide specific next steps, not vague advice

Edge Cases and Handling

No tests found: Report clearly and suggest creating test files
Coverage tool errors: Check if coverage.out was generated, provide troubleshooting
Flaky tests: Note if re-running gives different results
Build failures: Distinguish between compilation errors and test failures
Timeout issues: Identify long-running tests and suggest optimization

Test Failure Analysis

When test failures occur:

Identify root cause
- Not just surface-level error message
- Analyze what condition caused failure
Provide guidance
- Suggest specific fixes
- Recommend additional tests if edge cases found
Prevent regression
- Ensure fix includes test for the failure scenario

Integration with Other Skills

code-reviewer: Run after review to verify fixes don't break tests
refactoring-assistant: Verify refactoring doesn't cause regressions
git-commit-assistant: Ensure all tests pass before committing

Usage Tips

For User

Run tests before committing changes
Check coverage regularly, especially after adding new features
Investigate failing tests immediately, don't accumulate tech debt

For Claude

Always provide exact test output, not paraphrased summaries
Guide toward root cause, not just making tests pass
Prioritize test quality over coverage numbers
Suggest additional tests for edge cases

Maintenance

Update this Skill when:

Test standards or thresholds change
New testing frameworks are adopted
Project-specific test commands change
CI/CD pipeline requirements evolve

test-executor

When & Why to Use This Skill

Use Cases