dwalleck

Generates and writes new unit tests for any programming language using a Research-Plan-Implement-Validate pipeline, orchestrated by the main agent through IDE subagents. Use when asked to generate tests, write unit tests, add tests, improve test coverage, create test project, achieve high coverage, comprehensive tests, or asked to scaffold a new test project for an app, service, or library. Supports C#, TypeScript, JavaScript, Python, Go, Rust, Java, and more. You (the main agent) launch the code-testing-researcher-ide, code-testing-planner-ide, code-testing-implementer-ide, and code-testing-validator-ide subagents in sequence so tests compile, pass, and follow project conventions. DO NOT USE FOR: running existing tests or test filters (use run-tests); diagnosing coverage plateaus or project-wide coverage/CRAP analysis without writing tests (use coverage-analysis); targeted method/class CRAP scores (use crap-score); MSTest assertion guidance, MSTest test pattern modernization, or fixing existing MSTest test c

Generates and writes new unit tests for any programming language using a Research-Plan-Implement pipeline. Use when asked to generate tests, write unit tests, add tests, improve test coverage, create test project, achieve high coverage, comprehensive tests, or asked to scaffold a new test project for an app, service, or library. Supports C#, TypeScript, JavaScript, Python, Go, Rust, Java, and more. Orchestrates the code-testing-generator sub-agent through research, planning, and implementation phases so tests compile, pass, and follow project conventions. DO NOT USE FOR: running existing tests or test filters (use run-tests); diagnosing coverage plateaus or project-wide coverage/CRAP analysis without writing tests (use coverage-analysis); targeted method/class CRAP scores (use crap-score); MSTest assertion guidance, MSTest test pattern modernization, or fixing existing MSTest test code (use writing-mstest-tests).

Migrate xUnit, NUnit, or MSTest test suites to TUnit. Use whenever the user wants to port tests from another framework to TUnit, or asks how to convert specific patterns: [Fact]/[Theory]/[InlineData]/IClassFixture (xUnit), [TestCase]/[TestCaseSource]/[SetUp]/[OneTimeSetUp] (NUnit), [TestClass]/[TestMethod]/[DataRow]/[DynamicData]/[TestInitialize] (MSTest). Covers attribute mapping tables, the assertion-shape change to `await Assert.That(...).IsEqualTo(...)`, the project-file changes (Microsoft.Testing.Platform, dotnet run vs dotnet test), the async-Task-by-default test signature, and the universal pitfalls when switching from sync-result Assert.Equal to awaited Assert.That.

Make TUnit test projects work under NativeAOT, IL trimming, and single-file publishing. Use when the user is publishing a TUnit test project with PublishAot=true, hits TUnit0058 errors about generic tests, sees IL2026/IL3050 trim warnings on test data sources, asks about [GenerateGenericTest], or needs to combine [ClassConstructor<T>] with the trimmer's DynamicallyAccessedMembers requirements. Also use when the user asks how to keep custom IClassConstructor or DataSourceGenerator implementations AOT-safe, or what restrictions apply to data sources under AOT (no reflection-based generators, static methods only).

TUnit's source-generated, AOT-compatible mocking framework — TUnit.Mocks. Use whenever the user is mocking dependencies in TUnit tests, references Mock.Of<T>(), `.Mock()` extension methods, `Any()`, `Is<T>(...)`, `WasCalled(Times.Once)`, or asks how to stub HttpClient/ILogger/ILogger<T> in TUnit. Also use when the user mentions the TUnit.Mocks, TUnit.Mocks.Http, or TUnit.Mocks.Logging packages, or asks how to verify mock calls without Moq/NSubstitute. Covers mock creation, setup (Returns/Throws/Callback/sequences/properties), argument matchers, call verification with the Times constraints, ordered verification, HTTP request matching and verification, and ILogger entry assertions.

