genomic-coordinates
À propos
Cette compétence gère les conversions de coordonnées génomiques et la normalisation des variants à travers plusieurs formats et assemblages, évitant ainsi des erreurs d'analyse courantes. Elle traite les différences telles que l'indexation basée sur 0 ou 1, aligne les indels à gauche et détecte les incohérences d'assemblage. Utilisez-la lors de l'intégration d'outils avec différentes conventions de coordonnées ou lors du débogage de problèmes de "décalage d'une unité" ou d'assemblage génomique.
Installation rapide
Claude Code
Recommandénpx skills add K-Dense-AI/claude-scientific-skills -a claude-code/plugin add https://github.com/K-Dense-AI/claude-scientific-skillsgit clone https://github.com/K-Dense-AI/claude-scientific-skills.git ~/.claude/skills/genomic-coordinatesCopiez et collez cette commande dans Claude Code pour installer cette compétence
Documentation
Genomic Coordinates
When to use
Any time a coordinate crosses a boundary: between two file formats, between two tools, between two assemblies, or between the genome and a transcript.
The rule
A coordinate is three facts, not one: the number, the convention it is written in, and the assembly it was measured against. Carry all three or the number is not interpretable.
Coordinate errors are the quietest class of bug in genomics. An off-by-one BED file parses, sorts, and intersects without complaint. A GRCh37 VCF joined against a GRCh38 annotation returns rows. A right-shifted indel simply fails to match its entry in ClinVar, and the result is a variant reported as novel. Nothing raises an error; the answer is just wrong, and it is wrong in a direction that looks plausible.
So: convert with the table, not from memory, and verify against the reference whenever a reference is available.
The two conversions
1-based inclusive -> 0-based half-open : start - 1, end
0-based half-open -> 1-based inclusive : start + 1, end
The end coordinate never moves. If a conversion changed both numbers, it is wrong.
Which format is which
| 0-based, half-open | 1-based, inclusive |
|---|---|
| BED, bedGraph, bigWig, narrowPeak | GFF3, GTF, VCF |
| BAM/CRAM (binary POS) | SAM (text POS) |
| PSL, genePred, refFlat | WIG, Picard interval_list |
| MAF (UCSC multiple alignment) | MAF (TCGA mutation annotation) |
| PyRanges, pybedtools | GRanges/IRanges, samtools & UCSC & Ensembl region strings |
Both "MAF" formats exist, they mean different things, and they disagree. UCSC
serves 0-based files through a 1-based browser box. references/format-conventions.md
has the full table with per-format detail.
cd skills/genomic-coordinates/scripts
python3 convert_coords.py --list # the table
python3 convert_coords.py --from bed --to gff chr1 999 1000
python3 convert_coords.py --from ucsc --to bed "chr7:5,530,601-5,530,625"
python3 convert_coords.py --from granges --to pyranges --input regions.tsv
contig input output length status detail
chr7 chr7:5530601-5530625 5530600-5530625 25 ok
Zero-length BED features (chromStart == chromEnd, a legal insertion point) are
reported as unrepresentable rather than converted to end = start - 1. Exit
code is 1 when any interval is degenerate or invalid.
Variants are not intervals
A VCF POS for an indel is the anchor base — the base before the event,
itself unchanged. And the same change can be written many ways:
chr1:7:CAC:C, chr1:3:CAC:C and chr1:2:GCA:G are one deletion. Joining,
deduplicating, or looking up variants before normalising loses real matches
silently, and it loses them preferentially in repeats, where indels concentrate.
Normalise — trim to parsimony, then left-align against the reference — before any comparison:
python3 normalize_variant.py --fasta ref.fa chr1 7 CAC C
python3 normalize_variant.py --fasta ref.fa --split --input cohort.vcf
python3 normalize_variant.py --fasta ref.fa --compare chr1:7:CAC:C chr1:2:GCA:G
input normalized type pos_shift ref_check changed
chr1:7:CAC:C chr1:2:GCA:G deletion 5 ok yes
Every record's REF is checked against the FASTA first. A MISMATCH means the
variants and the reference are different assemblies — stop and run
check_contigs.py rather than adjusting coordinates. Multi-allelic records must
be split with --split before normalising, never after.
HGVS shifts indels the opposite way, 3'-most along the transcript. For a
minus-strand gene that is the opposite genomic direction from VCF's
left-alignment. Details and the full procedure: references/variant-representation.md.
Check the assembly before trusting a join
python3 check_contigs.py --identify unknown.fa.fai
python3 check_contigs.py variants.vcf annotation.gtf --genome GRCh38.fa.fai
file kind contigs naming assembly detail
ref.fa.fai sizes 25 plain GRCh37 24/24 primary chromosome lengths match;
chrM is 16569 bp, i.e. GRCh37/38 (rCRS MT)
The script reads .fai, .chrom.sizes, VCF headers, SAM headers, FASTA, BED,
and GTF/GFF, identifies the assembly from primary-chromosome lengths, and reports
every reason a join between two files would go wrong: naming mismatch, length
conflict, coordinates past a contig end, contigs present in one file only. Exit
code 1 on any incompatibility.
GRCh37 and hg19 differ only in the mitochondrion — 16,569 bp (rCRS) versus
16,571 bp. Nuclear coordinates are identical, so a mixed pipeline runs fine and
only the mtDNA results are wrong. check_contigs.py reports which one it found.
Builds, naming schemes, ALT contigs, and liftover pitfalls:
references/reference-builds.md.
Audit a file against its own format
python3 audit_intervals.py peaks.bed
python3 audit_intervals.py gencode.gtf --genome hg38.chrom.sizes
python3 audit_intervals.py cohort.vcf --genome GRCh38.fa.fai
Looks for the evidence that a coordinate mistake leaves behind:
| Finding | What it proves |
|---|---|
start_below_one in GFF/GTF | 0-based data in a 1-based file; everything is one base left |
many_zero_length in BED | 1-based single-base features written into a 0-based file |
past_contig_end | wrong assembly, or an off-by-one at the contig edge |
mixed_contig_naming | any join will silently match one subset |
first_block_offset | BED12 blockStarts written as absolute coordinates |
not_parsimonious | untrimmed alleles; normalise before joining |
bad_alt_allele | Ensembl/VEP - notation in a VCF, which has no anchor base |
Exit code 1 on any fatal finding, so it works as a CI gate on a data directory.
Transcript, CDS, and protein positions
c.742 and chr17:7,674,220 are both "position", and neither converts to the
other by arithmetic. Transcript coordinates count spliced bases in transcription
order — decreasing genomic coordinate on the minus strand — and c.1 is the A
of the initiator ATG, not the start of the transcript.
The rules that get mis-remembered: there is no c.0; 5' UTR positions are
negative and 3' UTR positions take a *; GFF phase is the bases to remove to
reach the next codon, not start % 3; and a c. description is meaningless
without a versioned transcript accession, because the same variant numbers
differently in each transcript. references/transcript-coordinates.md has the
conversion procedure and the boundary cases.
Do the conversion with a tool that holds the transcript model — VEP,
bcftools csq, Mutalyzer, the hgvs package — not by hand.
Reporting results
State the assembly next to the coordinates, every time.
chr7:5,530,601-5,530,625 is not a location; chr7:5,530,601-5,530,625 (GRCh38)
is. Say which convention a coordinate column is in, in the column header or the
file's documentation. When a conversion produced a result, say which direction it
went.
References
references/format-conventions.md— every format's convention, with per-format detail, BED12 block rules, region-string syntax, and tool behaviour.references/variant-representation.md— VCF allele conventions, the normalisation algorithm, equivalence checking, multi-allelic splitting, and how HGVS disagrees with VCF.references/reference-builds.md— build signatures, GRCh37 vs hg19, ALT contigs, naming schemes, and liftover failure modes.references/transcript-coordinates.md— genomic ↔ transcript ↔ CDS ↔ protein, HGVS numbering, phase, and transcript choice.
Dépôt GitHub
Questions fréquentes
Qu’est-ce que le Skill genomic-coordinates ?
genomic-coordinates est un Skill Claude créé par K-Dense-AI. Un Skill regroupe des instructions et des ressources que Claude charge à la demande pour effectuer des tâches liées à genomic-coordinates sans consigne supplémentaire.
Comment installer genomic-coordinates ?
Utilisez les commandes d’installation de cette page : ajoutez genomic-coordinates à Claude Code comme plugin ou clonez son dépôt dans votre dossier skills, puis redémarrez Claude pour charger le Skill.
À quelle catégorie appartient genomic-coordinates ?
genomic-coordinates appartient à la catégorie Méta.
genomic-coordinates est-il gratuit ?
Oui. genomic-coordinates est référencé sur AIMCP et son installation est gratuite.
Compétences associées
Cette compétence propose une configuration éprouvée en production pour Content Collections, un outil axé sur TypeScript qui transforme des fichiers Markdown/MDX en collections de données typées de manière sûre avec une validation Zod. Utilisez-la lors de la création de blogs, de sites de documentation ou d'applications Vite + React riches en contenu pour garantir la sécurité de typage et la validation automatique du contenu. Elle couvre tout, de la configuration du plugin Vite et de la compilation MDX à l'optimisation des déploiements et la validation des schémas.
Cette compétence permet aux développeurs de créer des applications avec la plateforme de marchés prédictifs Polymarket, incluant l'intégration d'API pour le trading et les données de marché. Elle fournit également une diffusion de données en temps réel via WebSocket pour surveiller les transactions en direct et l'activité du marché. Utilisez-la pour mettre en œuvre des stratégies de trading ou pour créer des outils traitant les mises à jour de marché en direct.
Cette compétence aide les développeurs à créer des plugins OpenCode qui s'interconnectent avec plus de 25 types d'événements tels que les commandes, les fichiers et les opérations LSP. Elle fournit la structure du plugin, les spécifications de l'API événementielle et les modèles d'implémentation pour les modules JavaScript/TypeScript. Utilisez-la lorsque vous avez besoin d'intercepter, de surveiller ou d'étendre le cycle de vie de l'assistant IA OpenCode avec une logique personnalisée pilotée par les événements.
SGLang est un framework de service LLM haute performance spécialisé dans la génération rapide et structurée pour les workflows JSON, regex et agentiques grâce à son cache de préfixe RadixAttention. Il offre une inférence nettement plus rapide, particulièrement pour les tâches avec des préfixes répétés, ce qui le rend idéal pour les sorties complexes et structurées ainsi que les conversations multi-tours. Choisissez SGLang plutôt que des alternatives comme vLLM lorsque vous avez besoin d'un décodage contraint ou que vous construisez des applications avec un partage étendu de préfixes.
