code-and-comment-quality

# Code and Comment Quality An aggregate standard. It defines no rules of its own: it names the skills that carry them and states how to run them in one pass. Load this when a review must cover the code _and_ the prose written around it, rather than running two separate reviews. ## Component Skills Load all three: | Skill | Covers | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | `code-review-and-quality` | Correctness, security, performance | | `code-structure` (review mode) | Layering, placement, file and function shape, helpers, expressions | | `comment-and-documentation-quality` | Code comments, docstrings, READMEs, and commit messages: AI fluff, over-explanation, ghost commentary, tautologies, em dashes | For a GitHub pull request, also load `pr-review-delivery`, which labels, filters and posts the findings as one review. ## Required: Report Missing Skills This aggregate is only as good as the skills it loads, so a missing component is a reportable condition, never something to silently work around. - Before reviewing, confirm each component skill resolves. - **If a component skill cannot be found, STOP and tell the user which skill is missing.** Include the install command `npx skills add dvcrn/skills -g --skill <name>`. Do not fall back to your own idea of the standard, do not guess at its contents, and do not continue with the remaining skill as though the review were complete. - If a skill is missing but the user has already been told and asks you to proceed anyway, run the review with the skills that did resolve and state plainly in the output which standard was not applied. ## Running All in One Pass Review the target once, judging every change against all three standards, and emit a single report rather than two. - Label every finding with the review skill's severity labels, whatever its source. For a pull request, use the High, Medium and Low levels from `pr-review-delivery`. - A comment or documentation finding is a normal finding. Give it the same severity treatment as a code finding, and anchor it to the line it concerns. - Do not open a separate "comments" report or append a second summary. One review, one verdict. - The comment audit applies to prose _in the diff under review_. Do not audit unrelated files the change did not touch. ## Enforced Axes 1. **Correctness**: Bugs, edge cases, error handling, test validity. 2. **Readability & Simplicity**: Function shape, helpers, naming, expressions (`code-structure` R4 to R6). 3. **Architecture**: Layering, placement, file growth, abstractions (`code-structure` R1 to R3, R5). 4. **Security**: Vulnerabilities, input validation, external data handling. 5. **Performance**: Bottlenecks, N+1 query patterns, memory usage. 6. **Comments & Documentation**: Signal-free commentary, restated code, ghost commentary about what changed, narrative fluff, and the punctuation and tone rules from `comment-and-documentation-quality`.