agentleFS
flonatflonat/flonat-research/skills/data-analysis/SKILL.md

data-analysis

Skill150 starsChanged 9 days agoMITView on GitHub

Deliver an end-to-end analysis pipeline: EDA, estimation, or publication output. Use when the user requests an end-to-end analysis pipeline: EDA, estimation, or publication output.

76 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use algorithm-design, review-r and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • lingzhi227Skill

    algorithm-design

    Design algorithms with LaTeX pseudocode and UML diagrams. Generate algorithmic environments, Mermaid class/sequence diagrams, and ensure consistency between pseudocode and implementation. Use when formalizing methods for a paper.

    Also in 5 projects that use this

  • luischanciSkill

    review-r

    Run the R code review protocol on R scripts. Checks code quality, reproducibility, domain correctness, and professional standards. Produces a report without editing files.

    Also in 4 projects that use this

  • zephyrwang6Skill

    deepl

    Übersetzt Texte, Dokumente und XLIFF-Dateien via DeepL API. Verwende für Übersetzungen mit /deepl translate, /deepl file oder /deepl xliff.

    Also in 4 projects that use this

  • zephyrwang6Skill

    imagemagick-conversion

    Convert and manipulate images with ImageMagick. Covers format conversion, resizing, batch processing, quality adjustment, and image transformations. Use when user mentions image conversion, resizing images, ImageMagick, magick command, batch image processing, or thumbnail generation.

    Also in 4 projects that use this

  • lingzhi227Skill

    latex-formatting

    Handle LaTeX formatting, templates, and styling for academic papers. Set up conference templates (ICML, ICLR, NeurIPS, AAAI, ACL), fix formatting issues, manage packages, and ensure venue-specific compliance. Use when the user needs to set up a paper template, fix LaTeX formatting, or prepare for submission.

    Also in 4 projects that use this

  • stophobiaSkill

    surprise-me

    Create a delightful, unexpected "wow" experience for the user by dynamically discovering and creatively combining other enabled skills. Triggers when the user says "surprise me" or any request expressing a desire for an unexpected creative showcase. Also triggers when the user is bored, wants inspiration, or asks for "something interesting".

    Also in 4 projects that use this

  • +3 more from zephyrwang6
  • +2 more from lingzhi227

The file

We split this skill into the rules it gives an agent

7 rules. 0 are common, 2 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 53 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Default: Full. Detect mode from user request or ask if ambiguous.

    line 22
  2. Very specific:

    Detect project structure: Read CLAUDE.md, check for data/, code/, paper/ directories.

    line 50
  3. Very specific:

    Detect language: Check existing scripts, user preference, or ask.

    line 51
  4. Very specific:

    Read references/estimation-recipes.md for language-specific estimation patterns.

    line 84
  5. Very specific:

    Critical rule: All numbers in .tex files must come from generated files via \input{}.

    line 99
  6. Very specific:

    Verify outputs exist: Check all expected files in paper/tables/ and paper/figures/

    line 105
  7. Distinctive:

    Every generated script follows this header template:

    line 112

“Common” is measured: kept by at least 6 in 10 of the 53 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

Data Analysis Pipeline

Generate, execute, and verify analysis scripts across R, Python, Stata, and Julia.

Modes

ModeWhat it doesPhases
EDAExploratory data analysis only1–2
EstimationEstimation + publication output (requires locked design)1, 3–4
FullComplete pipeline1–5

Default: Full. Detect mode from user request or ask if ambiguous.

When to Use

  • "Analyse this data" / "Run EDA on this CSV" / "Estimate the model"
  • "Generate results tables" / "Create publication figures"
  • Any task requiring data → script → output pipeline

When NOT to Use

  • Experimental design or power analysis → experiment-design
  • Generating synthetic data for testing → synthetic-data
  • Auditing identification strategy → causal-design
  • Proofreading or compiling the paper → proofread, latex

Shared References

  • Method probing questions: shared/method-probing-questions.md — ask before running any analysis
  • Validation tiers: shared/validation-tiers.md — declare tier before examining results
  • Escalation protocol: shared/escalation-protocol.md — escalate when methodology answers are vague
  • Distribution diagnostics: shared/distribution-diagnostics.md — mandatory DV checks before model selection
  • Engagement-stratified sampling: shared/engagement-stratified-sampling.md — stratify by engagement tiers for social media data
  • Inter-coder reliability: shared/intercoder-reliability.md — per-category reliability for content analysis and LLM annotation

Workflow

