All posts
·3 min read·0 views·Shashank Bindal

Adding Requirement Coverage to Your CI Pipeline in 5 Minutes

A step-by-step guide to adding quell check to GitHub Actions, failing PRs on coverage drops, and posting automated gap reports as PR comments.

Adding Requirement Coverage to Your CI Pipeline in 5 Minutes

Line coverage in CI is table stakes. But high line coverage doesn't tell you whether your tests actually prove the behaviors they're supposed to cover. You can run every line with zero meaningful assertions and CI stays green.

This is how you add requirement coverage — a check that fails PRs when documented requirements lose their test coverage.

No API key needed. No LLM calls. The whole thing runs with --no-llm.

Basic workflow

Create .github/workflows/quell.yml:

name: Requirement Coverage

on:
  pull_request:
    paths: ["**/*.py"]
  push:
    branches: [main]

jobs:
  quell:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install
        run: |
          pip install quelltest
          pip install -e ".[dev]"

      - name: Check requirement coverage
        run: quell check src/ --no-llm --ci --threshold 0.80

The --ci flag exits with code 1 if coverage is below the threshold. The --threshold is a fraction — 0.80 means 80% of documented requirements must have a verified test.

That's the whole thing. PRs that drop coverage below 80% fail the check.

Adding a PR comment

If you want the coverage report posted directly on the PR so authors know exactly what's uncovered:

      - name: Post PR comment
        if: github.event_name == 'pull_request' && always()
        run: |
          quell pr ${{ github.event.pull_request.number }} \
            --comment \
            --no-llm \
            --repo ${{ github.repository }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

The always() means the comment gets posted even when the threshold check fails — so the PR author can see which specific requirements caused the failure, not just "CI failed."

The comment looks roughly like:

🟡 Quell Report — PR #47

Requirement coverage: 71% (15/21 covered)

Found 6 untested requirements:

| File | Function | Requirement | Type |
|------|----------|-------------|------|
| payments.py | retry_payment | ValueError: max_retries exceeded | MUST_RAISE |
| payments.py | retry_payment | RuntimeError: gateway timeout | MUST_RAISE |
...

Fix locally: quell check src/ --fix

Nothing gets posted on PRs that hit 100% — no noise when everything's covered.

One-command setup

quell install --pr

This generates the full workflow file at .github/workflows/quell-pr.yml and writes it to your project. Commit it and you're done.

Picking a threshold

The right answer depends on where you're starting from. Run quell check src/ --no-llm first to see your current score, then set the threshold at or just below it. Tightening over time is easier than starting too high and having to exclude half your codebase.

Rough starting points:

SituationThreshold
No baseline yet0.60 — see the lay of the land first
Established project0.75
Payment / auth / data pipeline0.85
Greenfield project0.90

Don't start at 1.0. You'll immediately find requirements that can't be auto-generated (external service calls, complex state setup) and have to carve out exceptions.

Secrets

SecretRequired?Purpose
GITHUB_TOKENYes — auto-providedPost PR comments
QUELL_API_KEYNoPro plan limits only

No ANTHROPIC_API_KEY, no OPENAI_API_KEY. The CI workflow runs entirely with --no-llm.


Full GitHub Actions docs or pip install quelltest to start locally.

Try Quelltest

Install Quelltest and run it on your codebase — no API key, no configuration.