rseng-code-quality
SolidCovers 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.
Install
Quality Score: 83/100
Skill Content
Details
- Author
- fdiblen
- Repository
- fdiblen/rseng-agent-skills
- Created
- 4 days ago
- Last Updated
- 4 days ago
- Language
- Python
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
rseng-code-review
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.
rseng-documentation
Covers how to document research software at every level: writing a README, code-level docs (comments, docstrings, API and CLI help), project docs (INSTALL, CONTRIBUTING, LICENSE, CITATION, changelog), publishing hosted documentation with Read the Docs, and capturing a Research Software Story. Use when the user asks how to write or improve a README, decide what documentation their project needs, add docstrings or inline comments, document an API or CLI, set up Sphinx/MkDocs/Doxygen, host docs on Read the Docs, structure a docs site, or write the narrative context and history behind a project. For outward-facing papers, talks and announcements see rseng-science-communication; for public and citizen-science narrative see rseng-storytelling.
rseng-fair-software
Covers how to apply the FAIR principles - findable, accessible, interoperable, reusable - to research software, and how to assess a project's FAIRness. Use when the user asks how to make software FAIR, wants help with findability, discoverability, or software reuse, mentions metadata, persistent identifiers, DOIs, registries, or software citation in a FAIR context, or asks to run a FAIR self-assessment or checklist on a repository. (Automated FAIR4RS scoring, compliance levels and CI gates with the FAIRGuard tool are rseng-fairguard; FAIR for ML models and datasets is rseng-fair-ml; finding existing software to reuse is rseng-software-reuse.)