Prompts & skills

The copy-paste page: starter prompts to adapt, and complete Claude skill files. When a vetted group version does better than something here, replace it.

Reusable prompts

Copy-pasteable prompts with a one-line “use when”. Add your own in the same format: one fenced block, nothing project-specific.

Verify a claim before citing it

Use when an AI gave you a fact or citation you plan to put in a paper.

Here is a claim I want to cite: <claim>.
Find the primary source. Quote the exact sentence(s) from it that support or
contradict the claim, with a full citation including DOI. If you cannot locate a
primary source, say "no primary source found". Do not substitute a similar paper
and do not guess. If the source only partially supports the claim, state exactly
which part is unsupported.

Adversarial review of AI-written code

Use when accepting a non-trivial AI-written change to analysis code, ideally in a fresh session, so the reviewer isn’t grading its own work.

Review this diff as a skeptical colleague. Do not explain what it does; hunt for
what's wrong. Specifically check: (1) units and unit conversions on every changed
quantity; (2) defaults or identifiers that changed meaning (methods, database
versions, regions, years); (3) filters, cutoffs, or NA-handling that silently
drop data; (4) off-by-one and boundary conditions. For each finding, give the
line and a concrete failing input. If you find nothing, say what you checked.

Surface a method’s assumptions

Use when applying an unfamiliar method (statistical, ML, or IE) to your data.

I plan to use <method> on <one-line description of data and goal>.
List the assumptions this method makes about the data, ordered by how badly the
result degrades when each is violated. For each: how do I test it on my data, and
what is the standard alternative if it fails? Cite a methods reference I can check.

Data-leakage self-check

Use when you’ve built an ML pipeline and want the leakage audit from the reproducibility checklist run against it.

Here is my modeling pipeline, in order: <paste the steps or the code>.
Audit it for data leakage. Check specifically: is the test set isolated before
any normalization, gap-filling, feature selection, or outlier removal? Is any
time-structured data split randomly? Does any preprocessing step see test rows?
Report each check as pass/fail with the offending step named, then suggest the
minimal reordering that fixes the failures.

Extract without inventing

Use when pulling structured data out of reports, EPDs, or papers.

Extract the following fields from the attached document: <fields>.
Rules: quote values exactly as written, with the page or section they came from.
If a field is not stated in the document, write "not stated". Do not infer,
convert, or fill from general knowledge. Flag any value whose unit differs from
the requested unit rather than converting it.

Claude skill files

Reusable Claude skills that package a workflow (checklist + instructions) so it triggers automatically.

Two working skills follow in full. Open Show the skill file and use the copy button. Save the content as SKILL.md in your skills folder, or get the file from skills/ on GitHub.

ml-reproducibility

Enforces the Rankin et al. recommendations whenever a model is trained or reviewed: test-set isolation before preprocessing, a linear baseline first, plain-language pipeline reporting, and the three disqualifying reviewer checks.

Show the skill file

skills/ml-reproducibility/SKILL.md

---
name: ml-reproducibility
description: Use when building, reviewing, or writing up a machine-learning model on research data (LCA, MFA, or any IE dataset); enforces a reproducibility-first workflow that prevents data leakage and under-reported pipelines.
---

# ML reproducibility for IE research

