Gene Panel Designer

Automatically designs candidate primer pairs for a gene's currently-selected exons (Step 2 scope) using real GRCh38 reference sequence. The flank and amplicon fields below are each a range: the smaller/preferred value is tried first, and only a target that can't produce a passing primer pair at that setting is automatically re-tried at progressively wider settings, up to the "expand up to" ceiling — independently per exon/target, so one difficult exon doesn't loosen the results for every other exon in the run. Candidates are scored on the same Tm/GC/homopolymer/hairpin/3′-dimer QC engine used throughout this tool, then checked for a unique binding site within a ~50kb local reference window. This local-window check is not a genome-wide BLAST search — no browser tool can run one (see disclosures) — so also use the "Open in NCBI Primer-BLAST" link on each result to verify genome-wide specificity yourself before ordering primers. Select more than one gene (Ctrl/Cmd-click, or Shift-click for a range) to run them one after another in a single click, for as many amplicon targets as the whole selection needs — a gene (or a whole multi-gene batch) is no longer stopped at 40 targets; it automatically continues in batches of 40 until everything selected is designed. Every UCSC fetch stays paced 250ms apart the whole time, so a large panel (e.g. every exon of several genes) just takes longer, not faster or less considerate of the shared service — a full 50-gene hotspot panel can genuinely take several minutes. Progress renders as it goes; click Stop at any point to keep whatever's been designed so far and end the run there.

Screens primer pairs for single-tube multiplex PCR compatibility — Tm clustering plus a 3′-end cross-dimer check, grouped into suggested pools via the same graph-coloring minimization either way. Draws on all three sources below at once, so primers don't need to be logged first just to check them. Gene below picks either one gene, or (direct follow-up request: "the multiplexing tool must be flexible to pool diverse and numerous different genes not one at a time") Whole panel, which pools every gene in your list together into one combined set of pools — the real question for something like a 50-gene cardiac panel, where "5 pools total" only means something if the pools can mix genes freely rather than being computed one gene at a time. For a real NGS panel you want every amplicon in scope represented — not just whatever happened to still be sitting in memory from an earlier, possibly narrower Step 5 run — so by default this auto-designs (using Step 5's own current flank/amplicon/merge settings above) anything not yet designed or logged before screening, following each gene's own current Step 2 scope exactly (whole gene, CDS-only, all exons, or a custom exon selection). No target-count cap either — a large gene, or a whole large panel, is designed automatically in batches until it's done (or you click Stop). In Whole panel + pool-aware mode, primer selection is deliberately shared across every gene in the run (not reset per gene) — the actual mechanism that lets many genes end up sharing few pools, rather than each gene independently landing in its own best-effort pool.

Designs primers for one large amplicon spanning a gene's whole genomic span (transcript start to end) where its size allows, or tiles a larger gene into several overlapping long-range amplicons otherwise — rather than the many small, exon-by-exon amplicons Step 5 designs. Typical long-range PCR range: ~5,000–15,000bp per amplicon (both edited below); a gene whose whole span already fits at or under the max is designed as ONE amplicon, a bigger gene is split into that many overlapping amplicons instead (reuses the exact same tiling logic Step 5 already uses for a single oversized exon). Primers are longer (25–30nt) with a higher Tm target (60–68°C) than Step 5's standard-PCR primers — sourced from Takara Bio's own TaKaRa LA PCR Kit/LA Taq documentation, which recommends 25–30nt primers (paired Tm within 2–3°C of each other) and an optimal annealing range of 55–68°C for long-range PCR (see disclosures for the full citation and the sourced cycling conditions below). Two things this section does not do, disclosed plainly: it has no data on neighboring genes, so a whole-gene amplicon's outer primers are searched in the immediately flanking sequence without checking whether that runs into another gene nearby; and it runs no local-specificity window check (a long-range amplicon can already be as large as the window would be) — always use the "Open in NCBI Primer-BLAST" link on every result before ordering, more important here than for short targeted amplicons.

A second, independently-coded design path (7.1) plus a way to bring in a primer pair from any outside source and check it against what this tool already has on file (7.2) — so a Step 5 result can be cross-checked by something that doesn't share its code, catching a bug or glitch specific to one engine. See the disclosures for exactly what this can and can't protect against (in particular: 7.1 still depends on the same UCSC sequence API as Step 5, so it isn't independent of a UCSC outage — 7.2 is, since it needs no network at all).

Fetches real GRCh38 sequence for a gene/exon/region (needs internet) and checks whether your logged primers (Steps 11–12) appear in it — plus, unless you turn either off below, this gene's tool-designed-but-not-yet-logged pairs (Steps 5, 6, 7.1) and any third-party primers already bulk-checked in Step 7.2. Literal sequence match only, not a genome-wide BLAST search — see disclosures for details and limitations. Source defaults to UCSC (same as Step 5's own design fetches, so a "Found" result there is confirmed against the identical build); switch to Ensembl for a genuinely independent second look — its own separate server, useful when UCSC is down or as a deliberate cross-check.