Write new MSTest unit tests and implement concrete fixes in existing MSTest code using MSTest 3.x/4.x modern APIs and best practices. USE FOR: write unit tests for a class, write MSTest tests, create test class, fix test assertions, MSTest assertion APIs (StartsWith, EndsWith, MatchesRegex, IsGreaterThan, IsInRange, HasCount, IsNull), something seems off with my tests, review tests and fix issues, fix swapped Assert.AreEqual arguments, replace ExpectedException with Assert.Throws, modernize test patterns, convert DynamicData to ValueTuples, data-driven tests, test lifecycle setup, sealed test classes, async test patterns, cancellation token testing, test parallelization, Parallelize, DoNotParallelize, MSTest.Sdk project setup. DO NOT USE FOR: broad test quality audits or test smell detection (use test-anti-patterns), running tests (use run-tests), MSTest version migration (use migrate-mstest-v1v2-to-v3 or migrate-mstest-v3-to-v4), or non-.NET languages (Python/JS/Go/Java/etc.) — this is .NET-only.

Best practices for writing TUnit unit and integration tests. Use whenever the user is writing, fixing, reviewing, or modernizing TUnit tests, or asks about [Test], [Arguments], [Before(Test)]/[After(Test)], [MethodDataSource], [ClassDataSource], [MatrixDataSource], hooks, lifecycle, parallelism, timeouts, or `await Assert.That(...)`. Also use when the user references TUnit attributes without naming the framework, or when test files import `TUnit.Core` / `TUnit.Assertions`. Covers project setup on Microsoft.Testing.Platform, the async-by-default model, data-driven tests, lifecycle hooks at four scopes, parallelism control, retries, skipping, and the awaited-assertion pattern.

HttpContext lifecycle and thread-safety violations in ASP.NET Core - fire-and-forget patterns capturing HttpContext or scoped services, sync-over-async on request/response bodies, accessing HttpContext from parallel tasks or after request completion, response header timing after body writes.

Replaces brainstorming for feature design. Produces a design where every claim is paired with an experiment that would prove it wrong, and the cheapest such experiment runs before the design is approved. Refuses to run until prove-it-prototype has produced agreement between probe and oracle.

REQUIRED before prove-it-prototype when a feature request originates from a human in natural language. Interrogates the requester one question at a time until every vague noun is resolved, every success criterion is measurable, every edge case has an explicit decision, every "TBD" is closed, and the requester has signed off in their own words. Refuses to proceed until the artifact has zero hand-waving.

REQUIRED before any design or plan when adding a feature to a system you did not personally write. Build a 30-50 line probe that produces the proposed feature's output against the real codebase, define an independent oracle that computes the same answer a different way, and refuse to proceed until probe and oracle agree.

Replaces executing-plans. Executes slices one at a time. After each slice, runs the slice's stress fixture AND the prove-it-prototype oracle against the binary AND the budget check. If any of those fail, STOPS and surfaces the drift to the user. Treats the plan as a hypothesis, not a contract.

Use when responding to PR review feedback (human or bot) before applying any changes. Treats each finding as a hypothesis to verify, not an instruction to follow. Decides per finding whether the bug claim is real AND whether the proposed fix is right AND whether to accept, modify, or reject. Refuses to apply changes without per-finding verification.

Replaces writing-plans. Decomposes a falsifiable design into small slices, each with mandatory complexity budget, scale budget, stress fixture, and oracle. Refuses to run until falsifiable-design has produced an approved design with a passing cheapest-falsifier.

A scoped TDD discipline. Use for unit tests inside a slice during checkpointed-build. Adds two mandatory steps beyond GREEN — BUDGET and ORACLE — and treats TDD as one tool in a larger spiral, not the whole methodology.

