Analyze an existing test suite in any supported language and apply a standardized set of trait tags to each test method, giving teams visibility into their test distribution (positive vs. negative, critical-path coverage, smoke tests, etc.).
\n\n\nLanguage-specific guidance: Call the
\ntest-analysis-extensionsskill to discover available extension files, then read the file matching the target codebase. The extension file documents framework-specific tag attributes and a \"tag-support capability\" (auto-edit, report-only, or convention-based) that drives whether this skill modifies source files or only emits a report.
code-testing-agent for any language, or writing-mstest-tests for MSTest)run-tests for .NET; equivalent native runners elsewhere)| Input | \nRequired | \nDescription | \n
|---|---|---|
| Test project or files | \nYes | \nPath to the test project, folder, or specific test files to analyze | \n
| Scope | \nNo | \ntag (apply attributes when language supports auto-edit), audit (report only), or both (default: both). For languages with no canonical tag syntax, the skill emits a report regardless of scope. | \n
| Framework | \nNo | \nAuto-detected. Override when detection fails. | \n
Use exactly these trait names and values. Do not invent new trait values outside this table.
\n| Trait Value | \nMeaning | \nHeuristics | \n
|---|---|---|
positive | \nVerifies expected behavior under normal/valid conditions | \nAsserts success, valid output, expected state, no exceptions for valid input | \n
negative | \nVerifies correct handling of invalid input, errors, or edge cases | \nAsserts exceptions, error codes, validation failures, rejects bad input | \n
boundary | \nTests limits, thresholds, empty/null/None/nil inputs, min/max values | \nOperates on 0, -1, int.MaxValue / sys.maxsize / Number.MAX_SAFE_INTEGER / math.MaxInt64 / i32::MAX, empty string, null/None/nil/undefined, empty collection, boundary of valid range | \n
critical-path | \nCore workflow that must never break; breakage blocks users | \nTests the primary success scenario of a key public API or user-facing feature | \n
smoke | \nQuick sanity check that the system is operational | \nFast, no complex setup, verifies basic wiring (e.g., service resolves, endpoint returns 200) | \n
regression | \nReproduces a specific previously-reported bug | \nReferences a bug ID, issue number, or describes a fix in its name or comments | \n
integration | \nCrosses process, network, or persistence boundaries | \nUses real database, HTTP client, file system, external service, or multi-component setup | \n
end-to-end | \nFull user workflow spanning the entire application stack | \nExercises a complete scenario from entry point to final result, distinct from single-boundary integration | \n
performance | \nValidates timing, throughput, or resource consumption | \nAsserts on elapsed time, memory, allocations, or uses benchmark harness (BenchmarkDotNet, pytest-benchmark, benchmark.js, JMH, go test -bench, criterion.rs, XCTMetric, kotlinx-benchmark, Google Benchmark) | \n
security | \nVerifies authentication, authorization, input sanitization, or secrets handling | \nTests for SQL injection, XSS, CSRF, unauthorized access, token validation, permission checks | \n
concurrency | \nValidates thread safety, parallelism, or async correctness | \nUses Task.WhenAll / Parallel.ForEach / SemaphoreSlim (.NET); asyncio.gather / threading.Lock / multiprocessing (Python); Promise.all / worker threads (JS/TS); CompletableFuture / ExecutorService / synchronized (Java); go func / sync.WaitGroup / sync.Mutex / chan (Go); Mutex / Thread.new (Ruby); tokio::spawn / Arc<Mutex<_>> / crossbeam (Rust); DispatchQueue / actor (Swift); coroutineScope / Mutex (Kotlin); Start-Job / RunspacePool (PowerShell); std::thread / std::mutex (C++); reproduces race conditions | \n
resilience | \nTests retry logic, timeouts, circuit breakers, or graceful degradation | \nAsserts behavior under transient failures, network drops, or service unavailability (e.g., Polly, tenacity, p-retry, resilience4j, hystrix, opossum, retry-go) | \n
destructive | \nMutates shared or external state that is hard to roll back | \nDeletes records, drops resources, modifies global config -- useful for CI isolation decisions | \n
configuration | \nVerifies settings loading, defaults, environment behavior | \nTests missing config keys, invalid values, environment variable fallbacks, options validation | \n
flaky | \nKnown to intermittently fail (meta-tag for test health tracking) | \nMark tests the team knows are unreliable; used to quarantine or prioritize stabilization | \n
A single test may have multiple traits (e.g., both negative and boundary). At minimum, every test should receive one of positive or negative.
Identify the codebase's language and test framework. Call the test-analysis-extensions skill and read the matching extension file. The extension file declares a tag-support capability for each framework:
auto-edit — framework has canonical tag syntax this skill can safely insert (.NET [TestCategory] / [Trait] / [Category] / [Property], pytest @pytest.mark.<name>, JUnit 5 @Tag(\"...\"), TestNG groups = {\"...\"}, RSpec metadata it \"...\" , :tag => true, Pester -Tag '...', Kotest @Tags(...), Swift Testing @Tag(.tagName), Catch2 [tag], doctest * doctest::test_suite(\"tag\") decorator).report-only — framework has no canonical, agreed-upon tag attribute; report tags in a Markdown table only and do not edit source (Go standard testing without build-tag conventions, Jest/Vitest without consistent describe-prefix convention, Rust without project-specific cfg conventions, XCTest without a test plan, GoogleTest without test-name prefix conventions, Mocha without describe-prefix conventions).convention-based — framework uses naming or file conventions for tagging (Go //go:build integration build tags, file-name suffixes like *_integration_test.go, GoogleTest INTEGRATION_* filter prefix). Only emit canonical edits when the user has confirmed the project convention; otherwise treat as report-only.Capture the capability before Step 4.
\nCheck which tests already have trait attributes. Use the loaded language extension as the source of truth — examples:
\n| Framework | \nExisting Attribute | \nExample | \n
|---|---|---|
| MSTest | \n[TestCategory(\"...\")] | \n[TestCategory(\"positive\")] | \n
| xUnit | \n[Trait(\"Category\", \"...\")] | \n[Trait(\"Category\", \"positive\")] | \n
| NUnit | \n[Category(\"...\")] | \n[Category(\"positive\")] | \n
| TUnit | \n[Property(\"Category\", \"...\")] | \n[Property(\"Category\", \"positive\")] | \n
| JUnit 5 | \n@Tag(\"...\") | \n@Tag(\"positive\") | \n
| TestNG | \n@Test(groups = {\"...\"}) | \n@Test(groups = {\"positive\"}) | \n
| pytest | \n@pytest.mark.<name> | \n@pytest.mark.positive | \n
| RSpec | \nmetadata after it | \nit \"...\", :positive do | \n
| Pester | \n-Tag '...' | \nIt '...' -Tag 'positive' | \n
| Kotest | \n@Tags(...) | \n@Tags(Positive) | \n
| Swift Testing | \n@Tag(.<name>) | \n@Test(.tags(.positive)) | \n
| Catch2 | \n[tag] in name | \nTEST_CASE(\"...\", \"[positive]\") | \n
| doctest | \n* doctest::test_suite(\"...\") decorator | \nTEST_CASE(\"...\" *doctest::test_suite(\"positive\")) | \n
Record which tests already have tags to avoid duplication.
\nFor each test method without traits, analyze:
\nInvalid, Fail, Error, Throw, Reject, BadInput, Null, None, Nil, Negative, raises_, _throws_, _returns_error suggest negativeAssert.ThrowsException / Assert.Throws / Should().Throw() / pytest.raises / expect(fn).toThrow / assertThrows / assert.Error(t, err) / expect { ... }.to raise_error / #[should_panic] / XCTAssertThrowsError / Should -Throw / EXPECT_THROW suggest negativenull / None / nil / undefined, \"\", 0, -1, int.MaxValue / sys.maxsize / Number.MAX_SAFE_INTEGER / math.MaxInt64 / i32::MAX, empty collections suggest boundarysmoke; external dependencies (file/db/net/env) suggest integrationregressionStopwatch, BenchmarkDotNet, elapsed-time checks; pytest-benchmark fixtures; benchmark.js; JMH @Benchmark; go test -bench; criterion.rs; XCTMetric; Google Benchmark; kotlinx-benchmark suggest performancecritical-pathsecurityconcurrencyresiliencedestructiveend-to-endconfigurationflakypositiveWhen in doubt between positive and negative, read the assertion: if it asserts success -> positive; if it asserts failure -> negative.
If the loaded language extension declares auto-edit for the framework, add the appropriate attribute to each test method. Place trait attributes adjacent to the existing test attribute. Examples:
MSTest:
\n[TestMethod]\n[TestCategory(\"negative\")]\n[TestCategory(\"boundary\")]\npublic void Parse_NullInput_ThrowsArgumentNullException() { ... }\nxUnit:
\n[Fact]\n[Trait(\"Category\", \"positive\")]\n[Trait(\"Category\", \"critical-path\")]\npublic void CreateOrder_ValidItems_ReturnsConfirmation() { ... }\nNUnit:
\n[Test]\n[Category(\"regression\")]\n[Category(\"negative\")]\npublic void Calculate_OverflowInput_ReturnsError() // Fix for #1234\n{ ... }\npytest:
\n@pytest.mark.negative\n@pytest.mark.boundary\ndef test_parse_none_input_raises_value_error():\n ...\nJUnit 5:
\n@Test\n@Tag(\"positive\")\n@Tag(\"critical-path\")\nvoid createOrder_validItems_returnsConfirmation() { ... }\nTestNG:
\n@Test(groups = {\"negative\", \"boundary\"})\npublic void parse_nullInput_throwsIllegalArgumentException() { ... }\nRSpec:
\nit \"rejects null input\", :negative, :boundary do\n ...\nend\nPester:
\nIt 'Rejects null input' -Tag 'negative','boundary' {\n ...\n}\nKotest:
\n@Tags(Negative, Boundary)\nclass ParserSpec : StringSpec({\n \"rejects null input\" { ... }\n})\nSwift Testing:
\n@Test(.tags(.negative, .boundary))\nfunc parseNullInputThrows() throws { ... }\nCatch2:
\nTEST_CASE(\"Parse null input throws\", \"[negative][boundary]\") { ... }\nIf the loaded language extension declares report-only for the framework (Go standard testing, plain Jest/Vitest without convention, Rust without project-specific cfg, plain XCTest, plain GoogleTest, plain Mocha), do NOT modify source files. Instead emit a Markdown table mapping each test to its suggested tags, and recommend a project-wide convention the team can adopt (build tags, file suffix, describe-block prefix, GoogleTest filter prefix, test-plan grouping, etc.).
If the loaded language extension declares convention-based (e.g., Go //go:build integration, *_integration_test.go, GoogleTest INTEGRATION_* prefix), only emit canonical edits when the user has confirmed the project's convention. Otherwise treat as report-only.
After tagging, produce a summary table:
\n## Trait Distribution\n\n| Trait | Count | % of Total |\n|---------------|-------|------------|\n| positive | 42 | 53.8% |\n| negative | 22 | 28.2% |\n| boundary | 8 | 10.3% |\n| critical-path | 12 | 15.4% |\n| smoke | 3 | 3.8% |\n| regression | 5 | 6.4% |\n| integration | 4 | 5.1% |\n| end-to-end | 2 | 2.6% |\n| performance | 1 | 1.3% |\n| security | 3 | 3.8% |\n| concurrency | 2 | 2.6% |\n| resilience | 1 | 1.3% |\n| destructive | 1 | 1.3% |\n| configuration | 2 | 2.6% |\n| flaky | 1 | 1.3% |\n| **Total tests** | **78** | -- |\n\nNote: Percentages exceed 100% because tests can have multiple traits.\nInclude observations such as:
\npositive or negative at minimum) — in the report for report-only frameworks, or as an attribute for auto-edit frameworksauto-edit frameworks, the project still builds / tests still discover after changes (dotnet build / pytest --collect-only / mvn test-compile / go vet ./... / cargo check --tests / npm run test:list / Invoke-Pester -PassThru -Skip / equivalent)report-only frameworks, no source files were modifiedconvention-based frameworks, edits were applied ONLY when a project convention was confirmed| Pitfall | \nSolution | \n
|---|---|
| Guessing traits without reading the test body | \nAlways read assertions and setup to classify accurately | \n
Tagging a test only as boundary without positive/negative | \nEvery test should also be positive or negative -- boundary is additive | \n
| Using the wrong attribute syntax for the detected framework | \nMatch the attribute style to the loaded language extension (don't put [TestCategory] in an xUnit project or @pytest.mark.x in a unittest test) | \n
| Duplicating an existing category attribute | \nCheck for pre-existing traits in Step 2 before adding | \n
Over-tagging as critical-path | \nReserve for tests on primary public entry points, not every helper | \n
| Editing Go / plain Jest / plain Rust / plain XCTest / plain GoogleTest source | \nThese are report-only by default — emit a Markdown table instead. Only edit if the user confirms a project-wide convention (build tag, file suffix, describe-prefix, test-plan grouping). | \n
| Inventing tag prefixes for convention-based frameworks | \nConfirm the project's existing convention before adopting one — don't guess between _integration_test.go, //go:build integration, or IntegrationTest prefix | \n
| Missing language-specific concurrency / async primitives | \nEach language has its own primitives — read the loaded language extension and the Trait Taxonomy concurrency row before classifying as concurrency | \n