Direct request: this step used to only ever check your logged NGS/Sanger primers (Steps 11–12) plus whatever you paste in below. It now also offers this gene's tool-designed-but-not-yet-logged pairs (Step 5, Step 6 long-range, Step 7.1 Algorithm B) and any third-party primers already bulk-checked in Step 7.2 — so you can see everything's real position before deciding what to log at all. A pair that HAS since been logged may show up twice here (once as "Logged", once under its design source) rather than being silently hidden — this tool doesn't track whether a given designed pair was later logged, so it errs toward showing a possible duplicate over hiding a real result.

Optional — paste a forward/reverse pair here (from a colleague, another source, or something you designed but haven't logged) to see it checked against this same fetched window, right alongside any already-logged primers for this gene. Nothing pasted here is saved anywhere; it's checked once, for this fetch only.

Direct request: a way to find primers already published for a gene, rather than only designing new ones. Honest scope, checked directly against NCBI's own documentation before building this: NCBI's PubMed/E-utilities API does not support cross-origin requests from a browser-based page like this one (no CORS), and even where a paper's full text is reachable, primer sequences almost never live in a structured, machine-readable field — they're typically in a Methods-section table or supplementary file as an image or formatted text. An automatic "search and extract primers" feature is not honestly buildable as a static, offline-capable browser tool without a server-side component this project doesn't have. What this section does do instead: builds a correctly-formed PubMed (and Google Scholar) search link for a gene plus primer-related keywords, opened in a new tab for you to search and read yourself — and gives you a place to log what you find (primer sequences, target, authors, citation, link) in one tabulated record, with the same export and "log to NGS/Sanger" options as everywhere else in this tool. Nothing here is fetched or scraped automatically; every row is something you read and typed in yourself.

High Resolution Melting (HRM) assay design for two different goals, run independently below: 14.1 Known-variant genotyping designs a short amplicon centered on one specific SNV (by rsID, manual chromosome/position/ref/alt, or a codon number/protein change) so its two genotypes can be told apart by melt-curve shift, and predicts that shift; 14.2 Unknown-mutation scanning tiles a whole exon (or several) into short overlapping amplicons so ANY variant inside one — known or not — perturbs its melt curve enough to flag it for Sanger follow-up. Both reuse this tool's existing primer-candidate engine and QC thresholds (same Tm/GC/homopolymer/hairpin/3′-dimer checks as Step 5), just with an amplicon-size range tuned short — HRM strongly prefers single-domain products well under 200bp — instead of Step 5's default ~400bp target. Two disclosed limits, upfront: this only supports single-nucleotide variants (SNVs) for genotyping, not indels; and every Tm number here — including the predicted genotyping ΔTm — comes from the same two-state nearest-neighbor model used throughout this tool, applied across the whole amplicon rather than just an 18–27nt primer. That is a real, documented approximation of true HRM melt-curve behavior, not a partition-function melting-curve simulator like uMelt and not a substitute for actually running the assay. A homozygous SNV's real ΔTm is often small (well under 1°C); treat the predicted ΔTm as a rough, directional planning aid, not a promise that two genotypes will be visually distinguishable on your instrument without a proper heterozygote/no-template control panel run alongside your samples.

Direct request: "add a separate section for ARMS PCR primer design as most of single genes mutations such as EGFRm PIK3CA and ALK etc are known to be detected by ARMS PCR technology" (citing diatechpharmacogenetics.com and amoydx.com as real examples of commercial ARMS-PCR/qPCR hotspot kits). Amplification Refractory Mutation System (ARMS, also called allele-specific PCR) designs a primer whose 3′-terminal base sits exactly on one specific allele -- it only extends efficiently when that exact base is present in the template, so a real-time Ct shift or gel band tells genotype directly, without a melt-curve step. Unlike HRM (Step 14), which can flag an unknown mutation anywhere in a region, ARMS is inherently allele-specific -- it can only ever detect the exact substitution(s) it was designed against, which is exactly why 15.1 below supports two ways in: a single known variant (rsID / codon+protein-change / manual coordinates), or -- the real clinical pattern described directly ("the codon base changes are not usually readily available so is it possible to search for all at the same time," using KRAS codon 12/13 as the reference case) -- a hotspot codon with NO specific base change given, which auto-expands into a small PANEL of allele-specific primers, one per real possible single-nucleotide substitution at that codon, all sharing the SAME common/outer primer -- the same structure real commercial ARMS hotspot kits use. Design rules are sourced, not invented: allele-specific primer length 20–30nt (this tool searches that full band; a peer-reviewed ARMS methods overview flags 25–28nt as typically best) and a deliberate destabilizing mismatch at the 2nd base from the 3′ end alongside the true discriminating 3′-terminal base, both per a Thermo Fisher SNP-detection-by-ARMS-PCR technical note and a published ARMS-PCR protocol/methods overview (both fetched and quoted while building this -- see disclosures for the exact citations and this tool's own simplifications). Reuses this tool's shared primer-candidate/QC engine (same Tm/GC/homopolymer/hairpin/3′-dimer checks as every other step) for the common/outer primer, and the same shared HRM-built variant-resolution engine (codon/protein-change parsing, reverse rsID lookup, codon-substitution enumeration, exon-number lookup) for variant input -- one real engine behind both sections, not two copies.