菜单
Guides design of a DuckDB-native, SQL-first sequencing QC system inspired by RustQC and related upstream tools, with one-pass analytics, reusable kernels, compatibility outputs, and careful threading and summary design. Use when planning DuckQC-style functionality.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | duckqc-design |
| description | Guides design of a DuckDB-native, SQL-first sequencing QC system inspired by RustQC and related upstream tools, with one-pass analytics, reusable kernels, compatibility outputs, and careful threading and summary design. Use when planning DuckQC-style functionality. |
Use this skill when planning a DuckDB-native QC system for sequencing data, especially RNA-seq and alignment-centric QC workloads.
This skill is intentionally design-oriented. It assumes a future system in the spirit of “DuckQC”: SQL-native, extension-first, one-pass where possible, and able to emit both queryable outputs and compatibility-style summaries.
A useful design reference is RustQC, which appears to:
A DuckQC direction should ask:
A DuckQC-style system should aim to:
Prefer a layered system:
This avoids rewriting the same scan logic separately for every QC metric.
DuckQC should aggressively look for shared-pass opportunities.
Possible one-pass outputs from aligned reads:
But each metric still needs an explicit contract.
Decide early:
Good candidate model:
Be careful where the host execution model makes this awkward.
DuckQC-like functionality may need:
Think carefully about startup costs vs repeated-query reuse.
Should a QC feature be exposed as:
Prefer queryable outputs first, compatibility writers second.
For each upstream-inspired QC artifact, decide whether the goal is:
Do not blur these categories.
Avoid:
Guides machine-readable function catalogs for DuckDB extensions, including a `functions.yaml` source-of-truth pattern that can drive docs, wrappers, aliases, examples, and consistency checks. Use when an extension exposes many SQL functions or multiple wrapper surfaces.
Guides development in the DuckHTS repo, including DuckDB extension work, Rduckhts package integration, vendored htslib workflows, SQL and tinytest coverage, wasm/webR constraints, and exact-compatible rewrites of upstream genomics tools. Use when working in github.com/RGenomicsETL/duckhts.
Guides creation, maintenance, checking, testing, documenting, and releasing R packages using project-native workflows such as Makefiles, tinytest, roxygen2, base R, and optional tools like usethis, pkgdown, air, or jarl. Use when working on any R package or CRAN-style package workflow.
Guides cache, index, and annotation-store design for bioinformatics rewrites, including when to use mainstream interoperable formats versus specialized high-performance encodings. Use when startup cost, repeated lookup performance, interval access, or annotation storage strategy are central design concerns.
Guides library-first bioinformatics rewrites that expose mature native code through bindings, extensions, FFI, or embedded runtimes across R, Python, SQL, and wasm. Use when building reusable interfaces around existing C/C++ libraries instead of standalone-only rewrites.
Guides responsible AI-assisted rewriting and porting of bioinformatics tools, combining rewrites.bio principles with practical validation, attribution, compatibility, and maintenance discipline. Use when planning or implementing a rewrite, reimplementation, or high-performance port of an existing bioinformatics tool.