Phase 1: Setup

  1. Detect project structure: Read CLAUDE.md, check for data/, code/, paper/ directories.
  2. Detect language: Check existing scripts, user preference, or ask. Read shared/multi-language-conventions.md for the chosen language's conventions.
  3. Locate data: Find datasets in data/raw/ or data/processed/. Never modify data/raw/ (per data-sensitivity rule). For social-media datasets, follow shared/engagement-stratified-sampling.md when constructing analysis samples.
  4. Confirm validation tier per shared/validation-tiers.md. Tier dictates claim-strength language allowed in Phase 4 outputs and how strict the locked-design gate (step 5) is enforced.
  5. Check for locked design: Look for analysis plan in log/plans/, .context/project-recap.md, or MEMORY.md estimand registry. If running Estimation or Full mode and no design exists, stop and warn: "No locked research design found. Run experiment-design or causal-design first, or confirm the specification before proceeding." Use shared/method-probing-questions.md to probe gaps if the user pushes back on the gate.

Phase 2: Exploratory Data Analysis

Generate and execute an EDA script that produces:

  1. Data overview: dimensions, types, missingness summary
  2. Univariate distributions: histograms/density for continuous, bar charts for categorical
  3. Bivariate relationships: correlation matrix, key scatterplots, cross-tabulations
  4. Outlier detection: box plots, IQR-based flags
  5. Distribution diagnostics (mandatory): run distribution_diagnostics() from shared/distribution-diagnostics.md on every DV and key IVs. Report skewness, zero proportion, overdispersion, and model recommendation. Flag if OLS is inappropriate.
  6. Balance tables (if treatment variable identified): pre-treatment covariate balance

Output routing:

  • Exploratory figures → output/figures/ (not paper/figures/)
  • Summary statistics → output/tables/ as .csv
  • EDA script → code/01_eda.R (or .py/.do/.jl)

EDA mode stops here.

Phase 3: Estimation

Gate check: Verify the research design is locked before proceeding. The specification (estimand, identifying assumptions, main model) must be documented. This enforces the design-before-results rule. If the user resists the gate, follow shared/escalation-protocol.md — escalate rather than accommodate. For analyses involving human or LLM coding (content analysis, annotation), require per-category reliability per shared/intercoder-reliability.md before estimation.

Generate estimation script(s) covering:

  1. Main specification — as defined in the locked design
  2. Robustness checks — pre-committed alternatives (different SEs, controls, subsamples)
  3. Diagnostics — specification-appropriate tests (first-stage F for IV, parallel trends for DiD, bandwidth sensitivity for RDD)

Read references/estimation-recipes.md for language-specific estimation patterns.

Output:

  • Estimation script → code/02_estimation.R (or equivalent)
  • Coefficient estimates → output/results/ as .rds/.pkl/.dta for downstream table generation

Phase 4: Publication Output

Generate publication-ready tables and figures. Read shared/publication-output.md for format standards and references/table-formatting.md for language-specific recipes.

  1. Main results table — booktabs three-line format, exported as .tex to paper/tables/
  2. Robustness tables — same format, appendix naming convention
  3. Publication figures — coefficient plots, event study plots, mechanism figures → paper/figures/ as PDF
  4. Inline statistics — export \newcommand definitions for key numbers referenced in text

Critical rule: All numbers in .tex files must come from generated files via \input{}. Never hard-code results (per no-hardcoded-results rule). Scripts in code/, outputs in paper/ (per overleaf-separation rule).

Output script → code/03_tables_figures.R (or equivalent)

Phase 5: Save & Review

  1. Verify outputs exist: Check all expected files in paper/tables/ and paper/figures/
  2. Run the code-review agent on all generated scripts (auto-invoke via skill-routing mechanism)
  3. Log the analysis: Record what was done, which scripts were created, which outputs were generated
  4. Suggest next steps: compilation with latex, or additional analyses

Script Structure

Every generated script follows this header template:

# ============================================================
# Script: [filename]
# Purpose: [one-line description]
# Inputs: [list of input files]
# Outputs: [list of output files]
# Dependencies: [packages used]
# Author: [from git config]
# Date: [today]
# ============================================================

Cross-References

ResourceWhen read
shared/multi-language-conventions.mdPhase 1 (language setup)
shared/publication-output.mdPhase 4 (table/figure format)
references/estimation-recipes.mdPhase 3 (estimation code patterns)
references/econ-visualisation.mdPhase 2 & 4 (economics figure/table conventions)
references/table-formatting.mdPhase 4 (language-specific table export)
references/language-conventions.mdPhase 1 (additional language notes)
design-before-results rulePhase 3 gate check
data-sensitivity rulePhase 1 (data access)
no-hardcoded-results rulePhase 4 (output routing)
overleaf-separation rulePhase 4 (file placement)
the code-review agentPhase 5 (auto-invoked)
experiment-design skillSuggested if no design exists
causal-design skillSuggested if no design exists
econ-plots skillEconomics-specific figures
r-econometrics skillR-specific estimation
econ-data skillData download from public APIs

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.