This skill follows the recommendations of
[Rankin et al. (2026)](https://doi.org/10.21203/rs.3.rs-9270723/v1), a CML survey
of ML use in industrial ecology. Two failure modes dominated that survey: **data
leakage** and **poor computational reporting**. Every rule below traces to one of
them.

## When to apply

- The user is training, tuning, or evaluating any predictive model on research data.
- The user is writing the methods section for a study that used ML.
- The user is reviewing someone else's ML-using manuscript (see reviewer mode).

## Workflow rules (builder mode)

1. **Isolate the test set first.** Split the data before *any* preprocessing.
   Fit normalization, gap-filling, feature selection, and outlier removal on the
   training set only. If the data has a time dimension, split by time
   (time-series cross-validation), never randomly.
2. **Ask whether ML is needed at all.** If the hypothesis can be tested with
   empirical data or a mechanistic model, prefer that. ML reproducibility errors
   can't occur in an analysis that doesn't use ML.
3. **Fit the simplest model first.** Report a linear-regression (or equivalent)
   baseline before any complex model. If the complex model barely beats it, say so;
   several best-practice studies found linear models nearly as good.
4. **Fill in a model info sheet.** Use Kapoor & Narayanan's model info sheets to
   check the study against known leakage types before writing up.
5. **Describe the pipeline plainly, in order.** The write-up must say things like
   "we split the data, then normalized, then trained". A reader should be able to
   confirm the order of operations from the text alone.
6. **Justify anything withheld.** If you can't share data, code, or model weights
   (e.g. proprietary data), state why. Point to where readers can get similar data. Transparency is the default; withholding is the documented exception.
7. **Hunt for assumptions.** Before trusting a good test metric, ask: does the data
   reflect the process being modeled? Are there hidden assumptions (sampling,
   temporal ordering, unit handling) that condition the result? Treat this like the
   sensitivity analysis of an LCA/MFA.

## Reviewer mode

When reviewing an ML-using study, check the three **disqualifying errors** first.
You need no ML expertise to spot them, and any one puts the results in serious
dispute:

- [ ] No hold-out test set at all.
- [ ] Temporal leakage: random splits on time-structured data.
- [ ] Normalization, gap-filling, or feature selection performed *before* the
      train/test split.

Then the softer checks:

- [ ] Is a simple baseline reported alongside the complex model?
- [ ] Is the pipeline order stated plainly in the methods?
- [ ] If data/models are withheld, is the reason stated and reasonable? (Withheld
      data alone is *not* disqualifying when the rest follows best practice.)
- [ ] If you can't tell whether an error is present, that ambiguity is itself a
      finding. Ask for clarification in the revision instead of guessing.

## Output

When you apply this skill, state which rules you checked and what you found
("checked test-set isolation: split happens in `split.py` before the scaler
is fit, OK"), not a generic "looks reproducible".

lca-data-sanity-check

A structured pass over AI-written pipeline code: units, defaults, thresholds, mappings, a known-answer test, and a mass/energy balance check.

Show the skill file

skills/lca-data-sanity-check/SKILL.md

---
name: lca-data-sanity-check
description: Use when AI has written or edited code in an LCA/MFA/IO data pipeline; catches silently changed units, defaults, thresholds, and mappings that run without error but change results.
---

# LCA / MFA data-pipeline sanity check

AI-generated pipeline code usually *runs*. The dangerous failures in IE work are the
ones that run silently: a unit conversion dropped, a default swapped, a
characterization method substituted. This skill is a structured pass over an
AI-produced diff before you trust its results.

## When to apply

- After any AI-assisted change to code that computes impacts, flows, stocks, or
  footprints (Brightway, ODYM, pymrio, pandas pipelines, spreadsheets-as-code).
- Before results from such code go into a paper, report, or dataset release.

## The pass

1. **Read the diff, not the summary.** Check every changed line against what you
   asked for. Flag any change you didn't request, however plausible it looks.
2. **Units.** For every quantity the change touches: what unit is it in at each
   step? Look specifically for kg↔t, MJ↔kWh, per-kg↔per-unit, and percent↔fraction
   flips. If the code has no unit annotations, add a comment stating the unit at
   the boundary of the changed code.
3. **Defaults and identifiers.** Did any function default change meaning
   (allocation method, characterization method, database version, region code,
   reference year)? AI models substitute "similar" identifiers, so verify exact
   database/method names against the originals, character for character.
4. **Thresholds and filters.** Did the change add or alter a cutoff, `dropna`,
   filter, or rounding? Quantify what it excludes: row counts before and after.
5. **Mappings.** For any classification/correspondence table the AI wrote or edited
   (e.g. product→material, sector→sector): spot-check entries against the
   authoritative source. Don't trust a generated mapping wholesale.
6. **Known-answer test.** Run the pipeline on a case where the answer is known
   (a published figure, a hand-calculated example, last release's output). "It
   executed without error" is not verification. If no known-answer case exists,
   create one tiny synthetic case and keep it as a regression test.
7. **Mass/energy balance.** Where applicable, check totals: do inputs still equal
   outputs plus stock change within tolerance? A balance that held before the
   change and fails after it points straight at the bug.

## Output

For each item, report what you checked, how, and the result. Attach the failing
case when something breaks. If everything passes, name the known-answer case you
used. A pass without a named test case doesn't count.

To add your own, start from skills/SKILL-template.md. Put each skill in its own folder under skills/. CONTRIBUTING describes the format.