
Code Reviewer Colony
Run a consistent PR review against readability, safety, testability, and performance before you merge agent-generated or hand-written changes.
Overview
Code Reviewer Colony is an agent skill most often used in Ship (also Build) that applies general code review principles for readability, maintainability, safety, and testability on code changes.
Install
npx skills add https://github.com/mols3131d/mols-agent-assets --skill code-reviewer-colonyWhat is this skill?
- Four principle areas: readability & maintainability, defensive programming & safety, testability, performance & efficien
- Enforces intent-revealing names, SRP, short functions (prefer under 30 lines), and early returns over deep nesting
- Requires boundary input validation, structured error handling without silent swallows, and no secrets/PII in logs
- Points reviewers to architectural-patterns reference for structure and naming consistency
- Separates business logic from side effects to keep unit tests and mocking simple
- Four numbered review principle sections
- Prefer functions under 30 lines
Adoption & trust: 1 installs on skills.sh; trending (+100% hot-view momentum).
What problem does it solve?
You are merging changes but lack a shared bar for naming, safety, tests, and structure, so reviews become inconsistent or miss boundary and error-handling gaps.
Who is it for?
Solo builders reviewing PRs, agent-generated patches, or refactors before merge when you want principle-based feedback without a full enterprise review process.
Skip if: Teams that need automated SAST, license compliance, or formal security sign-off only—use dedicated security and CI tooling alongside this skill.
When should I use this skill?
You want general code review guidelines applied to a change covering readability, maintainability, safety, and testability.
What do I get? / Deliverables
You get a structured review aligned to SRP, defensive checks, and testability so the change is easier to maintain and safer to ship.
- Structured review notes by principle area
- Actionable issues on naming, safety, tests, and performance
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the skill is written as code-change review guidance aligned with merge readiness and quality gates. Review subphase matches structured PR/code review principles rather than authoring features or deploying.
Where it fits
Review a new API handler for boundary validation and decoupled business logic before you wire CI.
Walk a PR diff for naming, nesting, and silent exception handling before merge.
Check whether changes remain easy to unit test without heavy DB mocks.
Review a hotfix patch for null safety and logging without leaking secrets.
How it compares
Use instead of one-off “LGTM” chat reviews when you want repeatable maintainability and safety criteria, not instead of linters or test runners.
Common Questions / FAQ
Who is code-reviewer-colony for?
Solo and indie developers shipping with AI coding agents who want consistent human-style review criteria on every diff or PR.
When should I use code-reviewer-colony?
Use it during Ship review before merge, and during Build when you iterate on backend or API changes and want the same bar applied early; invoke whenever you have a concrete code change to critique.
Is code-reviewer-colony safe to install?
It is guidance-only review methodology with no implied shell or network access; check the Security Audits panel on this Prism page before installing any skill package from the catalog.
SKILL.md
READMESKILL.md - Code Reviewer Colony
# Code Review Principles Guidelines for reviewing code changes to ensure high maintainability, correctness, and safety. --- ## 1. Readability & Maintainability - **Intent-Revealing Names**: Variables, functions, and classes must clearly describe their purpose. Avoid cryptic abbreviations. - **Single Responsibility (SRP)**: Each function and class should do one thing. Keep functions short (prefer < 30 lines). - **Control Flow**: Avoid deep nesting (prefer early returns). Minimize complex conditional logic. - **Structure & Naming**: Refer to the architecture guidelines in [architectural-patterns.md](../../code-builder-colony/references/architectural-patterns.md). ## 2. Defensive Programming & Safety - **Error Handling**: Never swallow exceptions silently. Use structured error boundaries and log relevant details safely (no secrets/PII). - **Input Validation**: Validate all inputs at the boundary. Do not trust external data. - **Null & Boundary Safety**: Guard against null pointer exceptions, index out-of-bounds, and undefined values. ## 3. Testability - **Decoupling**: Keep business logic separated from external side-effects (DB, API) so it is easy to unit test. - **Mocking**: Minimize complex mocking setups by keeping interfaces clean and simple. ## 4. Performance & Efficiency - **Avoid Redundant Work**: Watch out for unnecessary DB queries (e.g., N+1), file I/O inside loops, or redundant API calls. - **Resource Management**: Ensure files, database connections, and sockets are properly closed or disposed of. #!/usr/bin/env python3 import argparse import re import sys def parse_args(): parser = argparse.ArgumentParser( description="Analyze a git diff and suggest appropriate reviewer sub-skills." ) parser.add_argument( "--diff-file", help="Path to a file containing git diff output. If not provided, reads from stdin." ) parser.add_argument( "--git", nargs="?", const="HEAD", help="Run 'git diff' on the specified ref (defaults to HEAD)." ) return parser.parse_args() def get_diff_content(args): if args.git: import subprocess try: cmd = ["git", "diff", args.git] result = subprocess.run(cmd, capture_output=True, text=True, check=True) return result.stdout except subprocess.CalledProcessError as e: print(f"Error running git command: {e}", file=sys.stderr) sys.exit(1) except FileNotFoundError: print("Error: 'git' command not found in PATH.", file=sys.stderr) sys.exit(1) elif args.diff_file: try: with open(args.diff_file, "r", encoding="utf-8") as f: return f.read() except Exception as e: print(f"Error reading diff file: {e}", file=sys.stderr) sys.exit(1) else: # Read from stdin if sys.stdin.isatty(): print("No input provided. Pipe a diff to stdin or use --git / --diff-file.", file=sys.stderr) sys.exit(1) return sys.stdin.read() def analyze_diff(diff_text): # Regex to capture file paths in git diff # Format: a/path/to/file b/path/to/file or rename from/to file_headers = re.findall(r"^diff --git a/(.*?) b/(.*?)$", diff_text, re.MULTILINE) modified_files = [] for a_path, b_path in file_headers: if b_path not in modified_files: modified_files.append(b_path) # Check for renamed/deleted/added files in the diff headers new_files = re.findall(r"^new file mode \d+\nindex .*?\n--- /dev/null\n\+\+\+ b/(.*?)$", diff_text, re.MULTILINE) deleted_files = re.findall(r"^deleted file mode \d+\nindex .*?\n--- a/(.*?)\n\+\+\+ /dev/null$", diff_text, re.MULTILINE) categories = { "audit-