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.

Production Readiness Score (PRS)

PRS is Quell's measure of edge-case test quality. It's not coverage — it's a measure of whether your tests actually catch bugs.

The formula

PRS = (WRITTEN × 1.0 + SCAFFOLDED × 0.5) / total_requirements × 100

Weighted by how well each bucket catches bugs:

WRITTEN counts fully — gate 5 proved the test catches violations
SCAFFOLDED counts half — structure is correct, but not fully proven
FLAGGED counts zero — documented but not testable

Score tiers

Score	Tier	Meaning
80–100	Production Ready	Edge cases are well-covered
60–79	Review Needed	Significant gaps remain
0–59	Needs Work	Many untested edge cases

Why PRS vs coverage

A codebase with 91% line coverage might have a PRS of 52.

Both numbers are correct. They measure different things.

Coverage tells you which lines ran during your test suite. PRS tells you whether tests would catch a real bug in those lines.

You can have 100% coverage with zero PRS if all your tests just assert the function returns something without checking correctness.

Improving your PRS

quell find src/ --fix    # write tests for verified gaps
quell score src/         # see current PRS by file

The fastest wins are usually:

Functions with explicit Raises in their docstrings
Pydantic models with field validators
Functions with guard clauses at the top

PRS in CI

Enforce a minimum score on every PR:

quell ci src/ --threshold 75

See CI/CD Integration for setup details.