**ALWAYS USE** when working with Rust code. This skill contains 45 rules that prevent common bugs. Trigger on ANY of these: - Editing .rs files or Cargo.toml - Writing new Rust functions, structs, enums, or impl blocks - Reviewing Rust code before committing - Debugging Rust errors (borrow checker, Option/Result, lifetimes) - Working with: unwrap, expect, ?, Option, Result, Path, PathBuf - File I/O operations in Rust (read, write, atomic writes) - CLI development with clap - Error handling patterns - Functions returning Option or Result that might fail silently - Path operations (canonicalize, file_name, parent, extension) - Deserializing JSON/YAML/TOML from external sources Key rules to apply: - Rule 35: Log before returning None (prevent silent failures) - Rule 36: Return Err for invalid input, not empty collections - Rule 37: Canonicalize paths at system boundaries - Rule 39: Every public method needs tests - Rule 40: Validate untrusted data at point of use - Rule 41: Audit ergonomic error suppressors (.

Run cargo audit and triage advisories by crate scope. Use whenever bumping dependencies, editing Cargo.toml or Cargo.lock, or investigating a RUSTSEC advisory. Also triggers on user phrases like "audit deps", "check CVEs", "are our dependencies safe".

Analyzes the variety and depth of assertions across test suites in any supported language. Use when the user asks to evaluate assertion quality, find shallow testing, identify tests with only trivial assertions, measure assertion diversity, or audit whether tests verify different facets of correctness. Produces metrics and actionable recommendations. Supports Rust and .NET (MSTest, xUnit, NUnit, TUnit). Also detects implicit assertions, panic/exception testing, mock verification, and framework-specific patterns. DO NOT USE FOR: writing new tests, detecting general anti-patterns, or fixing existing assertions — help the user directly with those.

Run cargo check after Rust file modifications to catch compile errors early

Run the full issue-to-merge pipeline for one tethys rivets issue — verify/pick the issue, branch, gilfoyle loop (probe → falsifiable design → HARD PAUSE for approval → plan → checkpointed build), pre-PR code review with fixes, open PR, watch CI, merge on green after confirmation, close the issue. Use whenever the user says "ship <issue-id>", "work tethys-XXXX", "pick the next issue and build it", "run the pipeline", or asks to take any rivets issue end-to-end — even if they don't say "ship".

Batch-close small tethys bugs in parallel — select 2-4 small P2-P4 ready bugs from rivets, fan out worktree-isolated subagents (reproduce → minimal fix → regression fence → PR each), watch CI, merge serially, close the issues. Use whenever the user says "sweep bugs", "burn down the bug backlog", "close some small bugs", "work a few bugs in parallel", or complains that issues are being opened faster than closed.

Secret safety for AWS Secrets Manager, secret management, credentials, API keys, tokens, and passwords. Prevents AI agents from directly fetching secret values and teaches runtime dynamic references with asm-exec so plaintext never enters the LLM context window.

Builds, deploys, manages, debugs, configures, and optimizes serverless applications on AWS using Lambda, API Gateway, Step Functions, EventBridge, and SAM/CDK. Covers cold starts, CORS debugging, event source mappings, troubleshooting, concurrency, SnapStart, Powertools, function URLs, EventBridge Scheduler, Lambda layers, and production readiness. Triggers on mentions of Lambda, API Gateway, Step Functions, SAM templates, CDK serverless stacks, DynamoDB stream triggers, SQS event sources, cold starts, timeouts, 502/504 errors, throttling, concurrency, CORS, Powertools, or any event-driven architecture on AWS, even without the word "serverless." Does not apply to EC2, ECS/Fargate containers, or Amplify hosting.

Comprehensive Rust development guidelines based on 6 months of code reviews. Use when writing Rust code, debugging Rust issues, or reviewing Rust PRs. Covers error handling, file I/O safety, type safety patterns, performance optimization, common footguns, and fundamental best practices. Perfect for both new and experienced Rust developers working on CLI tools, hooks, or production code.

Expert evaluator for Grafana Loki label strategy. Audits, designs, and improves label schemas using cardinality scoring, access-pattern alignment, static vs. dynamic label rules, and consistency checks. Use when the user asks to evaluate, audit, design, or improve a Loki label strategy — or asks why their Loki queries are slow.

A demo skill used for discovery tests.