agentleFS
open-science-pillarsopen-science-pillars/core/skills/quality-control/SKILL.md

quality-control

Skill0 starsChanged 53 days agoApache-2.0View on GitHub

QC for geophysical data: completeness, physical-bounds checks, fill-value audit, satellite QA flag decoding, discontinuity detection.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 8 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before reporting any check, consult installed knowledge concepts first, as the consult-knowledge skill sets out, by the dataset, variable, …

    line 16
  2. Distinctive:

    Physical bounds: Every value inside the hard bounds of its variable.

    line 47
  3. Distinctive:

    Never run bounds checks before the fill-value audit.

    line 89
  4. Distinctive:

    Never threshold or average a packed QA integer as if it were data.

    line 91
  5. Distinctive:

    Never treat QA flags as quantitative uncertainty.

    line 92
  6. Distinctive:

    Never silently delete or interpolate flagged data.

    line 93
  7. Distinctive:

    Never pass a dataset as "QC clean" without reporting all six checks with evidence.

    line 95
  8. Distinctive:

    Never inline a screening bound, a sentinel value, or a QA bit layout in this skill.

    line 97

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

quality-control

Quality control for geophysical datasets: invocable directly ("run QC on this dataset") and consulted automatically before analysis. The six-check structure reconstructs the v0.1 enumeration that the specification's acceptance criteria reference (docs/SPECIFICATION.md in open-science-pillars/marketplace).

Consult the bundle for this dataset

Before reporting any check, consult installed knowledge concepts first, as the consult-knowledge skill sets out, by the dataset, variable, and check in play; this skill carries no dataset facts, sentinel lists, screening numbers, or QA bit layouts. The concepts it leans on:

  • the sentinel list and detection recipe: conventions/common-fill-values.md;
  • the physical-bounds screening table: conventions/physical-bounds-screening.md;
  • the satellite QA bit and class layouts: conventions/satellite-qa-flag-decoding.md;
  • calendar and time-axis rules: conventions/calendars.md;
  • the dataset's own known-issues / gotcha concepts, for named instrument or version transitions.

Numbers, sentinel values, and bit layouts are read from the concepts, never from this file.

The six checks, in order

Order matters: a bounds check on unmasked sentinels reports garbage, so the fill audit precedes bounds.

  1. Coordinates and time axis. Latitude within [-90, 90], longitude convention identified, coordinates monotonic after sorting; time axis monotonic, no duplicates, cadence as documented; calendar identified.
  2. Fill-value audit. _FillValue/missing_value attributes present and applied; scan minima/maxima for unmasked sentinels and check encoding for packing applied twice or not at all. The sentinel list and the detection recipe are read from conventions/common-fill-values.md, not carried here.
  3. Completeness. Missing fraction per variable, overall and per time step; the longest gap, reported in time units, with its dates; spatial holes distinguished from temporal gaps.
  4. Physical bounds. Every value inside the hard bounds of its variable; values outside the plausible-but-legal range listed for review rather than auto-rejected. Hard versus plausible is the method; the screening numbers per variable are read from conventions/physical-bounds-screening.md, and regional analyses tighten them. State which bounds were applied.
  5. QA flag decoding. Satellite products: decode the bit-packed QA layer with bitwise operations and mask accordingly; never threshold a packed QA integer numerically. The product bit and class layouts (MODIS, Landsat C2, Sentinel-2, and kin) are read from conventions/satellite-qa-flag-decoding.md, not carried here; state which bits or classes were masked and what fraction that removed.
  6. Discontinuity detection. Spikes (rolling-median deviation test), steps (change in mean across a break, instrument or version transitions), and suspicious exact repeats (stuck sensor, duplicated granule).

Report each check with a verdict and one line of evidence. Flagged data is masked and reported, never silently deleted; interpolation across a reported gap happens only when stated in the methods.

QA flags are categorical: they are never a quantitative uncertainty (uncertainty-quantification carries that rule). The screening numbers (the physical-bounds table) and the product QA layouts (MODIS, Landsat C2, Sentinel-2) are dataset facts and live in the concepts named in "Consult the bundle for this dataset", read and cited per run, never inlined here.

Discontinuity detection

  • Spikes: deviation from a centered rolling median beyond k robust standard deviations (k around 5 for geophysical series); report count and worst offenders with dates.
  • Steps: compare means across candidate break dates (known instrument or version transitions first; the dataset concept's known-issues section names them); a persistent shift after a transition date is a finding for the provider, not something to quietly detrend.
  • Exact repeats: identical consecutive values or identical granules beyond chance suggest a stuck sensor or duplicated file.

Must NOT (hard refusals and gates: invariant, universal, fire without consulting anything)

  • Never run bounds checks before the fill-value audit. (Ordering gate: a bounds check on unmasked sentinels reports garbage.)
  • Never threshold or average a packed QA integer as if it were data.
  • Never treat QA flags as quantitative uncertainty.
  • Never silently delete or interpolate flagged data; mask, report, and state any infilling in the methods.
  • Never pass a dataset as "QC clean" without reporting all six checks with evidence.
  • Never inline a screening bound, a sentinel value, or a QA bit layout in this skill; read them from the concepts and cite them per run.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.