sysndd-code-quality

Stars6

Forks0

UpdatedMay 18, 2026 at 22:23

Use when reviewing or changing SysNDD code for maintainability, modularity, file size, duplication, simplicity, typed boundaries, tests, or architecture quality before handoff

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

berntpopp

berntpopp/sysndd

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	sysndd-code-quality
description	Use when reviewing or changing SysNDD code for maintainability, modularity, file size, duplication, simplicity, typed boundaries, tests, or architecture quality before handoff

SysNDD Code Quality

Use this skill as a focused review pass before handoff, during refactors, or when touching large or shared SysNDD files.

Review Workflow

Inspect the diff and the nearby implementation patterns before judging the change.
Run deterministic checks first when they are relevant: make code-quality-audit, git diff --check, targeted tests, make lint-api, make lint-app, cd app && npm run type-check, cd app && npm run type-check:strict, or the smallest useful single-test command from AGENTS.md.
Review the changed files for the quality risks below.
Report concrete findings with file and line references. Distinguish must-fix issues from optional cleanup.

Quality Checks

Modularity: each file/module should have one clear responsibility and a readable public surface. Prefer cohesive helpers, composables, services, or repository functions over adding another mode to an already broad file.
600-line soft ceiling: flag handwritten source files that exceed or approach 600 lines when the change makes them larger. make code-quality-audit enforces the deterministic ratchet: new oversized files fail, and baseline oversized files may not grow. Tests, migrations, fixtures, generated files, and tightly coupled implementations may exceed the ceiling when splitting would reduce clarity.
KISS: prefer direct, local solutions that match existing patterns. Push back on speculative abstractions, new dependencies, clever generic utilities, and cross-layer shortcuts.
DRY: remove meaningful duplicated business logic, API normalization, query construction, or UI state handling. Do not extract tiny one-off code if it makes call flow harder to follow.
SOLID, pragmatically: apply dependency direction and single-responsibility thinking, but do not introduce class-heavy architecture just to satisfy a slogan.
Frontend boundaries: views and components should use typed clients from app/src/api/*; do not add raw axios calls or direct localStorage.token / localStorage.user access.
API boundaries: endpoint files should stay thin and delegate reusable logic to services/repositories/helpers without dropping required svc_ or service_ prefixes.
Tests: behavior changes need targeted tests or a documented deterministic check. API integration tests that write DB state should use with_test_db_transaction() or document why rollback is not possible.
Docs: update durable docs when behavior, commands, runtime assumptions, or contributor expectations change.

Output

Lead with findings ordered by severity. If there are no findings, say that and list any checks run plus residual risk.

More from this repository

same repository

sysndd-external-proxy

berntpopp/sysndd

Use when adding or changing an external HTTP provider call in SysNDD (gnomAD, Ensembl, UniProt, AlphaFold, MGI, RGD, PubMed, PubTator, MONDO, JAX/HPO) or touching external-call timeouts, retries, caching, or per-request time budgets

2026-07-066

sysndd-frontend-integration

berntpopp/sysndd

Use when wiring a SysNDD Vue 3 view or component to the backend API, adding a typed API client, handling API errors, or binding backend data into BootstrapVueNext tables and tooltips — especially around Plumber response shapes and BVN table/tooltip quirks

2026-07-066

sysndd-migrations-db

berntpopp/sysndd

Use when adding or changing a SysNDD DB migration, editing a SQL view (especially ndd_entity_view or the core read views), touching the migration runner or manifest, restoring a database, or diagnosing a startup failure related to migrations

2026-07-066

sysndd-security-bug-scan

berntpopp/sysndd

Use when reviewing or writing SysNDD code for security vulnerabilities or correctness bugs — authorization/role gates, SQL/expression injection, credential and secret handling, data exposure through public or MCP surfaces, resource-exhaustion/DoS from external calls, error/info leakage, and the repo's known R/Plumber footguns — especially before merging a diff or PR

2026-07-066

sysndd-analysis-snapshots

berntpopp/sysndd

Use when changing gene clustering (STRING/Leiden functional axis or phenotype MCA/HCPC), the analysis snapshot builder or validator, the memoised clustering cache, cache coherence, or LLM cluster summaries — or deploying a clustering change so public endpoints and summaries reflect it

2026-07-066

sysndd-api-testing

berntpopp/sysndd

Use when writing, running, or fixing SysNDD R/Plumber API tests (testthat) — including database-writing tests, running a single test inside the API container, mocking external providers, or diagnosing SKIP-vs-PASS, helper-loading, or path-resolution issues

2026-07-066

SysNDD Code Quality

Use this skill as a focused review pass before handoff, during refactors, or when touching large or shared SysNDD files.

Review Workflow

Inspect the diff and the nearby implementation patterns before judging the change.

Run deterministic checks first when they are relevant: make code-quality-audit, git diff --check, targeted tests, make lint-api, make lint-app, cd app && npm run type-check, cd app && npm run type-check:strict, or the smallest useful single-test command from AGENTS.md.

Review the changed files for the quality risks below.

Report concrete findings with file and line references. Distinguish must-fix issues from optional cleanup.

Quality Checks

Modularity: each file/module should have one clear responsibility and a readable public surface. Prefer cohesive helpers, composables, services, or repository functions over adding another mode to an already broad file.

600-line soft ceiling: flag handwritten source files that exceed or approach 600 lines when the change makes them larger. make code-quality-audit enforces the deterministic ratchet: new oversized files fail, and baseline oversized files may not grow. Tests, migrations, fixtures, generated files, and tightly coupled implementations may exceed the ceiling when splitting would reduce clarity.

KISS: prefer direct, local solutions that match existing patterns. Push back on speculative abstractions, new dependencies, clever generic utilities, and cross-layer shortcuts.

DRY: remove meaningful duplicated business logic, API normalization, query construction, or UI state handling. Do not extract tiny one-off code if it makes call flow harder to follow.

SOLID, pragmatically: apply dependency direction and single-responsibility thinking, but do not introduce class-heavy architecture just to satisfy a slogan.

Frontend boundaries: views and components should use typed clients from app/src/api/*; do not add raw axios calls or direct localStorage.token / localStorage.user access.

API boundaries: endpoint files should stay thin and delegate reusable logic to services/repositories/helpers without dropping required svc_ or service_ prefixes.

Tests: behavior changes need targeted tests or a documented deterministic check. API integration tests that write DB state should use with_test_db_transaction() or document why rollback is not possible.

Docs: update durable docs when behavior, commands, runtime assumptions, or contributor expectations change.

Output

Lead with findings ordered by severity. If there are no findings, say that and list any checks run plus residual risk.