---

name: test-tagging description: > Classifies existing tests by standard traits and reports their distribution. USE FOR: tagging all tests with category attributes, categorizing/tagging/ labeling each test, compare happy vs error paths, audit the test mix, describe coverage shape by test type, or tag then verify the project builds. Read bodies when names mislead. Apply canonical attributes; otherwise report only. DO NOT USE FOR: requests owned by test-anti-patterns, coverage-analysis, crap-score, test-gap-analysis, code-testing-agent, or migration skills. license: MIT

Test Trait Tagging

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.).

Language-specific guidance: Try test-analysis-extensions once. If it is unavailable, continue immediately with the built-in framework table below; never block tagging on the helper.

When to Use

• Auditing a test project to understand the mix of test types
• Adding trait attributes to untagged tests
• Generating a summary report of trait distribution across a test suite
• Reviewing whether critical paths have sufficient coverage

When Not to Use

• Writing new tests from scratch (use code-testing-agent for any language, or writing-mstest-tests for MSTest)
• Running or filtering tests (use run-tests for .NET; equivalent native runners elsewhere)
• Migrating between test frameworks
• General quality, smell, flakiness, or assertion audits (use test-anti-patterns or the matching analysis skill)
• Diagnostic .NET executed line/branch/Cobertura interpretation or project-wide CRAP risk (use coverage-analysis); raw coverage collection (use run-tests for .NET, native tooling otherwise)
• CRAP analysis for a named method, class, or file (use crap-score)
• Behavioral gaps where a test would survive broken production logic (use test-gap-analysis)

Inputs

| Input | Required | Description | |-------|----------|-------------| | Test project or files | No | Path to the test project, folder, or specific test files. Discover from the current workspace when omitted. | | Scope | No | Infer from the verb: tag/apply edits, audit/classify/report is report-only, and both applies only when both are requested. If ambiguous, default to audit to avoid unrequested edits. Frameworks declared report-only always emit a report; convention-based frameworks edit only after the user confirms the convention. | | Framework | No | Auto-detected. Override when detection fails. |

Trait Taxonomy

Use exactly these trait names and values. Do not invent new trait values outside this table.

| Trait Value | Meaning | Heuristics | |-------------|---------|------------| | positive | Verifies expected behavior under normal/valid conditions | Asserts success, valid output, expected state, no exceptions for valid input | | negative | Verifies correct handling of invalid input, errors, or edge cases | Asserts exceptions, error codes, validation failures, rejects bad input | | boundary | Tests limits, thresholds, empty/null/None/nil inputs, min/max values | Operates 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 | | critical-path | Core workflow that must never break; breakage blocks users | Tests the primary success scenario of a key public API or user-facing feature | | smoke | Quick sanity check that the system is operational | Fast, no complex setup, verifies basic wiring (e.g., service resolves, endpoint returns 200) | | regression | Reproduces a specific previously-reported bug | References a bug ID, issue number, or describes a fix in its name or comments | | integration | Crosses process, network, or persistence boundaries | Uses real database, HTTP client, file system, external service, or multi-component setup | | end-to-end | Full user workflow spanning the entire application stack | Exercises a complete scenario from entry point to final result, distinct from single-boundary integration | | performance | Validates timing, throughput, or resource consumption | Asserts 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) | | security | Verifies authentication, authorization, input sanitization, or secrets handling | Tests for SQL injection, XSS, CSRF, unauthorized access, token validation, permission checks | | concurrency | Validates thread safety, parallelism, or async correctness | Uses 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 | | resilience | Tests retry logic, timeouts, circuit breakers, or graceful degradation | Asserts behavior under transient failures, network drops, or service unavailability (e.g., Polly, tenacity, p-retry, resilience4j, hystrix, opossum, retry-go) | | destructive | Mutates shared or external state that is hard to roll back | Deletes records, drops resources, modifies global config -- useful for CI isolation decisions | | configuration | Verifies settings loading, defaults, environment behavior | Tests missing config keys, invalid values, environment variable fallbacks, options validation | | flaky | Known to intermittently fail (meta-tag for test health tracking) | Mark tests the team knows are unreliable; used to quarantine or prioritize stabilization |

