Purpose
Review only test issue code. Do not define scope (diff vs codebase) or perform language/framework/security/architecture analysis; these are separate atomic skills. Emit in standard formatfindings listfor aggregation. Focus on test presence and coverage, test quality and structure, test types and layering, edge cases and error path coverage, and test maintainability.
Core Objective
Primary objective: Generate a test-focused findings list covering test presence, coverage adequacy, test quality/structure, test types/layering, edge case coverage, and test maintainability for the given code scope.
Success criteria(all requirements must be met):
- ✅ Test scope only: Review only the testing dimension; no scope selection, language/framework conventions, security, performance, or architecture analysis performed
- ✅ Cover all six testing dimensions: Evaluate test presence, coverage adequacy, quality/structure, types/layering, edge cases/error paths, and maintainability where relevant
- ✅ Conform to findings format: Each finding includes location, category ("cognitive-testing"), severity, title, description, and optional recommendation
- ✅ Flag high-risk gaps: Untested or inadequately tested high-risk code paths (authentication, payments, data mutation) are flagged as "critical" or "major"
- ✅ Analyze from code only: Assess test adequacy from code structure and available artifacts, without running tests or generating coverage reports
AcceptanceTest: Does the output contain a test findings list covering all relevant dimensions, with risk-appropriate severity ratings and actionable recommendations to improve test coverage and quality?
Scope Boundaries
This skill is responsible for：
- Test presence checks (missing test files for critical modules, services, public functions)
- Coverage adequacy analysis (high-risk path coverage: authentication, payments, data mutation)
- Test quality and structure (arrange-act-assert, meaningful assertions, behavior over implementation)
- Test types and layering (unit, integration, e2e balance; mock/stub isolation)
- Edge cases and error path coverage (boundary conditions, invalid inputs, failure modes)
- Test maintainability (DRY without sacrificing readability, fixture organization, brittle test detection)
This skill is not responsible for：
- Scope selection (deciding which files/paths to analyze) - scope is provided by the caller
- Running tests or generating coverage reports - use "automate-tests" for test execution
- Language/framework-specific testing conventions - use "review-dotnet", "review-java", "review-go", etc.
- Security, performance, or architecture review - use the respective atomic skills
- Full orchestrated review - use "review-code"
Handoff point: After emitting all test findings, hand them off to "review-code" for aggregation in a curated review. For actually running tests, redirect to "automate-tests".
Use Cases
- Carefully Orchestrated Review: whenorchestrate-code-reviewused as the cognitive step when running scope→language→framework→library→cognitive.
- Test-Focused Review: when the user only wants to assess test operation status and coverage (for example, before release, after major refactoring, or during onboarding).
- Gap Analysis: identify untested modules, missing test types (unit/integration/e2e), or low-quality tests that provide false confidence.
When to Use: when the task includes test review. The scope and code scope are determined by the caller or user.
Behavior (Behavior)
The scope of this skill
- Analysis: Testinggiven code scopedimensions in (files or diffs provided by the caller). Does not determine scope; accepts code scope as input.
- Do not: perform scope selection, language/framework conventions, security, performance, or architecture review. Focus only on testing.
Review Checklist (test dimensions only)
- Whether tests exist: Do key modules, services, and public functionality have corresponding test files? Are there obvious gaps where critical logic is not tested at all?
- Coverage adequacy: Is test coverage sufficient for the risk level of the code? Are high-risk paths (authentication, payments, data mutation) tested? Note: if coverage reports or metrics are available, refer to them; otherwise perform a structural assessment.
- Test quality and structure: Are tests well structured (arrange-act-assert or given-when-then)? Do test names clearly describe the scenario? Are the assertions meaningful (not just "does not throw an exception")? Do the tests verify behavior rather than implementation details?
- Test types and layering: Is there an appropriate combination of unit, integration, and end-to-end tests? Are unit tests isolated (mocks/stubs for external dependencies)? Do integration tests test real interactions when needed?
- Edge cases and error paths: Do the tests cover boundary conditions, invalid input, null/empty cases, concurrency scenarios, and expected error responses? Are failure modes explicitly tested?
- Test maintainability: Are tests DRY without sacrificing readability? Are test fixtures and helpers well organized? Are tests brittle (tightly coupled to the implementation, over-mocked, or dependent on execution order)? Is test data management clean (factories, builders, or fixtures instead of hardcoded magic values)?
Tone and references
- Professional and technical: Reference specific locations (file:line or module). Emit findings that include location, category, severity, title, description, and recommendation. Use severity "major" or "critical" for untested high-risk code paths.
Input & Output (Input & Output)
Input (Input)
- Code scope: the files or directories (or diff) already selected by the user or the scope skill. This skill does not determine scope; it only reviews the provided code for testing.
Output (Output)
- withAppendix: Output Contractemit zero or more in the format defined infindings。
- The category of this skill iscognitive-testing。
Limits (Restrictions)
Hard Boundaries
- Do notperform scope selection, language, framework, security, performance, or architecture review. Stay within the testing scope.
- Do notgive conclusions without a specific location or actionable recommendations.
- No needto run tests or generate coverage reports. Analyze test adequacy from the code and available artifacts (e.g., existing coverage files). For actually running tests, use automate-tests。
- Do notpenalize the lack of tests for trivial code (simple getters, constants, generated code) unless it masks real risk.
Skill Boundaries
Do not do these(other skills can handle them):
- Do not select or define code scope - the scope is determined by the caller or "Review Code"
- Do not run or execute tests - use "automate-tests" for test execution
- Do not perform language/framework-specific test convention analysis - use the corresponding language skill
- Do not perform security, performance, or architecture analysis - use the respective atomic skills
When to stop and hand off：
- When all test results are published, hand them off to "Review Code" to aggregate them in a curated review
- When the user needs to actually run tests, redirect to "automate-tests"
- When the user needs a comprehensive review (scope + language + cognitive), redirect to "Review Code"
Self-Check
Core Success Criteria
- Test scope only: only the testing dimension is reviewed; no scope selection, language/framework conventions, security, performance, or architecture analysis is performed
- Covers all six testing dimensions: where relevant, evaluate test existence, coverage adequacy, quality/structure, types/layering, edge cases/error paths, and maintainability
- Conforms to the findings format: each finding includes location, category ("cognitive-testing"), severity, title, description, and optional recommendation
- Flag high-risk gaps: untested or inadequately tested high-risk code paths (authentication, payments, data mutation) are flagged as "Critical" or "Major"
- Analyze from code only: evaluate test adequacy based on code structure and available artifacts, without running tests or generating coverage reports
Process Quality Checks
- Was only the testing dimension reviewed (no scope/language/security/architecture)?
- Are relevant test existence, coverage adequacy, quality/structure, types/layering, edge cases, and maintainability covered?
- Does each finding include location, category=cognitive-testing, severity, title, description, and optional recommendation?
- Are critical gaps (untested high-risk code) clearly flagged and actionable?
Acceptance Testing
Does the output contain a list of test results covering all relevant dimensions, along with risk-appropriate severity ratings and actionable recommendations to improve test coverage and quality?
Example (Example)
Example 1: Missing tests for a critical module
- Input: A payment processing module with no test files.
- Expected: Issue a critical finding for missing tests on high-risk code; recommend creating unit tests for core payment logic and integration tests for gateway interactions. Category = cognitive-testing.
Example 2: Tests exist but are shallow
- Input: The authentication module has tests, but they only cover the happy path (valid login) and skip invalid credentials, expired tokens, rate limiting, and account lockout.
- Expected: Issue a major finding for insufficient edge case coverage; list the specific scenarios to add. Category = cognitive-testing.
Edge case: A well-tested codebase
- Input: The module has comprehensive unit, integration, and end-to-end tests, with clear structure and broad coverage.
- Expected: Issue zero findings or suggestion-level findings for minor improvements (e.g., test naming consistency). Do not invent problems.