Quell reads your docstrings, Pydantic models, and type annotations, extracts every testable requirement, finds which ones have no test, generates pytest tests via a rule engine, verifies each test through a 5-gate pipeline, and writes only proven tests to disk.

Does Quell require an LLM API key?

The rule engine runs entirely in-process — no source code is ever transmitted. ~75% of edge cases are handled with no network call and no API key. LLM fallback is opt-in and only sends the function signature, never the full body.

What is the 5-gate pipeline?

Every generated test must pass: Gate 1 (AST valid Python), Gate 2 (not already in a test file), Gate 3 (no shell calls or file writes), Gate 4 (passes against original code), Gate 5 (fails when the requirement is violated). Only gate-5-verified tests are written to disk.

What is the Production Readiness Score (PRS)?

PRS = (WRITTEN × 1.0 + SCAFFOLDED × 0.5) / total_requirements × 100. Tiers: 80-100 Production Ready, 60-79 Review Needed, 0-59 Needs Work.

How is Quell different from GitHub Copilot or Qodo for test generation?

Quell reads specifications that already exist in your code — it does not generate tests from scratch. It finds requirements already documented in your docstrings, Pydantic models, and type annotations that have no test. The 5-gate pipeline, especially Gate 5 (violation injection), verifies each test actually catches the bug it claims to catch. This verification step is not present in Copilot, Qodo, or Hypothesis.

Can Quell be used in CI pipelines?

Yes. Run quell ci src/ --threshold 80 to fail CI if PRS falls below 80. Set prs_threshold in pyproject.toml under [tool.quell]. Works with GitHub Actions, GitLab CI, and any system that checks exit codes.

Can Claude Code or Cursor use Quelltest directly?

Yes. Quelltest ships a local MCP server: install with pip install quelltest[mcp], then add {"mcpServers": {"quelltest": {"command": "quelltest-mcp"}}} to your project's .mcp.json. The agent can then call find_edge_cases, write_verified_tests, get_prs_score, prove_file, and reproduce_bug directly — no terminal needed. A Claude Code plugin is also available via /plugin marketplace add quelltest/quelltest-lib.

Does the Quelltest MCP server send my code anywhere?

No. The local MCP server (quelltest-mcp) runs entirely on your machine over stdio — no cloud, no network calls, no telemetry. The separate opt-in Claude.ai connector only ever transmits sanitized metrics (PRS score, bucket counts, test names, flag locations); a sanitizer blocks source code, function bodies, and docstrings structurally.

How do I add Quelltest as a Claude.ai connector?

In Claude.ai, go to Settings, then Connectors, then Add custom connector, and enter https://mcp.quelltest.com. Claude discovers the OAuth endpoints automatically and walks you through authorization.

Vitest, Jest, or node:test?

The best test runner is usually the one your team can run, understand, and maintain. Community discussions show real trade-offs: Vitest is attractive for TypeScript and ESM, Jest has mature conventions and a familiar API, and node:test reduces tooling for Node-only services.

The choice does not answer a different question: which edge cases does the code promise but the test suite never exercise?

Separate discovery from execution

Use Quelltest to scan the source contract, then use the runner your repository already owns:

npm install -D quelltest
npx quell find src/
npx quell generate src/       # dry-run scaffolds
npm test                      # your runner remains authoritative

This separation avoids a common migration trap: changing the runner and the test strategy at the same time. First make the missing behavior visible; then decide how to execute it.

A useful CI contract

Keep the output machine-readable and fail only on an agreed threshold:

npx quell score src/ --json > quell-report.json
npx quell score src/ --threshold 70

A readiness score is a review aid, not a quality guarantee. Pair it with unit, integration, API, security, and end-to-end coverage.

What to optimize for

Choose the runner based on project constraints, then make the surrounding workflow trustworthy: clear docs, stable Node support, lockfiles, low dependency risk, reproducible CI, and test failures that point to a source location. Those are the signals that make a package useful after the first install.