agentleFS
zjunlpzjunlp/Mechanist/skills/data-rule/SKILL.md

data-rule

Skill75 starsChanged 4 months agoMITView on GitHub

The single place for every data constraint an experiment must satisfy — dataset provenance (existing → adapted → constructed), clear train / validation / test splits, labels that reflect the target behavior, and the minimum data amount. Use whenever an experiment chooses, adapts, or constructs a dataset, defines splits, or sets a sample size — for phenomenon validation (M0), mechanism exploration, intervention, or tuning. Domain-general: no assumption about model family, modality, or task.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Prefer an existing dataset that directly tests the target behavior.

    line 12
  2. Very specific:

    If none fits, adapt an existing one (relabel / filter / transform).

    line 13
  3. Distinctive:

    Do not set up special or different data for M0 or for different mechanism methods — use one consistent dataset across them.

    line 25
  4. Very specific:

    If the user or an incoming signal (e.g.

    line 27

≈ “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

Data Rule

All data constraints for an experiment live here. Apply them when you design the data (choose / adapt / construct the dataset and splits) and when you run the experiment — for every method and every milestone, M0 included. Use one consistent dataset; do not special-case per method or per phase.

1. Provenance — existing dataset first

Prefer an existing dataset that directly tests the target behavior. All inputs, conditions, and intervention contexts should be derived from naturally occurring examples in the dataset, rather than from artificially constructed, random, reverse-engineered, or model-generated substitutes. If none fits, adapt an existing one (relabel / filter / transform). Build your own only as a last resort. Record which of the three was used: existing / adapted / constructed.

2. Clear splits

Partition the data into explicit train / validation / test sets. No leakage across splits: deduplicate, and split by group / entity so near-duplicates cannot straddle the boundary. Never evaluate a probe / direction / classifier on the data it was fit on — held-out evaluation only; a score on training data is not evidence.

3. Labels reflect the target behavior

Labels must actually capture the target behavior the experiment is about, not a loose proxy. Ground truth comes from the dataset, never from another model's output.

4. Sample size

Do not set up special or different data for M0 or for different mechanism methods — use one consistent dataset across them.

  • If the user or an incoming signal (e.g. uer input or task.md ) states a data amount, use exactly that amount.
  • Otherwise, apply the floor by what the experiment does:
    • Inference-time mechanism exploration or intervention (locate a component, then ablate / patch / steer it): at least 50 examples (n > 50). This floor applies to every run at this stage, including preliminary ones — e.g. when sweeping steering coefficients, each coefficient setting must still be evaluated on at least 50 examples. Smaller samples make the results too noisy to trust: the run-to-run variance swamps the effect, and a coefficient can look best purely by chance.
    • Tuning / editing (training-time tuning, weight editing, learned steering directions): hundred-level — on the order of hundreds of examples (i.e. at least ~100).

The floor is on effective sample size — the count after filtering for usable signal, capped by the number of unique source items (many derived examples from a few sources do not raise it).

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.