If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/nextest-rs/nextest shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 2d ago
• 4 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Small team — 4 contributors active in recent commits
• ⚠ Concentrated ownership — top contributor handles 76% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live nextest-rs/nextest repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/nextest-rs/nextest.

What it runs against: a local clone of nextest-rs/nextest — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in nextest-rs/nextest | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 32 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of nextest-rs/nextest. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/nextest-rs/nextest.git
#   cd nextest
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of nextest-rs/nextest and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "nextest-rs/nextest(\\.git)?\\b" \\
  && ok "origin remote is nextest-rs/nextest" \\
  || miss "origin remote is not nextest-rs/nextest (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "cargo-nextest/src/main.rs" \\
  && ok "cargo-nextest/src/main.rs" \\
  || miss "missing critical file: cargo-nextest/src/main.rs"
test -f "cargo-nextest/src/dispatch/app.rs" \\
  && ok "cargo-nextest/src/dispatch/app.rs" \\
  || miss "missing critical file: cargo-nextest/src/dispatch/app.rs"
test -f "nextest-runner" \\
  && ok "nextest-runner" \\
  || miss "missing critical file: nextest-runner"
test -f "cargo-nextest/src/dispatch/core/run.rs" \\
  && ok "cargo-nextest/src/dispatch/core/run.rs" \\
  || miss "missing critical file: cargo-nextest/src/dispatch/core/run.rs"
test -f "nextest-metadata" \\
  && ok "nextest-metadata" \\
  || miss "missing critical file: nextest-metadata"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 32 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/nextest-rs/nextest"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Nextest is a next-generation test runner for Rust that replaces cargo test with a faster, more flexible alternative. It provides parallel test execution, advanced filtering via filtersets, structured output formats (JSON, JUnit), and is distributed as cargo-nextest, a cargo subcommand. The core value is dramatically faster test iteration and better insights into test results through features like per-test timeouts, partitioning for CI, and rich reporting. Monorepo workspace (Cargo.toml) containing: (1) cargo-nextest/ — the CLI entry point, (2) nextest-runner/ — core test execution engine, (3) nextest-metadata/ — library for programmatic invocation, (4) nextest-filtering/ — DSL parser for test filtersets, (5) fixture-data/ and internal-test/ for testing. Configuration lives in .config/nextest.toml and .config/hakari.toml (workspace hack for dependency tree consistency). Build orchestration via .github/workflows/ and .github/buildomat/.

Rust developers and project maintainers who run large test suites and want faster feedback cycles. CI/CD engineers integrating Rust projects into pipelines who need structured test output (JUnit XML) and test partitioning across machines. Developers authoring Rust libraries and binary projects who want nextest available as a drop-in replacement for cargo test.

Production-ready and actively developed. The repo shows ~3.9M lines of Rust code across 4 crates, comprehensive CI across multiple platforms (.github/workflows/ci.yml, .github/buildomat for illumos, Cross.toml for cross-compilation), and regular releases. The MSRV is explicitly defined (1.91 for building, 1.41 for running). Multiple published crates on crates.io (cargo-nextest, nextest-runner, nextest-metadata, nextest-filtering) with versioning discipline (pre-1.0 allowing MSRV bumps in patch releases).

Low risk for stability but moderate maintenance load. The project is a single-crate published tool (cargo-nextest) with stable library interfaces (nextest-runner, nextest-metadata, nextest-filtering), reducing vendor lock-in. Dependencies are well-managed via workspace.dependencies (e.g., tokio, clap, camino). However, as a test infrastructure tool, breaking changes to the filtering DSL or JSON output schema could affect downstream CI systems—the repo addresses this via versioning (editions in Cargo.toml). Activity is steady but the project is core infrastructure, making it a maintenance responsibility.

Active development with focus on test infrastructure improvements. The repo has a .claude/ directory with skills for changelog preparation, suggesting recent tooling investment. GitHub workflows include coverage.yml (codecov integration), hakari.yml (for dependency checking), and zizmor.yml (security scanning). Recent changes likely touch nextest-filtering (DSL improvements), nextest-runner (execution optimizations), and CLI ergonomics in cargo-nextest. Renovate automation (.github/renovate.json) keeps dependencies current.

