research-software-versions
Skill1 starsChanged 4 months agoMITView on GitHub
Research the appropriate stable version of one software component before installation or migration. Use for compatibility, deprecation, and migration evidence; remain read-only and project-constrained.
In this repository15 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- apply-project-updatesSkill
- audit-project-updatesSkill
- design-agent-capabilitySkill
- engineer-cli-toolsSkill
- maintain-agent-instructionsSkill
- maintain-project-docsSkill
- maintain-project-memorySkill
- maintain-web-design-systemSkill
- prepare-web-assetsSkill
- red-team-technical-planSkill
- release-web-applicationSkill
- verify-software-changeSkill
- web-discovery-artifactsSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
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
- Distinctive: line 27
Use current sources in this order where available:
- Very specific: line 35
Read references/source-policy.md for projects without conventional releases.
- Distinctive: line 36
Do not infer stability from a default branch or download badge.
- Distinctive: line 48
Do not introduce prereleases unless explicitly requested and justified.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Research Software Versions
Recommend the latest appropriate stable version, not simply the highest number.
Establish the compatibility envelope
Inspect:
- manifests and lockfiles
- runtime and toolchain files
- engine and platform constraints
- CI and deployment matrices
- transitive requirements and native dependencies
- existing compatibility decisions
- repository-specific validation restrictions
Identify the currently declared, resolved, installed, and deployed states. Treat them as distinct.
Research authoritatively
Use current sources in this order where available:
- security and support policy
- first-party registry or release index
- official documentation and migration guide
- official changelog and release notes
- upstream repository release or tag
Read references/source-policy.md for projects without conventional releases.
Do not infer stability from a default branch or download badge.
Evaluate:
- runtime and operating-system requirements
- removed or renamed APIs and flags
- feature and default changes
- transitive and lockfile impact
- deployment-platform compatibility
- maintenance status and release age
- known regressions or security advisories
Do not introduce prereleases unless explicitly requested and justified.
Recommend
State:
- current declared and resolved version
- latest stable available
- latest compatible under current constraints
- recommended version
- why newer or older candidates were rejected
- required migration
- verification path and rollback
- authoritative sources and date checked
Required upgrades, security response, routine maintenance, and optional enhancements must remain separate. Do not apply unrelated upgrades without approval.
Define verification
Define the project's approved build, test, or deployment evidence for the later
implementation. Preserve lockfile reproducibility in the recommendation. Do not
claim proven project compatibility from documentation alone. Stop before
editing files or running mutating update commands; hand an authorized selection
to apply-project-updates.
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
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.