| name | constructing-product-type-qldpc-circuits-with-quits |
| description | Guides product-type QLDPC circuit construction with QUITS, including code-family selection, circuit-strategy selection, and bring-your-own parity-check workflows for HGP, LP, BPC, BB, and related codes. |
| version | 0.1.0 |
| author | QEC Research Skills |
| license | MIT |
| tags | ["QEC","QLDPC","QUITS","Circuits","HGP","Bivariate Bicycle"] |
| dependencies | ["qec-research","studying-qldpc-codes-with-qldpc","building-stim-circuits"] |
Constructing Product-Type QLDPC Circuits With QUITS
What This Skill Is For
Use this skill when the task starts from a QLDPC code family and needs a circuit-level plan:
- choose a QUITS-supported code family,
- map a custom HGP, LP, BPC, LCS, or BB request into QUITS modules,
- decide which circuit-construction strategy fits the code,
- separate code construction, noise-model choice, and decoder choice before implementation.
When To Use It Versus Alternatives
Use this skill when the user wants product-type QLDPC syndrome-extraction circuits or wants to reproduce the QUITS workflow for a custom code.
Use studying-qldpc-codes-with-qldpc when the task is still about code construction or structural analysis instead of circuits.
Use building-stim-circuits when the circuit design is already fixed and the remaining work is low-level Stim execution.
Do not present this skill as proof that the repo already ships a QUITS adapter. The current lane is documentation-first.
Required Artifacts And Assumptions
Expected inputs:
- target code family or explicit parity-check matrices,
- desired circuit strategy if already known,
- noise-model and decoder expectations,
- whether the request is for HGP, LP/QLP, BPC, BB, LCS, or bring-your-own matrices.
Expected outputs:
- a QUITS module-selection plan,
- a circuit-strategy recommendation,
- an explicit list of missing implementation artifacts,
- a handoff plan into
Stim, decoder, or benchmark lanes.
Assumptions to make explicit:
- whether the code family is directly supported or will use bring-your-own matrices,
- whether the request needs
zxcoloration, cardinal, cardinalNSmerge, or custom,
- whether the environment can support the current QUITS packaging expectations,
- whether the downstream decoder and noise-model assumptions are already fixed.
Standard Workflow Checklist
- Read
references/quits-module-and-workflow.md.
- State the code family, parity-check source, and downstream research question.
- Choose the QUITS code module first, then the circuit strategy, then the decoder, then the noise model.
- If the code is custom, make the parity-check handoff explicit instead of pretending QUITS natively constructs it.
- Start from the smallest representative circuit variant before proposing a large sweep.
- Record what would stay inside QUITS versus what should be exported to shared repo artifacts.
Validation Loop
Before closing work:
- confirm the requested code family maps to a supported QUITS lane or a bring-your-own-matrix lane,
- confirm the circuit strategy is named explicitly,
- confirm decoder and noise-model assumptions are not hidden inside the circuit recommendation,
- confirm any executable claim is labeled as planned unless a real adapter path exists.
Common Issues And Fixes
Treating QUITS as only a code library
Problem: the workflow jumps straight from parity checks to decoder choice.
Fix: restore the QUITS module order: code family, circuit strategy, decoder, noise model.
Unsupported strategy-family pair
Problem: a strategy is chosen that the code family does not support.
Fix: check the compatibility table in references/quits-module-and-workflow.md before planning implementation.
Hidden custom-code assumptions
Problem: "custom HGP/LP/BB" is requested, but the plan never says whether the matrices already exist.
Fix: make parity-check ownership explicit and treat matrix generation as a separate artifact when needed.
References