Clone, setup Rust 1.91+, and build:

git clone https://github.com/nextest-rs/nextest.git
cd nextest
cargo build --release -p cargo-nextest
./target/release/cargo-nextest --help

For testing locally:

cargo test --all

For running nextest on its own test suite (dogfooding):

cargo nextest run

Daily commands: Development loop:

cargo build
cargo test --all
cargo nextest run  # Test nextest with itself
cargo run -p cargo-nextest -- nextest run  # Test fixture projects

For documentation:

cargo doc --open --package nextest-runner

• cargo-nextest/src/main.rs — Entry point for the cargo-nextest CLI; handles command dispatch and argument parsing
• cargo-nextest/src/dispatch/app.rs — Core application dispatcher that routes commands (run, list, archive, replay) to their handlers
• nextest-runner — Core library containing test execution engine, filtering, and result aggregation logic
• cargo-nextest/src/dispatch/core/run.rs — Implements the main nextest run command; orchestrates test execution and reporting
• nextest-metadata — Serializable metadata structures for test discovery, execution results, and interop with cargo-nextest
• cargo-nextest/Cargo.toml — Workspace configuration and dependency management for the cargo-nextest binary
• .config/nextest.toml — Default nextest configuration schema and example; defines all configurable test execution behavior

Add a new test filtering option

1. Define the new filter enum variant in nextest-filtering crate (nextest-filtering)
2. Add CLI argument in dispatch/common.rs under filter-related options (cargo-nextest/src/dispatch/common.rs)
3. Implement filter logic in dispatch/core/filter.rs query handler (cargo-nextest/src/dispatch/core/filter.rs)
4. Integrate filter application into nextest-runner's test execution loop (nextest-runner)
5. Add integration test case in integration-tests or nextest-runner tests (cargo-nextest/src/dispatch/core/tests.rs)

Add a new output format (e.g., SARIF, Cucumber)

1. Add variant to OutputFormat enum in dispatch/core/value_enums.rs (cargo-nextest/src/dispatch/core/value_enums.rs)
2. Create formatter module in nextest-runner with serialization logic (nextest-runner)
3. Wire formatter into nextest-runner's result sink in run.rs (cargo-nextest/src/dispatch/core/run.rs)
4. Add serializable metadata types to nextest-metadata if needed (nextest-metadata)
5. Test with fixture-project and update snapshot tests (cargo-nextest/src/snapshots)

Add a new configuration profile setting

1. Update config schema in .config/nextest.toml with new profile field (.config/nextest.toml)
2. Add field to ConfigProfile struct (typically in nextest-runner config module) (nextest-runner)
3. Parse and apply setting in dispatch/core/run.rs command handler (cargo-nextest/src/dispatch/core/run.rs)
4. Integrate setting into nextest-runner's test executor loop (nextest-runner)
5. Add integration test with fixture-project using new setting (integration-tests)

• Tokio (async/await) — Parallel test execution with minimal thread overhead; enables efficient polling of many test process exits
• Clap for CLI — Type-safe argument parsing with automatic help/shell completion generation
• Cargo subprocess integration — Reuses existing cargo build infrastructure; avoids reimplementing Rust compilation
• Serde for serialization — Portable metadata format for test results; enables machine-readable output (JUnit, JSON)
• Camino for paths — UTF-8 path handling across Windows/Unix; cleaner than std::path::PathBuf in most code

• Async/tokio-based execution rather than rayon thread pools

  • Why: Tokio provides better interleaving of I/O (reading test output) and CPU (spawning processes) without OS thread overhead
  • Consequence: Adds tokio runtime dependency and async complexity, but achieves better scalability on machines with hundreds of tests

• Separate nextest-runner, nextest-metadata, and nextest-filtering libraries

  • Why: Allows third-party tools and build systems to reuse core orchestration logic without pulling in the entire CLI
  • Consequence: More crates to maintain and coordinate; each must maintain backwards-compatible APIs

• Stateless test execution (no persistent test database)

  • Why: Simpler architecture; tests are discovered fresh each run or cached locally
  • Consequence: Cannot support advanced features like test flakiness tracking across machines; suitable for local dev but not enterprise dashboards

