fdiblen

Covers user experience and accessibility for research software: UX disciplines, accessibility practice, Design Thinking, scoping a Minimum Viable Product versus a Minimum Loveable Product, Nielsen's usability heuristics, and prototyping with tools like Figma and Miro. Also covers WCAG conformance for web-facing tools, accessibility testing, CLI usability guidelines and inclusive defaults. Use PROACTIVELY when creating or reshaping a user-facing interface (CLI, GUI, web), and when the user designs a research tool's interface (web, GUI or CLI), asks how to make research software usable or accessible, plans user testing or prototyping, or mentions usability heuristics, WCAG, UX or a11y in a research software context.

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

Covers securing research software and its supply chain: secrets and sensitive-file hygiene (env files, keys, credentials and the never-commit file catalog) with leak response, dependency vulnerability scanning and pinning, OpenSSF Scorecard and Best Practices badge, SLSA provenance levels, SBOMs, signed releases and repository hardening. Use PROACTIVELY when setting up CI or releases, when an API key, password, credential or token is committed or appears in code or history, when the user asks how secure their project or dependencies are, or mentions Scorecard, SLSA, SBOM, CVEs or secret scanning. For the agent itself see rseng-agent-security; for GDPR and personal-data obligations see rseng-regulatory-compliance; for sensitive-data storage practice see rseng-data-management.

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

Covers measuring code health quantitatively: cyclomatic complexity, code duplication, coupling and cohesion, code churn, maintainability index, size conventions and documentation coverage - running radon, lizard, jscpd, interrogate and SonarQube-class tools, interpreting numbers against community conventions and the software's tier, wiring metric gates into CI, and avoiding metric gaming. Use when the user asks how healthy, complex or maintainable their code is, wants metrics or duplication measured, mentions cyclomatic complexity, churn, coupling or maintainability index, or when a quality assessment (rseng-quality-framework) needs the quantitative half. For style and linting see rseng-code-quality; for runtime performance measurement see rseng-performance-profiling.

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

Covers running user support as an operation for research software: triaging and answering support requests, converting recurring questions into documentation and FAQ entries, office hours and support channels, forum gardening, and feeding support signals into the roadmap. Use when support questions arrive faster than they are answered, when the same question keeps being answered by hand, when the user asks how to organize support, office hours or a helpdesk for their software, or when support load is invisible to planning.

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

Covers how to test research software: choosing test types and levels (unit, integration, system, regression, property-based, golden-master), test frameworks and coverage, TDD, validating analysis code against reference cases, and taming CI testing matrices across compilers, platforms and dependency versions. Use when the user asks how to write tests, set up pytest/testthat/JUnit, decide what to test, raise or interpret code coverage, do test-driven development, or when a CI matrix is exploding. Also use PROACTIVELY when new result-bearing code is written without tests, and before declaring any deliverable complete - the shipped entry point must be run and verified working, not only the test suite. For CI pipeline setup see rseng-ci-cd; for review-time test scrutiny see rseng-code-review.

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

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.

Covers choosing and handling scientific data formats in code: HDF5 and NetCDF for array data, CF conventions and standard metadata, Parquet for tabular data, domain standards (NeXus and similar), self-describing files, chunking and compression choices, and migrating away from fragile formats like pickles and ad-hoc binaries. Use when the user chooses a file format for research data, reads or writes HDF5/NetCDF/Parquet/zarr-style stores, asks about chunking, compression or metadata embedding, or ships data in CSV, pickle, MAT or homegrown binary formats that deserve scrutiny. (The surrounding data practice - versioning, deposit, licensing, documentation - is rseng-data-management.)

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

Covers designing research software: modularity and separation of concerns, interfaces and coupling, growing from script to package, the rule of three and the reuse ladder, architecture styles for research systems (pipeline, layered, plugin, services), quality-attribute trade-offs, visual design documentation (C4, Mermaid, PlantUML diagrams-as-code) and architecture decision records. Use when starting non-trivial research software, when a script has grown past easy understanding, when the user asks how to structure or architect code, wants an architecture, API or data-flow diagram, or mentions modularity, coupling, design patterns or refactoring toward structure. For file layout and style see rseng-code-quality; for restructuring inherited code see rseng-legacy-code.

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

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.)

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

Covers teaching research software skills while working: turning everyday coding moments into short, learner-centered lessons using Carpentries/CodeRefinery-style pedagogy (objective-led episodes, formative checks, error normalization), and routing learners to canonical training materials. Use when a teachable moment appears during a task (offer a one-line lesson, never lecture), when the user asks to learn a topic, requests an explanation or tutorial, wants training material recommendations, is preparing to teach others, or when a developed project should ship a build story (docs/BUILD-STORY.md) explaining its design, technology and process choices for new developers. For onboarding cohorts see rseng-contributor-onboarding.

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

Covers building, choosing, discovering, describing, and sharing computational workflows with workflow management systems - when to move off ad-hoc scripts onto a WMS, how to make workflows FAIR, and where to find or register them. Use when the user asks how to automate a multi-step data pipeline, mentions Snakemake, Nextflow, CWL, WDL, Galaxy, Apache Airflow, Parsl, nf-core, or WorkflowHub, wants to pick a workflow engine, package a workflow with RO-Crate metadata, or make an analysis pipeline reproducible and reusable.

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

Covers using version control effectively for research software and the PR-time review process: choosing a VCS, branching and commit practice, authorship and signatures in commit metadata (author/committer identity, Co-authored-by trailers, signed commits and tags, .mailmap), collaboration on GitHub/GitLab, and constructive checklist-driven pull-request reviews. Use when the user asks how to set up git, design a branching strategy, write commit messages, record who authored or co-authored a change, sign commits or tags, handle large binary files, open or review a pull/merge request, or wire linters and CI into review. (Audits of existing code and milestone reviews: rseng-code-review; pre-reviewing your own draft: rseng-pair-programming.)

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

