repo-test-architect

Repo Test Architect is an evidence-first test strategy auditing tool for real codebases. Its core idea is: before letting any model or agent reason about tests, first build a deterministic audit graph. This graph is based on the facts that the tool can inspect locally, including project roots, framework signals, existing tests, source classification, blockers, and residual risks, thereby identifying repository-native, high-value testing work.

Main capabilities

• Adapter coverage: can audit JavaScript/TypeScript, PHP, Python, Ruby, and Swift projects, and audit Kotlin/JVM, Go, Rust, C# (.NET), and Elixir through bounded adapters. Dart/Flutter remains experimental.
• Project detection: can detect multilingual project roots and report unsupported ecosystems, avoiding conflating "not yet audited" with "does not exist."
• A single audit outputs the full set of results: including complete repository analysis, findings, candidate ranking, test plans, execution prompts, and validation commands.
• Source classification and ranking: classifies source files by likely testing value, defers low-value direct testing; ranks test candidates based on the audit graph and generates test plans.
• Execution prompts: generates provider-agnostic execution, context, parallel-safety, and repository-reasoning prompts, but does not select models or generate subagents.
• Test placement analysis: performs conservative test placement discovery across project boundaries.
• Project statistics: collects project-level statistics such as coverage, candidate counts, frameworks, commands, and adapter usage.
• Local MCP diagnostics: off by default, provides safe internal error report IDs, runtime checks, and inspectable redacted bundles, with no external reporting.
• Multiple entry points: exposes the same deterministic behavior through CLI commands, local invocation tools, and a stdio MCP SDK server.
• Stability guarantees: locks behavior through golden snapshots, model consistency scenarios, package checks, and cross-OS CI.

How to use Requires Node.js 20 or higher. You can run the CLI directly without a global install, pin a stable version, or install the CLI and MCP server binaries. You can add the local stdio MCP server to an MCP-capable client and pin its version. The client starts the server locally, and repository source code stays on the local machine unless the client or another configured tool sends it elsewhere. Once connected, the model receives instructions to start with analyze_repository for routineSpecification repository review.

For users who want to review the current repository in a human-readable way, the analyze command can be run. It detects each project root, runs once for each supported adapter, and derives an audit summary, key findings, candidate ranking, test plan, execution hints, project statistics, and verification commands. Markdown output stays compact, while JSON preserves the full evidence bundle. Centralized views can also be used, such as listing registered adapters, checking project detection marker rules, detecting project roots and adapter matches, reusing saved project audit artifacts, outputting a structured audit graph, generating an actionable test plan from the audit graph, deriving suggested execution hints without changing the plan artifacts, and so on.

For MCP-connected models, the default equivalent tool is analyze_repository. Use narrower tools only when the request requires a single artifact or audit artifacts have already been provided. Installing the CLI or agent host is still responsible for model selection, budget, permissions, context loading, and sub-agent lifecycle.

Available adapters

