When to use this skill

When you need to review changes in a pull request or a set of commits before merging. This skill focuses on the delta (changed files) rather than a full component audit.

How to use this skill

1. •Identify the PR or commit range to review.
2. •Gather the list of changed files.
3. •Follow the detailed instructions to review each category.
4. •Generate findings and add them to the sprint backlog.

Detailed instructions

Step 1: Scope the review

Determine what is being reviewed:

• •For a PR: use git diff main...HEAD or gh pr diff to see changes.
• •For commits: use git diff COMMIT1..COMMIT2.

List all changed files and categorise them by component and facet.

Step 2: Review checklist

For each changed file, apply the following checks. Not all checks apply to all files - use judgement based on what was changed.

Headers & Licensing

Reference: See any existing file in the codebase for the expected format.

Code Style & Naming

Reference: Component Creator skill for component conventions.

Comment Quality

Platform Isolation

Code Locality

C++23 Idioms

Domain Types

If adding or modifying domain types, verify completeness per Domain Type Creator:

Protocol & Messaging

If adding or modifying protocol messages, verify per Binary Protocol Developer:

Temporality Patterns

If adding or modifying persisted domain types, verify temporal audit patterns:

Unit Tests

Verify test coverage per Unit Test Writer:

Error Handling

Security

Skill Consistency

If changing code patterns that are documented in skills, verify skills remain accurate:

Relevant skills to check based on changes:

• •Domain types: Domain Type Creator
• •Messaging: Binary Protocol Developer
• •Components: Component Creator
• •Tests: Unit Test Writer
• •Diagrams: PlantUML Modeler

Step 3: Generate findings

For each issue found, categorise by severity:

Critical (Must Fix)

Issues that must be resolved before merge:

• •Bugs that cause incorrect behaviour.
• •Security vulnerabilities.
• •Data loss risks.
• •Broken functionality.

Important (Should Fix)

Issues that should be addressed but don't block merge:

• •Architecture problems.
• •Missing features from requirements.
• •Poor error handling.
• •Test coverage gaps.
• •Convention violations.

Minor (Nice to Have)

Suggestions for improvement:

• •Code style preferences.
• •Optimisation opportunities.
• •Documentation improvements.
• •Refactoring suggestions.

Step 4: Document findings

For each issue, provide:

• •<line> - Exact location of the issue.
• •What's wrong - Clear description of the problem.
• •Why it matters - Impact of not fixing.
• •How to fix - Suggested resolution (if not obvious).

Step 5: Add to sprint backlog

Create stories in the sprint backlog per Agile Product Owner skill:

• •Group related issues into stories by component or theme.
• •Use :code: tag for implementation fixes.
• •Use :doc: tag for documentation issues.
• •Include <line> references in task descriptions.

Example story format:

**** STARTED [component] Address PR review findings :code:

Review findings from PR #XXX.

***** Tasks
- [ ] Fix: missing copyright header in src/domain/foo.cpp
- [ ] Fix: snake_case violation in bar_service.hpp:42
- [ ] Add: unit tests for baz_repository

***** Notes

PR: https://github.com/OreStudio/OreStudio/pull/XXX

Step 6: Provide verdict

Conclude the review with:

• •Ready to merge - No critical issues, important issues acceptable.
• •Ready with fixes - Critical issues identified that must be fixed first.
• •Not ready - Significant rework required.

Include a 1-2 sentence reasoning for the verdict.