• TOML-based configuration over environment variables or inline options

  • Why: Readable, hierarchical config; supports multiple profiles and inheritance
  • Consequence: Slightly higher overhead (config parsing at startup); users must understand TOML syntax

• Does not manage test infrastructure (CI/CD runners, distributed test systems)
• Does not provide persistent test reporting or dashboards (stateless per-run)
• Does not support non-Rust test binaries (expects cargo-built Rust test harness output)
• Does not provide real-time remote test result streaming (focuses on local execution)
• Not a replacement for Cargo; integrates with Cargo, does not reimplement it

1. MSRV split: Rust 1.41 to run nextest, but 1.91+ to build it—don't assume older Rust versions work for development. 2. Workspace hack: workspace-hack/ crate is auto-managed by hakari; don't manually edit Cargo.toml entries it controls. 3. Feature gating: cargo-nextest has 'default-no-update' feature disabled by default in workspace dependencies to prevent self-update in packaged builds—see workspace.dependencies comment in Cargo.toml. 4. Edition 2024 is specified but may not be stable; check rust-version pinning carefully. 5. Test output snapshots use insta with rules from .config/insta.yaml; snapshot updates require cargo insta review. 6. Cross-platform paths use camino throughout; standard std::path::Path may break Windows compatibility.

• Filtersets DSL — Nextest's killer feature for test selection—understanding the filterset grammar and parser is essential to extending test filtering capabilities beyond glob patterns
• Test partitioning (shard-count, shard-index) — Critical for distributing test loads across CI machines; nextest partitions deterministically so you can run disjoint test subsets in parallel without coordination
• libtest protocol — Nextest parses Rust's test binary protocol (--test-threads, --list, etc.) to discover and invoke tests; understanding the protocol explains why nextest can't run arbitrary binaries
• Work-stealing task scheduler — Nextest's parallel execution uses tokio for async task scheduling; the efficiency comes from intelligent work distribution, not just thread count
• JUnit XML format — Nextest outputs JUnit XML for CI integration (GitHub, Jenkins, etc.); understanding the schema is necessary when debugging CI reporter integration
• Cargo metadata JSON — Nextest uses cargo metadata to introspect the project (discover tests, resolve paths); the JSON schema is parsed by nextest-metadata library
• Per-test timeout and profile selection — Nextest allows .config/nextest.toml to define profiles with different timeout thresholds and retry policies per test; this is why flaky tests can be isolated from strict ones

• rust-lang/rust — The standard Rust test infrastructure that nextest replaces; understanding libtest is essential context for why nextest exists
• taiki-e/cargo-hack — Complementary tool for testing Rust projects (feature powerset, MSRV validation); often used alongside nextest in CI
• olix0r/linkerd2-proxy — Large Rust project that uses nextest in production CI; good reference for real-world test configuration patterns
• nextest-rs/public-api-scopes — Companion repo exploring public API stability patterns for Rust, relevant to nextest's versioning strategy
• cargo-generate/cargo-generate — Complementary Rust project templating tool; both are cargo subcommands and share distribution/installation patterns

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for cargo-nextest dispatch/clap error handling

The cargo-nextest dispatch module (cargo-nextest/src/dispatch/) contains critical CLI argument parsing and error handling code (clap_error.rs, app.rs, common.rs, helpers.rs), but there's no dedicated test file visible in cargo-nextest/src/dispatch/. The integration-tests/ workspace member exists but likely doesn't comprehensively cover edge cases in clap error formatting, argument validation, and user-facing error messages. This would improve reliability of the CLI experience and catch regressions early.

• [ ] Create cargo-nextest/src/dispatch/tests.rs (or expand existing cargo-nextest/src/dispatch/core/tests.rs pattern)
• [ ] Add tests for invalid flag combinations (e.g., conflicting --test-threads arguments)
• [ ] Add tests for clap_error.rs error formatting with various terminal widths
• [ ] Add tests for common.rs argument parsing edge cases
• [ ] Run cargo test --package cargo-nextest to verify new tests pass

Add missing .claude/skills for common contributor workflows

