Skip to content
cccskills
FreePublished on GitHub

rseng-software-peer-review

Covers community peer review of research software: preparing a package for JOSS, pyOpenSci or rOpenSci submission, self-checking against their review criteria before submitting, writing the paper or statement of need, responding to reviews, and acting as a reviewer or CODECHECK-style codechecker who executes the artifact. Use when the user mentions JOSS, pyOpenSci, rOpenSci or CODECHECK, wants to submit software for peer review or publication, asks whether their package is review-ready, or is reviewing someone else's research software for one of these venues. (PR-level code review is rseng-version-control-review; overall publication channel strategy is rseng-software-publishing.)

The English summary is being prepared. Showing the original description.

fdiblen/rseng-agent-skills24 stars(GitHub 24 + cccskills 0)

Run score Not tested

See how to install

Files included (2)

  • SKILL.md5.3 KB
  • references.md534 B

SKILL.md (original)

Review the instructions the agent will receive before you install.

Peer review of research software

Software peer review is the publication pathway where the SOFTWARE is the reviewed artifact: JOSS (any language), rOpenSci (R) and pyOpenSci (Python) run open, constructive reviews against public checklists, and CODECHECK issues certificates that a paper's computations were independently executed. For a maintainer, review readiness is a concrete bar to build toward; passing it earns a citable publication (JOSS papers get DOIs) and a community quality mark. This is review of the whole package - distinct from PR-level code review (rseng-version-control-review).

Pre-submission: self-review against the real checklist

Run the target venue's own checklist against the repository and fix failures BEFORE submitting - reviewers check exactly these:

  • License: OSI-approved LICENSE file at the root (rseng-licensing).
  • Documentation entry points: installation that works from a clean environment, usage examples that run, API docs for the public surface (rseng-documentation).
  • Statement of need: who this is for and what gap it fills - in the README and (for JOSS) the paper; write it for the target researcher, not the maintainer.
  • Tests that run in CI, covering the core claims of the software (rseng-testing, rseng-ci-cd); reviewers will run them.
  • Community files: contributing guidelines and code of conduct (rseng-community-governance).
  • Citation metadata and archiving: CITATION.cff, and a Zenodo (or equivalent) archive with DOI at acceptance (rseng-citation-metadata, rseng-publishing-releasing).
  • AI-usage disclosure: JOSS now asks about AI use in the submission - the project's aidecl.yaml (rseng-ai-declaration) is exactly the honest record to answer from.

Scope check before effort: each venue defines in-scope package types and substantiality; read the venue's scope page first and say honestly if the project is not there yet.

The JOSS paper: the user writes it

Short by design (750-1750 words): summary for non-specialists, statement of need, rough state of the field (neighboring tools and how this differs - rseng-discovery and rseng-software-reuse habits help here), acknowledgements, references with DOIs. It reviews the software; do not pad it into a methods paper. The agent's role is support only: outline against the venue's template, gather the material, check the draft against the criteria and verify its citations - never produce a submission-ready manuscript; authorship and every signed claim stay with the user (rseng-science-communication states the same boundary; JOSS itself asks about AI involvement - answer from aidecl.yaml).

Responding to reviews

Reviews are public issue threads. Respond to every point (fix, discuss, or explain why not), push commits as you go, and summarize changes when done. Tone: reviewers are volunteers improving your software - thank them, and disagree with reasons, not defensiveness.

Reviewing and codechecking

When the user is the reviewer:

  • Work through the venue checklist honestly - install from scratch in a clean environment (rseng-reproducible-environments), run the tests, run the examples; "it probably works" is not a review.
  • File findings as actionable issues, most important first; distinguish must-fix (checklist failures) from suggestions.
  • CODECHECK mode: execute the paper's workflow, record what reproduced (with outputs), what did not, and produce the certificate-style summary of exactly what was checked.
  • Constructive is the norm in this ecosystem: the goal is acceptance-after-improvement, not gatekeeping.

Working with this skill

This skill is source-independent: its authority is the venues' own review criteria and guides linked below.

Learn more (verified):

<!-- related-skills:begin -->

Related skills

Check whether any of these applies before moving on:

  • rseng-ai-declaration - JOSS asks about AI use
  • rseng-citation-metadata - CITATION.cff and DOI at acceptance
  • rseng-discovery - state-of-the-field section material
  • rseng-reproducible-environments - clean-room installs for reviewing
  • rseng-software-publishing - JOSS within the channel mix
  • rseng-version-control-review - PR-level review is distinct