• dart (experimental): Dart and Flutter pubspec packages, regular package:test and flutter_test entry points, precise library import evidence, widget test suggestions, and bounded dart test / flutter test commands.
• csharp: a static SDK-style test project or a unique literal production/test project edge, including bounded native xUnit MTP-v2 and MSTest.Sdk v4 ownership, precise literal or one-hop root alias target members, a direct *.cs compilation include within the repository, limited project-local target conditional package predicates, and selecting a pair in unrelated projects, paired with bounded nearest file Directory.Build.props metadata and static Directory.Packages.props versions, supporting xUnit, NUnit, or MSTest characteristic tests, precise project file commands, runnable body-owned direct type calls, bounded concrete local or immutable test field receivers, one-hop stable direct calls, receiver calls or inline out var result assertions, bounded exception assertions, and one same-kind private static test helper hop.
• elixir: a regular Mix application, with literal app and precise MixProject/Mixfile ownership, regular /app prefix modules and protocols, precise Mix tasks,Bounded abbreviations, terminal plurals, duplicate declarations and compile-local ExUnit wrapper ownership, static startup options, direct fully qualified or exact alias calls in test body scope, conservative filename evidence, and non-blocking mix test commands.
• javascript: JavaScript/TypeScript repositories, supporting Node test runners (including TypeScript execution scripts), Bun test, AVA, Mocha/CommonJS, Vitest, Jest, Playwright, Cypress, Express/Supertest, React Testing Library detection, as well as bounded literal browser request-to-route evidence.
• go: conventional go.mod projects and in-repository literal go.work members, using runnable standard library TestXxx, FuzzXxx, or ExampleXxx tests, package-local filenames, unique top-level and parser-owned concrete receiver method symbols (via explicit types, exact simple constructor results, or exact statically typed test helper results), bounded standard library and Testify assertion usage, parser-scoped local shadowing checks, same-package or exact external package imports (including dot imports), generic top-level functions, as well as bounded callable body-owned same-package or module-local source hops, module-local commands, and optional explicit GOOS / GOARCH / custom tag selection.
• kotlin: conventional Gradle/Maven JVM module roots, settings-owned Gradle aggregations, root-declared Maven reactors, with Kotlin and/or Java standard source sets, dependency-qualified direct/exported transitive module evidence, JUnit 4/5, kotlin.test, bounded Gradle/JUnit Platform Kotest generic specifications, conventional Gradle/Spock features, as well as method-level TestNG via direct Maven dependencies or Gradle useTestNG().
• php: a root Composer project, with PSR-4 source/test ownership of literal string values, bounded literal autoload function files, statically declared PHPUnit, exact bounded commands or explicit safe command preservation, conventional runnable test classes (including a unique source- or test-owned PHPUnit base class edge), direct imports or exactExact namespace-class call, plus conservative basename fallback.
• python: bounded Python packages, FastAPI, Django and Flask layouts, with declarative multi-package/namespace ownership, configured pytest discovery, exact absolute/relative imports, one-hop source dependency evidence, static framework test client route evidence, pytest/unittest, async and property-based extensions, fixture reachability, pip/setuptools, uv, Poetry, Hatch, tox, nox, and coverage configuration.
• rust: conventional Cargo packages and in-repo literal workspace members, using the built-in #[test] test framework, inline #[cfg(test)] modules, exact exclusion of external test-only module graphs, exact crate module imports from tests/, and exact unconditional crate root symbol re-exports.
• ruby: one conventional Bundler project, with lib/ sources, one root gemspec or a complete exact-named set of root gemspecs, runnable Minitest::Test test_* methods or RSpec examples, exact bounded commands, root .rspec and exact per-file spec_helper loading, three-way literal require/unique constant evidence, exact singleton calls, exact constant-owned RSpec described_class, direct immutable constructor locals, single-line RSpec let / subject, exact source factories with same-group RSpec helper receivers, and exact same-file literal shared example inclusion, bounded assertion usage, conservative basename fallback, and explicitly flagged Minitest-spec/Rails/mixed-runner blockers.
• swift: Swift Package Manager, Xcode-style and Bazel/rules_swift layouts, Swift Testing, XCTest, Quick/Nimble, SnapshotTesting, VaporTesting/XCTVapor, reactive frameworks, and generic Fluent database boundaries with driver-specific qualifiers.

Applicable scenarios and limitations This tool is suitable for developers and teams who want to systematically organize test strategies from repository-native facts, to audit existing test structures, identify high-value test candidates, and generate test plans and execution prompts.It does not automatically modify the repository; its findings should be reviewed as evidence-based review input, not as instructions to automatically change the repository.

Native test generation is intentionally deferred: generate_selected_test returns a structured deferral artifact until adapter-specific generation strategies and repair loop fixtures exist. Dart/Flutter remains experimental, and native test generation remains deferred. Maintenance is performed as time allows, with no guaranteed response time or feature schedule. Version 1.0.0 is latest on npm and is available in the official MCP Registry, providing stable support for documented CLI, MCP tools, configuration, and versioned artifact contracts. If a stack is missing, adapter requests can be submitted, including the language or ecosystem, build system, test framework, and, if possible, a representative public repository.