agentleFS
JunMA98JunMA98/Computer-science-claude-skills/skills/exploratory-data-analysis/SKILL.md

exploratory-data-analysis

Skill3 starsChanged 8 months agoMITView on GitHub

Explore and summarize computer science research data, experiment outputs, benchmark tables, logs, embeddings, predictions, and dataset files. Use when inspecting CSV, JSON, Parquet, NPY, NPZ, HDF5, TXT logs, or similar files to understand structure, quality, anomalies, and next analysis steps before modeling, benchmarking, or paper writing.

27 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 4 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 25 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill for CS-oriented exploratory analysis.

    line 8
  2. Distinctive:

    Before computing summaries, identify what one row, item, run, or file represents:

    line 23
  3. Very specific:

    Use scripts/eda_analyzer.py for an initial scan when it helps, but do not stop at generic summaries.

    line 42
  4. Distinctive:

    Use these inherited resources selectively:

    line 79
  5. Distinctive:

    When the user asks to explore a file or result table without more detail, return:

    line 99

“Common” is measured: kept by at least 6 in 10 of the 25 edited versions of this file we could read. “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

Exploratory Data Analysis

Use this skill for CS-oriented exploratory analysis. Prioritize findings that change research decisions: data leakage, broken runs, missing baselines, bad splits, unstable metrics, or misleading aggregates.

Typical CS Inputs

Handle cases such as:

  • dataset tables and metadata exports
  • train / validation / test split files
  • experiment logs and seed-wise result tables
  • benchmark leaderboards or ablation summaries
  • model predictions, error cases, and prompt-response pairs
  • embeddings, hidden states, graph statistics, or feature arrays
  • system measurement logs: latency, throughput, memory, failure counts

Start by Defining the Unit of Analysis

Before computing summaries, identify what one row, item, run, or file represents:

  • sample
  • document
  • graph
  • query
  • experiment run
  • model checkpoint
  • hardware configuration
  • user session

Many bad EDA conclusions come from mixing these levels.

Workflow

1. Inspect structure

  • file format, size, schema, and obvious parsing issues
  • column meanings or tensor shapes
  • join keys, IDs, timestamps, seeds, or split labels

Use scripts/eda_analyzer.py for an initial scan when it helps, but do not stop at generic summaries.

2. Check quality and validity

  • missing values and malformed records
  • duplicates and near-duplicates
  • inconsistent label or split assignments
  • impossible values, broken timestamps, or corrupted runs
  • class or task imbalance
  • train-test leakage or benchmark contamination indicators

3. Analyze the distributions that matter

  • label frequencies and long-tail behavior
  • sequence or prompt length distributions
  • metric spread across runs or seeds
  • runtime, memory, or throughput variance
  • embedding norms, sparsity, or dimensional anomalies
  • subgroup or slice behavior that averages may hide

4. Look for decision-relevant anomalies

  • runs that dominate an average because of one seed
  • missing baseline rows in supposedly complete tables
  • data slices where the model collapses
  • evaluation artifacts caused by filtering, truncation, or deduplication
  • suspiciously easy splits or repeated examples across partitions

5. Produce next-step guidance

Recommend concrete follow-up actions such as:

  • relabel or deduplicate data
  • redesign splits
  • rerun incomplete experiments
  • aggregate by seed with mean and variance
  • add subgroup evaluation
  • investigate outliers or failure slices
  • prepare cleaned tables for paper figures

Preferred Local Resources

Use these inherited resources selectively:

  • references/general_scientific_formats.md for common table/array formats
  • assets/report_template.md when a markdown analysis report is requested
  • scripts/eda_analyzer.py for quick initial parsing

The bio/chem/imaging references remain available from upstream, but for this curated repo they are secondary. Only load them if the actual data format requires them.

Output Formats

Choose an output that matches the task:

  • concise EDA memo
  • benchmark readiness report
  • run-quality audit
  • dataset issue list
  • error analysis summary
  • preprocessing plan
  • paper-ready results summary with caveats

Default Output

When the user asks to explore a file or result table without more detail, return:

  1. what the data appears to represent
  2. the most important structure and quality findings
  3. anomalies or risks that affect conclusions
  4. recommended next analyses or cleanup steps

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.