一键在 Manus 中运行任何 Skill

writing-data-contracts

星标91

分支148

更新时间2026年7月9日 10:22

Writes a data contract — what a row means, which fields are features vs labels vs context vs excluded, over which time windows — and verifies every claim with a query. Use before any feature building or modeling, or when results look wrong and the data definition is suspect.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

flyrank-bih

flyrank-bih/flyrank-ml-internship-starter

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Writing data contracts

Most weak analysis fails here, before any model: nobody wrote down what a row means. A data contract is that write-down — and a contract your code has checked, not just stated.

The contract, section by section

Unit of analysis. One row = one WHAT? (a page? a page-day? a client?) State it.
Time window. Which dates does each field cover? Draw the windows if they differ.
Field classification. Every field you may touch goes in exactly one bucket:
- Feature — knowable BEFORE the moment you predict, safe to use.
- Label / proxy — the thing you predict, or what it is computed from. Never a feature.
- Context — for grouping, joining, splitting, reading — never for the model to learn from (IDs live here).
- Excluded — private, product-decision flags, or future information. Each gets a one-line why.
Missing values. Which fields go blank, how often, and is the missingness random or does it follow a pattern (it usually follows a pattern — check by category).
Output. What the analysis hands to the human, in one sentence.

Verify every claim with a query

A contract line without a query next to it is a guess. For each claim, write the check:

Grain: SELECT unit_columns, COUNT(*) c FROM t GROUP BY unit_columns HAVING c > 1 LIMIT 5 — zero rows back means the grain holds.
Counts: total rows, rows per group, rows in your window. Compare to what the docs promised.
Missingness: AVG(CASE WHEN col IS NULL THEN 1.0 ELSE 0 END) per column — and again grouped by category, to catch patterned gaps.
Windows: MIN(date), MAX(date) — per group too, because histories rarely start together.

Traps that look innocent

Two tables with the same column name but different windows — align windows BEFORE joining.
Per-item context columns repeated on every row of a detail table: read them with a first/any-value, never SUM them (double counting).
A "complete" table that only accrues from each item's registration day — earlier history is absent, not zero.

How to verify

Every contract section has at least one executed query cell under it, and the query output matches the sentence above it.
Someone who has never seen the data could read your contract and predict the row count within a few percent. If they couldn't, the contract is still too vague.

同仓库更多 Skills

同仓库

hunting-leakage-and-validating

flyrank-bih/flyrank-ml-internship-starter

Finds label leakage and designs honest validation — leakage taxonomy, grouped and time-aware splits, base rates, and the attack-your-own-model checklist. Use before trusting any metric, when a score looks too good, or when features and labels share time windows or origins.

2026-07-1391

flyrank-data

flyrank-bih/flyrank-ml-internship-starter

The FlyRank internship datasets — the 30k-row starter CSV and its gotchas, the ~79M-row warehouse release tables and grains, panel warnings, access, and iteration rules. Load for EVERY task that touches the data. (Project-specific: delete this folder when reusing the skill library elsewhere.)

2026-07-1391

querying-big-datasets

flyrank-bih/flyrank-ml-internship-starter

Works with datasets far too big to download or load in pandas — SQL over remote Parquet with DuckDB, aggregate-then-model, iterate on samples. Use when a dataset has millions of rows, lives on a remote host (hf:// or s3), or a notebook runs out of memory or hits rate limits.

2026-07-1391

auditing-signals

flyrank-bih/flyrank-ml-internship-starter

Runs an honest EDA and signal audit — distributions first, heavy-tail handling, verdict-style mini-tests (CONFIRMED/OPPOSITE/MIXED/FALSE), sample-size floors. Use before modeling, when testing whether a popular belief shows up in data, or when a correlation looks too good.

2026-07-0991

building-baselines

flyrank-bih/flyrank-ml-internship-starter

Builds the transparent rule-based baseline every model must beat — a hand-written score with reason codes, ranked output, and precision@K evaluation. Use before training any model, or when someone reports model results with nothing to compare against.

2026-07-0991

deploying-static-pages

flyrank-bih/flyrank-ml-internship-starter

Deploys a static page (research paper, portfolio piece) for free from a GitHub repo using GitHub Pages — setup, file layout, verification, and recording the final URL. Use when publishing a finished write-up as a public web page.

2026-07-0991

name	writing-data-contracts
description	Writes a data contract — what a row means, which fields are features vs labels vs context vs excluded, over which time windows — and verifies every claim with a query. Use before any feature building or modeling, or when results look wrong and the data definition is suspect.

Writing data contracts

Most weak analysis fails here, before any model: nobody wrote down what a row means. A data contract is that write-down — and a contract your code has checked, not just stated.

The contract, section by section

Unit of analysis. One row = one WHAT? (a page? a page-day? a client?) State it.
Time window. Which dates does each field cover? Draw the windows if they differ.
Field classification. Every field you may touch goes in exactly one bucket:
- Feature — knowable BEFORE the moment you predict, safe to use.
- Label / proxy — the thing you predict, or what it is computed from. Never a feature.
- Context — for grouping, joining, splitting, reading — never for the model to learn from (IDs live here).
- Excluded — private, product-decision flags, or future information. Each gets a one-line why.
Missing values. Which fields go blank, how often, and is the missingness random or does it follow a pattern (it usually follows a pattern — check by category).
Output. What the analysis hands to the human, in one sentence.

Verify every claim with a query

A contract line without a query next to it is a guess. For each claim, write the check:

Grain: SELECT unit_columns, COUNT(*) c FROM t GROUP BY unit_columns HAVING c > 1 LIMIT 5 — zero rows back means the grain holds.
Counts: total rows, rows per group, rows in your window. Compare to what the docs promised.
Missingness: AVG(CASE WHEN col IS NULL THEN 1.0 ELSE 0 END) per column — and again grouped by category, to catch patterned gaps.
Windows: MIN(date), MAX(date) — per group too, because histories rarely start together.

Traps that look innocent

Two tables with the same column name but different windows — align windows BEFORE joining.
Per-item context columns repeated on every row of a detail table: read them with a first/any-value, never SUM them (double counting).
A "complete" table that only accrues from each item's registration day — earlier history is absent, not zero.

How to verify

Every contract section has at least one executed query cell under it, and the query output matches the sentence above it.
Someone who has never seen the data could read your contract and predict the row count within a few percent. If they couldn't, the contract is still too vague.