Reuse research software before building it
SkillAI & modelsCovers 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.
No other account needed.
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
- https://research-software-directory.org - the original instance; broad coverage of Dutch research software.
- https://helmholtz.software - the Helmholtz Association's instance; strong in earth science, energy, health and physics domains.
- Both run the open-source RSD-as-a-service platform (https://github.com/research-software-directory/RSD-as-a-service), which any organization can deploy - ask whether the user's own institution runs an instance, and check discipline-specific registries alongside (the rseng-fair-software skill covers registry types).
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:
- 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.
- Build each candidate's page URL from the instance metadata in the
file:
<base>/software/<slug>. - Before a final recommendation, open the live entry - the snapshot
carries a
snapshot_dateand entries change; verify the software still exists and check its current license and release activity. - Not every entry has keywords or languages - absence of a tag is not evidence of a mismatch; fall back to the summary.
- 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:
- 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.
- 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):
- https://research-software-directory.org - general instance
- https://research-software-directory.org/documentation/ - user docs
- https://helmholtz.software - Helmholtz instance
- https://github.com/research-software-directory/RSD-as-a-service - the platform behind the instances
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