Covers telling the story of research data, software and projects to broad audiences: narrative structure for data stories, turning milestones into human-centered stories, and citizen-science engagement - recruiting contributors, closing the feedback loop with data stories, honest narrative that never oversells. Use when the user wants to explain a project, dataset or tool to non-specialists, mentions storytelling, outreach, public engagement or citizen science, or needs project stories for websites, funders or volunteers. (Research-facing outputs - software papers, talks, announcements: rseng-science-communication; in-repo docs: rseng-documentation.)

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

Covers publishing research software through its distribution channels: packaging for and releasing on package indexes (PyPI, conda-forge, CRAN and ecosystem equivalents), registering in research software registries, submitting to software journals (JOSS-style), and choosing the channel mix for a project's audience. Use when the user wants their software installable by others, asks how to publish on PyPI, CRAN or conda-forge, wants the software listed where researchers search, or when a mature project is only obtainable by cloning its repository. (Cutting versioned releases and DOIs: rseng-publishing-releasing; the JOSS review process: rseng-software-peer-review; preservation: rseng-archiving.)

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

Covers integrity checks on research outputs before submission or release: statcheck/GRIM-style consistency of reported statistics, agreement between manuscript numbers and pipeline outputs, retraction screening of cited work, sanity checks on tables and figures against the data, and an auditable pre-submission checklist. Use PROACTIVELY before manuscript submission or release of result-bearing reports, when reported numbers are transcribed from analysis outputs, and when the user asks to check a paper's numbers, mentions statcheck, GRIM or integrity checks, or suspects a mismatch between code outputs and text. (Reference existence and retractions: rseng-citation-hygiene; claim-source support: rseng-fact-checking; concealment requests: rseng-honesty.)

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

Covers communicating research software outward to research audiences: supporting the user's software papers (JOSS/SoftwareX-style) with outlines, gathered material and structure - never writing a submission-ready manuscript - plus release announcements, lay summaries of what the software does, talk and poster outlines, blog posts, and making a package findable to its intended users. Use when the user wants to announce, present, promote or explain their research software, asks for help with a software paper, talk abstract or release post, or when a mature package has no visibility beyond its authors. In-repo docs live in rseng-documentation; public and citizen-science narrative in rseng-storytelling; venue mechanics and review preparation in rseng-software-peer-review.

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

Covers visualization of scientific data beyond publication figures: 3D and volumetric rendering with ParaView and VTK, scripted and reproducible visualization pipelines, state files and Python trace for repeatability, in-situ visualization of running simulations, web-delivered interactive 3D (trame-style apps), and choosing honest colormaps and representations for spatial data. Use when the user works with 3D, volumetric, mesh or simulation output data, mentions ParaView, VTK or interactive 3D viewers, needs a visualization others can regenerate, or wants to inspect large simulation results.

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

Covers research data management around software: organizing and documenting datasets (layout, data dictionaries), keeping data out of git while versioning it properly (DVC, git-annex, DataLad), FAIR data and metadata standards, depositing data with DOIs in repositories such as Zenodo, licensing data, and handling sensitive or personal data. Use PROACTIVELY when a project reads or produces datasets, when the user asks where to put data, how to version or share large files, how to document a dataset, which data license or repository to use, or when data files are about to be committed to a code repository. (Format engineering - HDF5, NetCDF, Parquet, chunking - is rseng-scientific-file-formats; funder data management plans are rseng-data-management-plans.)

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

Covers data management plans (DMPs) for research projects: what funders require, drafting a DMP from the project's actual data reality (types, volumes, storage, sharing, preservation, responsibilities, costs), machine-actionable DMPs (RDA common standard, Data Stewardship Wizard, DMPonline funder templates), and keeping the plan synchronized with practice. Use when a proposal or project needs a DMP, when the user mentions data management plans, maDMPs, DS-Wizard or DMPonline, when funder or institutional data policy applies, or when the existing DMP has drifted from what the project actually does with its data. (Day-to-day data practice is rseng-data-management; the software management plan twin is rseng-management-planning.)

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

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.

Covers turning users into contributors and contributors into regulars: curating genuinely good first issues, onboarding paths and checklists generated from the repository, first-PR shepherding, mentorship and buddy structures, and measuring where the contribution funnel leaks. Use when a project wants contributors but gets none, when first-time contributors do not return, when the user asks for good-first-issue curation, onboarding documentation or mentorship structure, or when a team member or student is joining a research software project.

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

Covers assessing research software against the 17 FAIR4RS principles with FAIRGuard (https://www.fairguard.org): compliance scores and levels (bronze to platinum), assessment profiles, quality gates for CI, .fairguard.yml configuration, per-indicator skips, and acting on findings. Use PROACTIVELY on research software projects - at repo intake, before releases, after adding publication metadata - and act on its findings. Also use when the user asks to check FAIR compliance, wants a FAIR score, report or badge level, wants a FAIR quality gate in CI, or mentions fairguard, FAIR4RS or .fairguard.yml. (FAIR concepts, principles and hand-guided improvement are rseng-fair-software; ML artifacts are rseng-fair-ml.)

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

Covers measuring community health with CHAOSS-style metrics: contributor growth and retention, bus factor, first-response and review latency, the casual-to-regular contributor conversion funnel, and organizational diversity - computed from forge data, interpreted against project stage, and turned into community actions rather than vanity dashboards. Use when the user asks how healthy their community is, wants contributor or responsiveness statistics, mentions CHAOSS or community metrics, prepares a sustainability report or grant renewal needing community evidence, or when community trends (rising latency, shrinking contributor base) should be checked rather than felt.

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

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.