How Quorum's reference implementation components map to Copilot CLI primitives.
The reference implementation's supervisor.py selects critics based on depth profile and artifact type. In the Copilot port, this logic moves into SKILL.md as natural language instructions that Copilot follows to orchestrate the validation flow.
Reference: supervisor.py → selects critics → ThreadPoolExecutor → collects results
Copilot: SKILL.md instructions → spawns task agents → collects responses
Each critic's system prompt + rubric injection becomes a task agent call:
# Reference implementation (simplified)
critic_result = litellm.completion(
model=config.tier2_model,
messages=[system_prompt + rubric + artifact]
)
# Copilot CLI equivalent (conceptual)
critic_result = task(
agent_type="explore", # or "general-purpose" for security
model="sonnet",
prompt=system_prompt + rubric + artifact
)The pre-screen layer runs identically — it's already a Python script that shells out to external tools:
Reference: quorum run → pre_screen.py → [DevSkim, Ruff, Bandit, PSSA]
Copilot: SKILL.md → python quorum-prescreen.py → [DevSkim, Ruff, Bandit, PSSA]
Key difference: Pre-screen must be stdlib-only for the port. The reference implementation uses pyyaml for config parsing — make it optional with JSON fallback.
The aggregator merges findings, resolves conflicts, and assigns verdicts. Two options:
- Inline in SKILL.md — aggregation logic as natural language instructions. Simpler, fewer premium requests.
- Dedicated agent —
general-purposeagent with aggregator prompt. More robust for complex conflict resolution.
Recommendation: Start with option 1, move to option 2 if quality suffers.
The fixer needs write access to propose changes:
Reference: fixer.py → reads findings + artifact → proposes text replacements → writes fix-proposals.json
Copilot: general-purpose task agent → reads findings + artifact → proposes changes → writes to disk
known_issues.json is read at session start and written after verdict. Files persist across Copilot sessions — no changes needed to the data format.
LiteLLM cost tracking doesn't apply. Copilot uses premium requests, not per-token billing. The port should track premium request count instead.
The reference implementation's batch mode processes multiple files with crash-resilient progressive saves. In Copilot:
Reference: BatchVerdict → ThreadPoolExecutor(max_workers=3) → progressive manifest
Copilot: SKILL.md loops over files → sequential or parallel task dispatch → progressive file writes
When extracting critic prompts from Python classes, preserve:
- System prompt — the critic's identity, evaluation criteria, and output format requirements
- Rubric injection — how rubric criteria are formatted and injected into the prompt
- Evidence grounding instruction — the requirement to cite specific locus (file, line, excerpt) for every finding
- Output schema — the JSON structure critics must return (findings array with severity, location, criterion, evidence)
Do NOT extract:
- LiteLLM-specific code (model routing, retry logic, cost tracking)
- ThreadPoolExecutor orchestration (replaced by
taskagents) - File I/O wrappers (Copilot agents handle file operations natively)
For each critic, run the same artifact through both:
- Reference implementation (
quorum run --target <file> --depth standard) - Copilot CLI port (natural language invocation)
Compare: finding count, severity distribution, evidence quality, verdict. They should converge but won't be identical (different model access patterns, prompt formatting).
Use the reference implementation's existing test artifacts:
examples/sample-research.md— planted flaws for research validationexamples/bad-config.yaml— planted security + completeness issues- Golden set artifacts (if graduated to public)
- Windows native PowerShell (primary)
- WSL (secondary)
- macOS Terminal (tertiary)
- Linux (tertiary)