The .claude/ directory exists with a prepare-changelog skill, but there are no skills for other common workflows (running tests locally, building docs, setting up a dev environment, understanding the architecture). The CONTRIBUTING.md likely documents these, but structured .claude/skills/ make it easier for new contributors to self-serve. This lowers friction for first-time contributors.

• [ ] Create .claude/skills/local-development-setup/SKILL.md with steps to build cargo-nextest and run nextest on itself
• [ ] Create .claude/skills/adding-new-test-filter/SKILL.md referencing nextest-filtering/ workspace member and nextest-runner integration
• [ ] Create .claude/skills/writing-integration-tests/SKILL.md referencing the integration-tests/ workspace member patterns
• [ ] Ensure each SKILL.md references specific files (e.g., Justfile, Cargo.toml, CI workflows) for context
• [ ] Link these skills from CONTRIBUTING.md

Add GitHub Actions workflow for nextest self-hosted test completeness verification

The repo has ci.yml, coverage.yml, and release-test.yml workflows, but there's no automated workflow to verify that nextest itself passes its own test suite using various configurations (e.g., different --test-threads, --jobs values, with filtering enabled/disabled). This ensures the dogfooding aspect works and catches regressions in nextest's own testing infrastructure. The .config/nextest.toml and .config/insta.yaml suggest complex test configuration that should be validated in CI.

• [ ] Create .github/workflows/nextest-self-test.yml workflow
• [ ] Add job that runs: cargo nextest run --all with default config
• [ ] Add job that runs: cargo nextest run --all --test-threads=1 (single threaded)
• [ ] Add job that runs: cargo nextest run --all with filtering patterns (e.g., --filter 'test(integration)')
• [ ] Add job that verifies .config/nextest.toml is syntactically valid and used correctly
• [ ] Ensure workflow runs on PR and main branch pushes

• Add documentation and examples for the nextest-metadata library in nextest-metadata/src/lib.rs—this is the programmatic API that's currently under-documented compared to the CLI, and writing guide docs with code examples would help downstream consumers
• Implement a new reporter output format (e.g., GitHub Actions annotation format) by extending nextest-runner/src/reporter/—this is self-contained, has clear precedent in JSON/JUnit reporters, and would unlock native CI/CD integration
• Add missing integration tests for filtersets edge cases in nextest-filtering/ by expanding the test suite to cover complex DSL combinations like 'test(foo) AND package(bar) BUT NOT test(baz)'—the parser exists but test coverage is likely incomplete

The codebase demonstrates generally good security practices. No critical vulnerabilities were identified in the static analysis of the provided configuration and file structure. The primary concerns are minor configuration issues (invalid Rust edition declaration) and best-practice recommendations around dependency management and feature flag handling. The project appears well-maintained with proper licensing, code of conduct, and security-conscious design (e.g., intentional disabling of self-update by default). Recommend validating the edition field and ensuring comprehensive documentation of dependency management strategies.

• Low · Outdated Rust Edition Declaration — Cargo.toml - workspace.package.edition. The Cargo.toml specifies edition = "2024" which does not exist. Rust editions are 2015, 2018, and 2021. This appears to be a placeholder or configuration error that could cause build failures or unexpected behavior. Fix: Update to a valid Rust edition (2021 recommended for modern projects). Verify: [workspace.package] edition = "2021"
• Low · Permissive Workspace Exclusion Pattern — Cargo.toml - workspace.package.exclude. The workspace.exclude pattern targets specific agent and Claude documentation files, but this approach may not catch all sensitive documentation. The exclusion is too narrow and could miss similarly named files. Fix: Review if AGENTS.md and CLAUDE.md contain sensitive information. Consider using a more comprehensive exclusion strategy or ensuring sensitive files are not checked into version control.
• Low · Self-Update Feature Configuration — Cargo.toml - workspace.dependencies.cargo-nextest. The cargo-nextest dependency uses 'default-no-update' feature flag to prevent self-update by default. While this is a reasonable security decision, the comment indicates this was done to prevent accidental feature unification. This suggests potential complexity in dependency management. Fix: Ensure that all distributors and packagers are aware of the self-update feature flag behavior. Document this in CONTRIBUTING.md or distribution guidelines.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.