fdiblen

Covers end-to-end computational reproducibility: making a project's results regenerable with one command, determinism and seed discipline, research compendium structure, replication packages for papers, Binder-launchable repositories, artifact evaluation and reproducibility badges. Use PROACTIVELY when the user wants results others can reproduce, prepares a replication package or artifact submission, mentions reproducibility, research compendia, Binder or badges, asks why results differ between runs or machines, or is about to publish results whose regeneration path is untested. (Pinning environments: rseng-reproducible-environments; pipeline automation: rseng-workflows; run-level lineage: rseng-provenance.)

日本語の概要は準備中です。原文の説明を表示しています。

Covers making research software environments reproducible: pinning a language version and its dependencies in a per-project virtual environment, choosing a package/environment manager, and packaging code and its full stack into a container. Use when the user asks how to set up venv/conda/poetry/uv/renv, lock or pin dependencies, share a runnable environment, escape "dependency hell" or "works on my machine", write a Dockerfile, build an Apptainer/Singularity image for HPC, or decide between a virtual environment and a container. For regenerating a project's results end to end see rseng-reproducibility; for environments of multi-step pipelines see rseng-workflows.

日本語の概要は準備中です。原文の説明を表示しています。

Covers making research code faster with evidence: profiling before optimizing (py-spy and language-native profilers), interpreting hotspots, choosing optimizations by measured payoff, benchmark regression tracking with airspeed velocity (asv), and scaling measurements. Use when the user says their code is slow, asks to optimize or speed something up, wants benchmarks or performance regression tests, or before recommending rewrites, parallelism or GPUs on performance grounds.

日本語の概要は準備中です。原文の説明を表示しています。

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

日本語の概要は準備中です。原文の説明を表示しています。

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.

日本語の概要は準備中です。原文の説明を表示しています。

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

日本語の概要は準備中です。原文の説明を表示しています。

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

日本語の概要は準備中です。原文の説明を表示しています。

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.

日本語の概要は準備中です。原文の説明を表示しています。

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

日本語の概要は準備中です。原文の説明を表示しています。

Covers making research software citable and contributors credited: writing CITATION.cff, describing software with CodeMeta (codemeta.json), minting DOIs and ORCIDs, and tracking contributors of every kind. Use when the user asks how to make software citable, add CITATION.cff or codemeta.json, obtain a DOI, ensure contributors get credit, or mentions CFF, CodeMeta, ORCID, CRediT or persistent identifiers. Use PROACTIVELY when generated code draws on a publication, website or existing code (credit it at the code site and in the references), at release preparation, and when citation files are edited. (Verifying references you cite: rseng-citation-hygiene; versioning schemes and the DOI-minting release: rseng-publishing-releasing.)

日本語の概要は準備中です。原文の説明を表示しています。

Covers writing readable research code and structuring software projects: naming, formatting, style guides, linters and formatters, pre-commit hooks, modular design, and a conventional directory layout with top-level metadata files. Use when the user asks how to make code readable or clean, pick or enforce a style guide, set up linting/formatting or pre-commit, name variables and functions, organise a repo, or decide where files and data go. For generating a new project from a maintained template see rseng-project-scaffolding; for quantitative complexity and duplication measurement see rseng-software-metrics; for architecture-level structure see rseng-software-design.

日本語の概要は準備中です。原文の説明を表示しています。

Covers reviewing existing code and whole projects, not just new diffs: structured codebase audits that produce ranked findings and then implement the agreed improvements, recurring project reviews after major tasks and milestones, review scoping by risk and tier, and turning review findings into tracked work and lessons. Use PROACTIVELY after major tasks and milestones, and when the user asks for a code review, codebase audit or health check of existing code, wants improvements suggested and applied, mentions reviewing the project after a milestone or before a release or submission, or when inherited or long-unreviewed code needs a structured pass. For diff-time pre-review of new work see rseng-pair-programming; for PR-time review process and rules see rseng-version-control-review.

日本語の概要は準備中です。原文の説明を表示しています。

Covers building and governing a community around research software: CONTRIBUTING guides, codes of conduct, governance models and decision-making, contributor recognition policy, issue and discussion hygiene, and handing over or sharing maintainership. Use when a project wants external contributors, when the user asks for a CONTRIBUTING.md, code of conduct or governance document, when maintainer burnout or bus-factor risks come up, or when a project is moving from single-author to team or community ownership. The contributor funnel and good-first-issue curation live in rseng-contributor-onboarding; health measurement in rseng-community-metrics; support operations in rseng-user-support.

日本語の概要は準備中です。原文の説明を表示しています。

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.

日本語の概要は準備中です。原文の説明を表示しています。

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.

日本語の概要は準備中です。原文の説明を表示しています。

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

日本語の概要は準備中です。原文の説明を表示しています。

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

日本語の概要は準備中です。原文の説明を表示しています。

Covers systematic debugging of research software: hypothesis-driven diagnosis instead of guess-and-change, building minimal reproducers, bisecting across commits, data and parameters, debugging scientific failure modes (wrong numbers rather than crashes, nondeterminism, scale-dependent bugs), debugger and print-discipline mechanics, and turning every fix into a regression test. Use when the user reports a bug, a crash, wrong or changed results, a heisenbug or an it-works-on-my-machine discrepancy, when a pipeline fails at scale but not in tests, or when the user is stuck guessing instead of diagnosing. For preventing silent wrong-result bugs see rseng-defensive-coding; for judging whether numerical differences matter see rseng-numerical-accuracy.

日本語の概要は準備中です。原文の説明を表示しています。

Covers defenses against silently wrong research results: validating data at boundaries (schemas, assertions, sanity checks), explicit physical units and quantities in code (pint/astropy-style), disciplined randomness (explicit seeded generators, parallel streams), and fail-loud handling of NaN and missing data. Use PROACTIVELY when code ingests external or instrument data, when values carry physical units, when randomness enters simulations or sampling, or when NaN or missing-data handling is implicit; also when the user mentions data validation, unit errors, seeds or silent bugs, or reviews analysis code whose failure would be invisible. For floating-point behavior and tolerances see rseng-numerical-accuracy; for diagnosing an existing bug see rseng-debugging.

日本語の概要は準備中です。原文の説明を表示しています。