Code Review and Quality Improvement

Code review isn’t just a formality — you need to find issues, give actionable review comments, and track them to completion. This case shows how to use LanMate to turn code review from “took a look, looks fine” into a structured closed loop, so issues aren’t missed and fixes are traceable.

Skills Used

• Built-in skills (installed with LanMate, ready out of the box): LanMate itself can read and write code files — no additional built-in skills required
• Skill Store: Code Review Requester — write structured review requests with change summaries and self-test checklists; Code Review Receiver — process review comments as the receiver, building a closed loop from classification to verification; Code Quality Reviewer — scan for complexity, duplicate code, naming conventions, and other quality issues; Code Security Scanner — scan for hardcoded secrets, SQL injection, XSS, and other security risks

Pain Points

• Review requests lack context: just a change link, and the reviewer doesn’t know what changed, why, or how it was tested
• Review comments are based on gut feeling: “this doesn’t look right,” “suggest optimizing” — no severity level or specific suggestion
• Quality issues recur: overly long functions, magic numbers, duplicate code — raised every review but never fixed
• Security risks are overlooked: hardcoded secrets, SQL injection, XSS — manual review can’t catch them all
• Fixes have no closure: comments are posted and forgotten — whether they were fixed and fixed correctly is untracked

Recommended Workflow

Prompt Examples

Self-Check Before Submitting for Review

I'm about to submit a code change. Please help me generate a structured review request:
- Change summary: what changed and why (1-2 sentences)
- Change scope: list of files involved and the type of change for each (added / modified / deleted)
- Self-test checklist: which scenarios I should test
- Risk notes: which changes might affect existing functionality
- Rollback plan: how to roll back if something goes wrong

Read the code files in the src/ directory and generate based on recent changes.
The self-test checklist should be specific to test scenarios — don't write generic statements like "comprehensive testing."

Receiving Another Developer’s Code Changes for Review

Please review the code changes in the src/ directory and generate per-file review comments:
1. First analyze the change scope: which files changed and what changed in each
2. Review file by file; each comment should include:
   - File name and line number
   - Issue description
   - Severity (blocker / major / suggestion)
   - Fix suggestion (specific to how to change it)
3. Summarize highlights in the changes (patterns worth learning from)

Focus on:
- Logic errors and edge cases (null values, out-of-bounds, unhandled exceptions)
- Whether unnecessary complexity was introduced
- Whether hardcoded values should be extracted into configuration

Code Quality Assessment

Please scan the code in the src/ directory and generate a quality review report:
1. Function complexity: flag functions with excessive cyclomatic complexity (suggest threshold: 15 and above)
2. Duplicate code: flag code blocks that appear repeatedly
3. Naming conventions: check whether function names and variable names are meaningful and follow conventions
4. Code smells: overly long functions, excessive nesting, overly large classes

For each issue, output:
- File name and location
- Issue type
- Severity (high / medium / low)
- Refactoring suggestion

Do not report purely formatting issues (e.g., indentation, spacing) — focus on substantive issues that affect maintainability.

Security Scan

Please scan the code in the src/ directory for security risks:
1. Hardcoded secrets: check for API keys, passwords, or tokens written directly in the code
2. SQL injection: check for string-concatenated SQL statements
3. XSS: check for unescaped user input rendered directly to the page
4. Sensitive data leakage: check whether sensitive data is logged

For each risk, output:
- File name and line number
- Risk type
- Severity (critical / high / medium / low)
- Fix suggestion

For locations where it's uncertain whether there's a risk, mark "requires manual review" — do not assess on your own.

Generate Review Report

Please aggregate the above review results into a code review report:
- Issue list (file, line number, issue description, severity)
- Grouped statistics by severity (blocker / major / suggestion)
- Fix suggestion for each issue
- Owner and suggested fix deadline
- Review conclusion (approved / approved with changes / rejected)

Blocker-level issues must be pinned at the top of the report, with an explanation of the consequences if left unfixed.
Output an HTML report.

Acceptance Criteria

• The review request includes a change summary, change scope, and self-test checklist with specific, executable test scenarios
• Each review comment includes file name, line number, severity, and a specific fix suggestion
• The quality report focuses on maintainability issues and does not report purely formatting issues
• Security risks are graded by severity; indeterminate items are marked “requires manual review”
• The review report includes an issue list, fix suggestions, owners, and a review conclusion; blocker-level issues are pinned at the top

Common Mistakes