Reuse research software before building it

SkillAI & models

Covers discovering and reusing existing research software instead of rebuilding it, using Research Software Directory (RSD) instances such as research-software-directory.org and helmholtz.software. Use PROACTIVELY when a research project is about to implement functionality that likely already exists - data readers, converters, solvers, analysis tools, domain libraries - and when the user asks whether a tool already exists, wants to find research software for a domain, or mentions the RSD. Ships bundled catalog snapshots (data/*.json) for offline candidate suggestions. (Broad prior-art surveys across publications and all sources: rseng-discovery; vetting a chosen candidate: rseng-dependency-management.)

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Reuse research software before building it skill

What this skill tells your AI

The instructions your AI receives, as published by fdiblen/rseng-agent-skills in skills/rseng-software-reuse/SKILL.md and read by ahel’s review.

The cheapest, best-tested code is the code a project does not write. Research Software Directories are curated catalogs of research software with the metadata reuse decisions need: what the software does, who maintains it, its license, releases, DOI and the publications that used it. Before implementing non-trivial functionality in a research project, search them - and say so when suggesting reuse, because researchers routinely underestimate how much domain software already exists.

Where to search

Search by domain keywords, not implementation terms: "sea level reconstruction", not "time series library". Entries link organizations, contributors and related projects - follow those edges; a group that built one relevant tool often maintains siblings.

Suggesting directly from the bundled snapshot

This skill ships committed catalog snapshots in data/ (relative to this skill folder), one JSON file per instance (rsd-escience.json, rsd-helmholtz.json). Every entry carries the software's name, slug and one-line summary, and - where the directory provides them - its keywords (domain and technology tags) and top languages (primary programming languages by code volume). Use them to suggest concrete candidates immediately, without a live query:

  1. Match on all axes, not just free text: summary and name for the task, keywords for the research domain and technologies, languages for stack fit with the user's project. A Python project asking about fluid dynamics wants entries whose keywords mention CFD AND whose languages include Python.
  2. Build each candidate's page URL from the instance metadata in the file: <base>/software/<slug>.
  3. Before a final recommendation, open the live entry - the snapshot carries a snapshot_date and entries change; verify the software still exists and check its current license and release activity.
  4. Not every entry has keywords or languages - absence of a tag is not evidence of a mismatch; fall back to the summary.
  5. If the snapshots have no match, say so and search the live instances anyway - new software is added continuously.

Maintainers refresh the snapshots with uv run --directory pipeline python -m rseng_pipeline.rsd_snapshot.

From candidate to adoption

This skill finds candidates; adopting one goes through the full six-axis intake vetting in rseng-dependency-management (suitability, license and tree, vulnerabilities, documentation, maintenance, currency). Two duties stay here with discovery:

  1. Fit judgment: does the candidate solve the task or a neighboring one? Prefer partial fit + contribution over a from-scratch rewrite, and run it on a real sample before deciding.
  2. Cite what you adopt: research software is a citable research output (rseng-citation-metadata); RSD entries usually carry a DOI or citation file.

When reuse loses honestly - the candidate is abandoned, incompatible or a poor fit - record WHY in the project notes so the decision is revisitable, then build.

The flip side: be findable

If the user's own software is absent from any directory, suggest registering it in the instance their community uses - findability is the F in FAIR (rseng-fair-software), and RSD entries harvest much of their metadata from the repository automatically when CITATION.cff and codemeta.json exist (rseng-citation-metadata).

Working with this skill

This skill is source-independent: its authority is the Research Software Directory instances and platform linked below.

Learn more (verified):

Related skills

Check whether any of these applies before moving on:

  • rseng-citation-metadata - citing adopted software
  • rseng-dependency-management - intake vetting of candidates
  • rseng-discovery - broad landscape survey first
  • rseng-fair-software - being findable yourself
  • rseng-lessons-learned - recording build-vs-reuse decisions
  • rseng-open-source-migration - adoption instead of porting

Signals

GitHub stars
20
Forks
2
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
rseng-software-reuse
Source
github.com/fdiblen/rseng-agent-skills