A single test may have multiple traits (e.g., both negative and boundary). At minimum, every test should receive one of positive or negative.

Workflow

Step 1: Detect the language, framework, and tagging capability

Resolve the requested test scope from the current workspace before asking for a path. The skill context's Base directory contains these instructions, not the user's repository. Always inspect the current working directory before claiming that repository files are unavailable. If the prompt's relative path is absent, search the workspace for the named project/file and retry the exact result. A successful search proves that the target is present; if the normal reader then reports that same path missing, treat the contradiction as a reader path-normalization or transport failure rather than asking the user for files. Use a shell text reader (sed/cat on Unix, Get-Content on PowerShell) only for a confirmed reader availability, transport, or path-normalization failure and only after verifying the canonical path remains inside the current workspace. Stop on content-exclusion, permission/policy, workspace-boundary, or unknown read failures. Never ask the user for a path or file contents after a workspace search found a readable target.

For an auto-edit framework, a failed patch/editor call is not a stopping condition only when the failure is confirmed tool availability, transport, or path normalization. Do not bypass stale-context, concurrent-change, permission/policy, or path-boundary errors. Before a shell fallback, resolve the canonical path inside the current workspace, freshly read the file, and use an anchored transformation that aborts unless the expected old text and exact match count are unchanged. Then re-open the complete file, inspect the diff, and run Step 6 validation. Do not report proposed attributes as completion when the user asked to apply them.

Identify the language and framework. Try the matching test-analysis-extensions guidance once. If unavailable, classify capability from the built-in rules below:

• 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.

Also lock the requested mode before classification. Do not turn an audit into source edits because canonical attributes are available; edit only for an explicit tagging/apply request.

Step 2: Scan existing traits

Check which tests already have trait attributes. Use the extension when loaded; otherwise use this built-in table as the source of truth:

| Framework | Existing Attribute | Example | |-----------|--------------------|---------| | MSTest | [TestCategory("...")] | [TestCategory("positive")] | | xUnit | [Trait("Category", "...")] | [Trait("Category", "positive")] | | NUnit | [Category("...")] | [Category("positive")] | | TUnit | [Property("Category", "...")] | [Property("Category", "positive")] | | JUnit 5 | @Tag("...") | @Tag("positive") | | TestNG | @Test(groups = {"..."}) | @Test(groups = {"positive"}) | | pytest | @pytest.mark.<name> | @pytest.mark.positive | | RSpec | metadata after it | it "...", :positive do | | Pester | -Tag '...' | It '...' -Tag 'positive' | | Kotest | @Tags(...) | @Tags(Positive) | | Swift Testing | @Tag(.<name>) | @Test(.tags(.positive)) | | Catch2 | [tag] in name | TEST_CASE("...", "[positive]") | | doctest | * doctest::test_suite("...") decorator | TEST_CASE("..." *doctest::test_suite("positive")) |

Record which tests already have tags to avoid duplication.

Step 3: Classify each test method

Build one canonical inventory containing each discovered test exactly once. Record the test identifier, behavioral classification, and traits in that inventory; use the same rows for source edits, per-test reporting, totals, and distribution counts. Do not hand-count a separate denominator. Before publishing, reconcile the reported total with the number of inventory rows and verify that every row contributes to each displayed trait count.

For each test method without traits, analyze:

1. Method name -- names containing Invalid, Fail, Error, Throw, Reject, BadInput, Null, None, Nil, Negative, raises_, _throws_, _returns_error suggest negative
2. Assertion type -- Assert.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 negative
3. Input values -- null / None / nil / undefined, "", 0, -1, int.MaxValue / sys.maxsize / `Number.MAX