| name | conduct-code-review-round |
| description | Orchestrates a thorough code review process by chaining four engineering skills into a structured review pipeline. Covers code quality assessment, security review, performance analysis, and documentation of review findings with actionable feedback. Use when conducting a formal code review of a pull request or a batch review of recent changes. Do NOT use for automated-only code scanning, pair programming sessions, or architecture reviews that do not examine specific code changes. |
| license | Apache-2.0 |
| type | workflow |
| skills | code-review-patterns devsecops-engineer performance-profiling technical-documentation |
| trigger_phrases | conduct code review review pull request thorough code review structured review process |
| metadata | {"author":"foundry-skills","version":"1.0.0","tags":"testing security optimization step-by-step","category":"software-project","depends":"code-review-patterns devsecops-engineer performance-profiling technical-documentation","disclaimer":"none","difficulty":"intermediate"} |
Conduct Code Review Round
Estimated time: 1-4 hours per review round (depending on change size and complexity)
This workflow chains four atomic skills into a structured code review process that covers code quality, security, performance, and documentation completeness. It ensures reviews are thorough, actionable, and consistent rather than superficial approvals or nitpick-heavy criticism. The workflow produces specific, prioritized feedback that the author can act on immediately.
Critical note: Code review is a collaboration, not a gatekeeping exercise. The goal is to improve the code and share knowledge, not to prove the reviewer's superiority. Feedback should be specific, actionable, and tied to observable impact (correctness, security, performance, or maintainability).
When to Use
- User is reviewing a pull request and wants a structured approach beyond ad-hoc reading
- Team wants to establish a consistent, thorough review process
- User is reviewing a large or complex pull request (over 300 lines changed)
- User wants to catch security and performance issues in addition to code quality
- Do NOT use when: the review is a rubber-stamp approval for a trivial change, the user is pair programming (review happens in real time), or the user needs an architectural review that examines design decisions rather than code changes
Prerequisites
Before starting this workflow, ensure:
- Pull request is ready for review: The author has marked the PR as ready, all CI checks pass, and the PR description explains the context and changes
- Review context is available: You can access the code diff, linked ticket or issue, related documentation, and any design decisions that informed the implementation
- Review guidelines exist: The team has documented review expectations (response time, required checks, feedback format) or you will follow this workflow's structure
- Testing is complete: The author's tests pass and the reviewer can run the code locally if needed for complex changes
Steps
Step 1: Review Code Quality and Correctness (uses: code-review-patterns)
Examine the code changes for correctness, readability, maintainability, and adherence to team conventions. This step covers the core review: does the code do what it should, and will the team be able to understand and maintain it.
- Input: Pull request diff, linked ticket or issue with acceptance criteria, team coding conventions, existing codebase patterns
- Output: Code quality feedback with: correctness issues (logic errors, edge cases, race conditions), readability concerns (naming, complexity, unclear intent), convention violations (formatting, patterns, architecture), and positive callouts (well-designed solutions worth highlighting)
