references/principles.md
---
name: review-principles
description: General code review guidelines and principles covering readability, maintainability, safety, and testability.
---
# 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.
scripts/analyze_diff.py
#!/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-architecture": {"files": [], "reasons": []},
"audit-implementation": {"files": [], "reasons": []},
"audit-performance": {"files": [], "reasons": []},
"audit-security": {"files": [], "reasons": []},
"audit-tests": {"files": [], "reasons": []},
}
# Analyze file paths
for f in modified_files:
# Architecture detection: folder changes, structural configurations, or naming conventions
# e.g., router configuration, project layout configs, directory addition
f_lower = f.lower()
# Test detection: test files or spec files
if any(
term in f_lower for term in ["test", "spec", "mock"]
) or f_lower.endswith("_test.go"):
categories["audit-tests"]["files"].append(f)
if "Test file modified/added" not in categories["audit-tests"]["reasons"]:
categories["audit-tests"]["reasons"].append("Test file modified/added")
continue
# Otherwise, classify implementation
categories["audit-implementation"]["files"].append(f)
if (
"Implementation file modified/added"
not in categories["audit-implementation"]["reasons"]
):
categories["audit-implementation"]["reasons"].append(
"Implementation file modified/added"
)
# Check path for architecture patterns
if "/" not in f:
categories["audit-architecture"]["files"].append(f)
categories["audit-architecture"]["reasons"].append(
f"Root file modified: {f}"
)
elif any(
part in f_lower.split("/")
for part in [
"router",
"handler",
"controller",
"repository",
"service",
"infrastructure",
]
):
categories["audit-architecture"]["files"].append(f)
categories["audit-architecture"]["reasons"].append(
f"Architectural component modified in path: {f}"
)
# Parse individual diff lines for keywords
current_file = None
line_number = 0
# Simple regexes for scanning added lines
sec_keywords = [
(
re.compile(
r"\b(password|passwd|secret|token|api[-_]?key|private[-_]?key|credential)\b",
re.IGNORECASE,
),
"Potential credential/secret leak",
),
(
re.compile(r"\b(eval|exec|system|popen)\b"),
"Unsafe command execution function",
),
(
re.compile(r"\b(unsafe|innerHTML|dangerouslySetInnerHTML)\b"),
"Potential unsafe execution or XSS risk",
),
]
perf_keywords = [
(
re.compile(
r"\b(select\s+\*|insert\s+into|update\s+|delete\s+from)\b",
re.IGNORECASE,
),
"SQL Query found (verify index and N+1 query safety)",
),
(
re.compile(
r"\b(while\s*\(true\)|for\s+.*\b(in|of)\b.*inside\s+loop|nested\s+loops)\b",
re.IGNORECASE,
),
"Potential loop efficiency check needed",
),
]
lines = diff_text.splitlines()
for line in lines:
if line.startswith("+++ b/"):
current_file = line[6:]
line_number = 0
continue
elif line.startswith("@@"):
# Try to get starting line number
match = re.search(r"\+(\d+)", line)
if match:
line_number = int(match.group(1)) - 1
continue
# If we have a file context and it's an added line
if current_file and line.startswith("+") and not line.startswith("+++"):
line_number += 1
content = line[1:]
# Check security keywords
for pattern, desc in sec_keywords:
if pattern.search(content):
categories["audit-security"]["files"].append(current_file)
categories["audit-security"]["reasons"].append(
f"{desc} in {current_file}:{line_number}"
)
# Check performance keywords
for pattern, desc in perf_keywords:
if pattern.search(content):
categories["audit-performance"]["files"].append(current_file)
categories["audit-performance"]["reasons"].append(
f"{desc} in {current_file}:{line_number}"
)
# Post process duplicates
for cat in categories:
categories[cat]["files"] = sorted(list(set(categories[cat]["files"])))
categories[cat]["reasons"] = sorted(list(set(categories[cat]["reasons"])))
return categories, new_files, deleted_files
def main():
args = parse_args()
diff_text = get_diff_content(args)
if not diff_text.strip():
print("Diff is empty.")
return
categories, new_files, deleted_files = analyze_diff(diff_text)
print("# Diff Analysis Summary")
print(f"\n- **New files**: {len(new_files)}")
for nf in new_files:
print(f" - `{nf}`")
print(f"- **Deleted files**: {len(deleted_files)}")
for df in deleted_files:
print(f" - `{df}`")
print("\n## Recommended Review Sub-Skills")
recommended_any = False
for cat, info in categories.items():
if info["files"]:
recommended_any = True
print(f"\n### 🎯 `{cat}`")
print("**Reasons / Triggers detected**:")
for r in info["reasons"]:
print(f"- {r}")
print("**Files to inspect**:")
for f in info["files"][:5]: # Limit to top 5
print(f"- `{f}`")
if len(info["files"]) > 5:
print(f"- ... and {len(info['files']) - 5} more files.")
if not recommended_any:
print(
"\nNo specific triggers matched. Standard `audit-implementation` suggested for general sanity check."
)
if __name__ == "__main__":
main()
SKILL.md
---
name: code-reviewer-colony
description: >
Read when the user requests a code review, PR audit, or software quality check.
Do not read for code writing, bug fixing, or structural code modifications.
---
# Code Reviewer Colony
## Overview
- Perform specialized reviews of code changes and pull requests by routing tasks to focused sub-skills.
## Triggers
- User requests a code review, PR audit, or software quality check.
## Exclusions
- Code writing, bug fixing, or structural code modifications.
## Sub Skills
Read [INDEX.csv](sub-skills/INDEX.csv) to identify all matching sub-skills for the request.
- Multi-skill routing: If the request spans multiple categories, select and execute matching sub-skills sequentially.
- Workflow: Load instructions for all matched sub-skills → Plan a step-by-step sequence → Execute and report progress.
## Constraints
- Route tasks to the appropriate sub-skills by evaluating `keywords`, `trigger`, and `exclusion` in [INDEX.csv](sub-skills/INDEX.csv).
- If a request matches multiple sub-skills, load and execute all relevant sub-skills in sequence.
- Do not perform review audits directly in this master skill; delegate all auditing steps to the selected sub-skills.
sub-skills/assist-human/SKILL.md
---
name: assist-human
description: Acts as an interactive assistant to help human developers perform code reviews.
---
# Review Assistant Skill
Procedural guidelines for assisting human reviewers during code reviews.
## Goal
Provide interactive assistance to developers conducting code reviews, answering questions, explaining code logic, and drafting comments.
## Review Steps
1. **Answer Specific Review Queries**:
- Answer developer questions about a specific diff or codebase change (e.g. "What does this loop do?", "Could this cause a race condition?", "Are there side effects?").
- Perform spot-checks on specific files or functions requested by the human.
2. **Draft PR Comments**:
- Help the developer write clear, constructive inline review comments.
- Format comments concisely: describe the problem, explain why it is an issue, and provide the exact suggested fix.
3. **Delegate Deep Tasks**:
- For complex reviews, deep structural audits, or specialized checks, do not handle them inline.
- Delegate to other specialized sub-skills (e.g., `audit-architecture` for structure, `audit-performance` for efficiency, `audit-security` for security, or `audit-implementation` for logic) to handle the review depth.
- Refer to guidelines in [principles.md](../../references/principles.md) for basic constraints.
sub-skills/audit-architecture/SKILL.md
---
name: audit-architecture
description: Audits code directory structure, screaming architecture, module/dependency rules, and naming conventions.
---
# Architecture Auditor Skill
Procedural guidelines for auditing code architecture, boundaries, and structure.
## Goal
Ensure the code layout makes the application's domain and design rules obvious and follows target architectural patterns.
## Review Steps
1. **Check Directory Layout**:
- Verify if the layout is domain/feature-centric rather than tech-centric.
- Look for deep nesting of directories (> 4 levels) and suggest flattening.
- Refer to guidelines in [architectural-patterns.md](../../../code-builder-colony/references/architectural-patterns.md).
2. **Verify Naming Conventions**:
- Check if class and file names use appropriate architectural suffixes:
- `Handler` / `Controller` for entry points.
- `Service` / `UseCase` for business logic.
- `Repository` / `Dao` for data layers.
- `Dto` / `Response` / `Request` for data transfer.
- `Client` / `Gateway` for external integrations.
3. **Audit Dependency Flow**:
- Inspect imports to check the dependency direction (Infrastructure -> Application -> Domain).
- Ensure the `domain` (core business rules) contains no imports from outer layers (like database drivers, ORMs, Web/REST frameworks).
- Check for circular dependencies between components and suggest extracting shared logic if necessary.
4. **Verify Entry Points**:
- Ensure the entry points (`main.py`, `app.py`, `cli.py`, etc.) are in clear, predictable locations.
sub-skills/audit-implementation/SKILL.md
---
name: audit-implementation
description: Reviews core code logic, readability, style, correctness, error handling, and formatting.
---
# Implementation Reviewer Skill
Procedural guidelines for reviewing code implementation details, logic flow, and clean code qualities.
## Goal
Ensure the implemented code is correct, maintainable, readable, and conforms to target guidelines.
## Review Steps
1. **Check Correctness & Logic**:
- Verify if the code satisfies the functional requirements.
- Look for edge cases (e.g., empty arrays, null values, out-of-range inputs, division by zero) and verify they are handled properly.
- Check if public APIs are preserved unless specifically requested to change.
2. **Evaluate Readability & Style**:
- Verify if variables and functions are named clearly and express intent.
- Ensure the code follows consistent style patterns.
- Flag unnecessary code changes or formatting churn in unrelated files.
- Ensure functions and files are focused (SRP). Prefer short functions.
- Check guidelines in [principles.md](../../references/principles.md).
3. **Assess Error Handling**:
- Ensure errors are not silently swallowed.
- Check that error handling uses appropriate language conventions (e.g., try-catch blocks, Go style err returns, Result types).
- Verify that logs do not contain secrets or sensitive user information (PII).
sub-skills/audit-performance/SKILL.md
---
name: audit-performance
description: Reviews performance-sensitive code, execution complexity, resource management, database queries, and async patterns.
---
# Performance Reviewer Skill
Procedural guidelines for identifying performance bottlenecks, resource leaks, and inefficiencies in code.
## Goal
Ensure the code executes efficiently, manages memory and resources correctly, and scales appropriately.
## Review Steps
1. **Check Algorithmic Complexity**:
- Check for heavy nested loops or high time/space complexity (e.g., O(N^2) or worse on large datasets).
- Ensure collections are sized or filtered correctly rather than processing unnecessary items.
2. **Audit Database & I/O Operations**:
- Watch out for N+1 query problems (e.g., executing DB queries or external API calls inside a loop).
- Verify that database queries are indexed and efficient (avoiding SELECT *).
- Ensure caching is utilized where appropriate for heavy or frequently repeated operations.
3. **Check Resource Management**:
- Verify that file descriptors, DB connections, and network sockets are closed properly (use context managers like `with` in Python, try-with-resources in Java/Go defer, etc.).
- Check for potential memory leaks (e.g., global list additions without deletion, unremoved event listeners).
4. **Verify Concurrency & Async Usage**:
- Check if asynchronous operations are used for I/O bound tasks.
- Verify that concurrency controls (locks, mutexes, semaphores) are correctly managed to prevent deadlocks or race conditions.
- Refer to guidelines in [principles.md](../../references/principles.md).
sub-skills/audit-security/SKILL.md
---
name: audit-security
description: Reviews security vulnerabilities, input validation, authentication/authorization checks, and prevents hardcoded secrets.
---
# Security Reviewer Skill
Procedural guidelines for scanning and preventing security vulnerabilities in code changes.
## Goal
Ensure the code is secure against common vulnerabilities (OWASP Top 10) and does not leak sensitive data.
## Review Steps
1. **Check for Code Injections**:
- Verify that all database queries use parameterized queries / ORM prepared statements instead of raw string interpolation to prevent **SQL Injection**.
- Check if inputs rendered in UI or templates are properly escaped to prevent **XSS (Cross-Site Scripting)**.
- Inspect command executions (e.g., `os.system`, `subprocess`, `exec`, `eval`) to ensure they do not run raw untrusted input.
2. **Audit Secrets & Sensitive Data**:
- Scan the changes for hardcoded credentials, API keys, passwords, private tokens, or certificate files. Ensure they are placed in environment variables or configuration files.
- Verify that sensitive information (PII or secrets) is not printed to stdout or written to logs.
3. **Check Input Validation & Path Safety**:
- Ensure external input is validated against a whitelist/schema.
- Guard against **Path Traversal** (e.g., verify that file paths constructed from inputs are sanitized and restricted to a specific base directory).
- Check against SSRF (Server-Side Request Forgery) by validating URLs before calling them.
4. **Verify Authentication & Access Control**:
- Check that any new endpoints or APIs require appropriate authentication and authorization checks.
- Ensure access checks are performed on the server-side, not just in UI.
- Refer to guidelines in [principles.md](../../references/principles.md).
sub-skills/audit-spec/SKILL.md
---
name: audit-spec
description: Audits code changes against specifications, requirements documents, PRDs, and user stories.
---
# Specification Compliance Auditor Skill
Procedural guidelines for auditing whether code changes satisfy requested specifications, designs, or requirements.
## Goal
Ensure all features, rules, behaviors, and edge cases described in the product/technical specifications are fully and correctly implemented without missing requirements or unintended deviations.
## Review Steps
1. **Locate and Read Specifications**:
- Identify the source of requirements: design documents, PRDs, specs, issues, or ticket descriptions.
- Read and list all explicit and implicit requirements.
2. **Map Requirements to Code Changes**:
- Trace each requirement to specific files and line ranges in the pull request.
- For every rule or behavior in the spec, verify if the corresponding logic is present in the diff.
3. **Verify Compliance and Completeness**:
- Confirm that all functional requirements are implemented.
- Confirm that all non-functional requirements (e.g. constraints, performance, limits) are respected.
- Check if edge cases or error handling scenarios described in the spec are implemented.
4. **Detect Discrepancies and Gap Analysis**:
- Identify any requested requirements that were omitted or only partially implemented.
- Spot any implemented features or changes that deviate from the specification or add undocumented complexity (feature creep).
5. **Generate Specification Compliance Report**:
- Summarize findings in a checklist or tabular format containing:
- Requirement / Specification Feature
- Implementation Status (Fully Implemented / Partially Implemented / Missing)
- Code References (relative paths to relevant code files/lines)
- Notes / Discrepancies details
## Example Compliance Table
| Requirement / Spec Item | Status | Code Reference | Notes |
| :--- | :--- | :--- | :--- |
| Req 1: User authentication via JWT | Fully Implemented | [auth.py](../../../code-reviewer-colony/scripts/analyze_diff.py) (example) | Matches spec section 2.1 |
| Req 2: Rate limit of 60 req/min | Partially Implemented | [middleware.go](../../../code-reviewer-colony/sub-skills/INDEX.csv) | Logic is present but limit is hardcoded to 100 |
| Req 3: Soft delete for user accounts | Missing | N/A | No code implements this behavior in the diff |
sub-skills/audit-tests/SKILL.md
---
name: audit-tests
description: Reviews test coverage, test cases, mocking strategies, and unit/integration test code quality.
---
# Test Reviewer Skill
Procedural guidelines for reviewing test files, assertions, and test coverage.
## Goal
Ensure the codebase has robust, readable, and maintainable test coverage, focusing on correctness and regression prevention.
## Review Steps
1. **Verify Coverage & Tests Presence**:
- Check if new features or bug fixes are accompanied by appropriate unit or integration tests.
- If functional logic is modified but no tests are added or updated, verify if coverage is already sufficient or ask if tests are needed.
2. **Evaluate Test Case Quality**:
- Verify that test cases cover happy paths, error paths, and boundary conditions (empty values, extremes).
- Ensure assertions are meaningful (avoiding vague assertions like `assert True` or just checking that a function returns without error).
- Check that tests are structured cleanly (e.g., Arrange-Act-Assert / AAA pattern).
3. **Inspect Mocking Strategies**:
- Verify that external dependencies (database, third-party APIs, filesystem) are mocked out in unit tests to ensure fast and isolated test execution.
- Ensure mocks are not over-engineered or hard to maintain. Check that mock expectations match actual logic.
- Refer to guidelines in [principles.md](../../references/principles.md).
sub-skills/INDEX.csv
name,overview,keywords,trigger,exclusion
audit-architecture/SKILL.md,Audits folder structure naming and dependency rules,"architecture, structure, folder, directory, package, boundary, cyclic, naming, clean architecture","request to review structure, architecture design, directory layout, or screaming architecture",no structural changes
audit-implementation/SKILL.md,Reviews code quality logic and readability,"clean code, refactor, logic, readability, bug, style, correctness, code smell","request to review implementation, general logic, readability, or refactor code",no code changes
audit-performance/SKILL.md,Reviews code performance complexity and resource usage,"performance, complexity, leak, query, sql, slow, cache, scale, profiling, heap","request to review performance, optimize speed, heavy operations, slow queries, or memory usage",no performance impact expected
audit-security/SKILL.md,Reviews security vulnerabilities and safe inputs,"security, vulnerability, owasp, injection, secret, auth, path traversal, xss, csrf","request to review security, verify inputs, secure code, check for vulnerabilities, or secret checks",no security impact expected
audit-tests/SKILL.md,Reviews test coverage test cases and test code quality,"test, coverage, mock, unit test, integration test, spec, assert","request to review tests, check test cases, coverage verification, or writing tests",no test files changed
run-automated/SKILL.md,Performs agent-led automated reviews and reports,"automated, run review, review report, agent review, complete review, review draft, checklist","request for an automated review, code review report, or overall review scan",no general review requested
assist-human/SKILL.md,Helps human developers perform interactive code reviews,"assistant, helper, query, question, explain, check file, draft comment, design choice","request to assist human, answer queries about changes, explain diff, or draft inline comments",no interactive assistance needed
audit-spec/SKILL.md,Audits code changes against specifications and requirements,"spec, specification, requirement, feature list, documentation comparison, conformity, design document","request to review spec compliance, verify implementation against spec, check documentation conformity, or check off features",no spec or requirement document provided
summarize-changes/SKILL.md,Summarizes code changes in a tabular format with easy navigation links,"summary, overview, changes, diff, table, navigation, links, markdown table","request to summarize changes, provide diff summary, create review table, or navigate changes",no change summary requested
sub-skills/run-automated/SKILL.md
---
name: run-automated
description: Performs agent-led automated code reviews and generates structured code review reports.
---
# Automated Reviewer Skill
Procedural guidelines for performing autonomous code reviews and compiling findings into a structured report.
## Goal
Autonomously analyze a set of code changes, apply relevant review sub-skills, and output a comprehensive Code Review Report.
## Review Steps
1. **Perform Initial Diff Scan**:
- Run the diff analyzer helper script: `python scripts/analyze_diff.py` (relative to the reviewer root).
- Capture the output to identify which specialized review categories apply.
2. **Run Specialized Audits**:
- For each recommended review category, execute its specific sub-skill:
- **Architecture**: Audit code layouts, naming patterns, and dependency flows.
- **Implementation**: Inspect core logic correctness, clean code standards, and error boundaries.
- **Performance**: Scan for database bottlenecks (N+1 queries), loop complexity, and leakages.
- **Security**: Scan for secrets leakage, input injection risks, and authorization missing checks.
- **Tests**: Evaluate test presence, assertions, and mock isolation.
3. **Compile and Format Report**:
- Consolidate all findings into a Markdown report.
- Organize the feedback by severity:
- **Blockers**: Critical bugs, security vulnerabilities, or resource leaks.
- **Major**: Architecture violations or missing tests.
- **Suggestions**: Enhancements, style tips, or performance optimizations.
- Provide concrete, copy-pasteable code suggestions to fix identified problems.
- Refer to guidelines in [principles.md](../../references/principles.md).
sub-skills/summarize-changes/SKILL.md
---
name: summarize-changes
description: Summarizes code changes in a clean tabular format with easy navigation links to changed files.
---
# Code Changes Summarizer Skill
Procedural guidelines for generating a clean, high-level summary of code changes in a structured table format with direct navigation links.
## Goal
Provide developers with an immediate, clear overview of what files were changed, why, and how, with clickable relative links to allow quick traversal to the relevant code.
## Review Steps
1. **Analyze File Diffs**:
- Scan the git diff or changes list to identify all added, modified, deleted, or renamed files.
- For each file, inspect the specific changes to understand the scope and intent.
2. **Summarize Key Changes**:
- For each changed file, write a concise description of the modification (e.g., "Added input validation for the registration form", "Refactored database query to use parameterized queries").
- Classify the type of change (e.g., Feature, Bug Fix, Refactor, Test, Config, Chore).
3. **Construct the Change Summary Table**:
- Organize the information into a markdown table with the following columns:
- **File Path / Link**: Clickable link to the file. Always use relative paths starting from the workspace root or relative to the review document.
- **Status**: Visual indicator of the change state (e.g., `🟢 Added`, `🟡 Modified`, `🔴 Deleted`, `🔵 Renamed`).
- **Change Type**: Category of the change.
- **Summary of Changes**: Bullet points of key modifications in that file.
- **Impact**: Code components or areas affected.
4. **Add High-Level Statistics**:
- Include a brief summary count of total files changed, lines added, and lines deleted to give quick context.
## Example Summary Table
### Summary Statistics
- **Total Files Changed**: 3
- **Change Type Breakdown**: 1 Feature, 1 Refactor, 1 Test
### Changes Table
| File Path / Link | Status | Change Type | Summary of Changes | Impact |
| :--- | :--- | :--- | :--- | :--- |
| [auth.go](../../../code-reviewer-colony/scripts/analyze_diff.py) (example) | 🟢 Added | Feature | - Implemented JWT-based session verification.<br>- Added password hashing helper. | Authentication flow |
| [user_service.go](../../../code-reviewer-colony/sub-skills/INDEX.csv) | 🟡 Modified | Refactor | - Extracted profile update logic into helper function.<br>- Cleaned up redundant DB queries. | User profiles |
| [user_service_test.go](../../../code-reviewer-colony/references/principles.md) | 🟢 Added | Test | - Added unit tests for profile updates.<br>- Added mock database assertions. | Test coverage |