<!-- related-skills:end -->

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Covers operating AI coding agents securely: auditing whether the agent runs sandboxed, permission and dangerous-command configuration, containerized environments, secrets kept out of context, network egress and token privileges, prompt-injection risk, and the privacy of agent use itself. Use PROACTIVELY when permission gating is broadly disabled (skip-permissions modes), when secrets are visible to the agent's shell, or when the agent processes untrusted code, issues or web content; when a project holds personal or confidential data while a cloud agent is active (what leaves the machine, retention, training use), or when the user asks how to run coding agents safely or privately. (Supply-chain security: rseng-security; disclosing agent contributions: rseng-ai-declaration.)

The English summary is being prepared. Showing the original description.

fdiblen/rseng-agent-skills24Updated Sep 23, 2026

Covers declaring AI involvement with the AI Declaration Format (https://ai-declaration.org): creating and maintaining an aidecl.yaml that records which AI tools and agents were used, what each contributed, when and how much, plus the README disclosure footnote, JSON/JSON-LD export and CI validation. Machine-readable disclosure is the practice; this format is one implementation. Use PROACTIVELY when an AI assistant or agent creates or modifies a project's content - generate aidecl.yaml if missing, update it after AI-assisted changes. Also use when the user asks about AI transparency, provenance, disclosure or EU AI Act disclosure, wants to state that NO AI was used, or mentions aidecl. For concealment requests see rseng-honesty; for the human review duty see rseng-human-verification.

The English summary is being prepared. Showing the original description.

fdiblen/rseng-agent-skills24Updated Sep 23, 2026

Covers long-term archiving of research software and data: Software Heritage save requests and SWHID persistent identifiers, Zenodo deposits with versioned DOIs and forge integration, choosing domain and institutional repositories, deciding what to archive (code, data, environments, documentation) and when, and archiving at project retirement. Use when the user wants software or data preserved beyond the life of a forge account, grant or lab, mentions Software Heritage, SWHIDs, Zenodo deposits or archiving, retires or hands over a project, prepares artifacts that must stay resolvable for a paper, or when funder policy requires long-term preservation. (Cutting the release itself is rseng-publishing-releasing; day-to-day data storage and repository choice is rseng-data-management.)

The English summary is being prepared. Showing the original description.

fdiblen/rseng-agent-skills24Updated Sep 23, 2026

Covers processing research data that outgrows one machine's memory: out-of-core and chunked computation, Dask for scaling the scientific Python stack, Spark for distributed tabular pipelines, lazy evaluation, partitioning strategies, idempotent and restartable batch jobs, and knowing when NOT to distribute. Use when datasets no longer fit in memory, when the user mentions Dask, Spark, out-of-core or larger-than-memory data, when a pandas/NumPy workflow hits memory limits, or when designing batch pipelines over many files. (Cluster job submission and job arrays are rseng-hpc-computing; pipeline orchestration engines are rseng-workflows; profile first with rseng-performance-profiling.)

The English summary is being prepared. Showing the original description.

fdiblen/rseng-agent-skills24Updated Sep 23, 2026

Covers continuous integration and delivery for research software: CI/CD concepts, automating builds and tests with GitHub Actions and GitLab CI/CD, and wiring an organization's GitLab CI infrastructure to a GitHub-hosted project. Use when the user asks to set up CI, write a pipeline or workflow file (.github/workflows, .gitlab-ci.yml), add automated builds/tests on push or pull request, publish a package or deploy docs when a tag or release is cut, cache dependencies to speed up CI runs, choose between GitHub Actions and GitLab CI, use self-hosted or GPU runners, mirror a repo, or report external CI status back to GitHub. For what to test and shrinking a test matrix see rseng-testing; for linter and pre-commit policy see rseng-code-quality.

The English summary is being prepared. Showing the original description.

fdiblen/rseng-agent-skills24Updated Sep 23, 2026

Covers verifying that every citation is real, correct and current: checking references in manuscripts, READMEs, references files and code metadata against Crossref and OpenAlex, screening cited DOIs against the Retraction Watch database, catching fabricated or mis-attributed citations (a documented AI failure mode), and keeping bibliographies and CITATION.cff files resolvable. Use PROACTIVELY before any bibliography, reference list or citation metadata is finalized or published, whenever the agent itself has produced citations, and when the user asks to check references, mentions broken DOIs, retracted papers or citation verification, or prepares a manuscript, README or software paper with references. (Making your own software citable is rseng-citation-metadata.)

The English summary is being prepared. Showing the original description.

fdiblen/rseng-agent-skills24Updated Sep 23, 2026

See all skills by fdiblen

Report a problem with this skill