Run any Skill in Manus with one click

Get Started

darwin-code-review

Stars7

Forks1

UpdatedJune 11, 2026 at 13:58

Code and MR/PR review workflow for plan mode. Use when reviewing merge requests, pull requests, or code changes.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

The-Darwin-Project

The-Darwin-Project/Blackboard

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name	darwin-code-review
description	Code and MR/PR review workflow for plan mode. Use when reviewing merge requests, pull requests, or code changes.
roles	["architect"]
modes	["plan","review"]

Darwin Code Review Workflow

When to Use

You are in review mode. FRIDAY wants a code review, NOT an implementation plan. Do NOT produce a plan or write code.

Review Process

Fetch the diff: Obtain the MR/PR diff for the changes under review
Read the context: Check related files to understand the impact
Assess each change against the criteria below

Review Criteria

For each finding, assign a severity:

HIGH: Security issues, data loss risk, breaking changes, missing error handling
MEDIUM: Logic errors, missing edge cases, performance concerns, API contract violations
LOW: Style issues, naming, documentation gaps, minor improvements

Output Format

Structure your review with YAML frontmatter wrapping the body:

---
reasoning: "APPROVE | REQUEST CHANGES | NEEDS DISCUSSION: brief justification"
---

## Review Summary
<1-2 sentence overview>

## Findings
| Severity | File | Issue |
| -------- | ---- | ----- |
| HIGH     | path/to/file.py:42 | Description of the issue |
| MEDIUM   | path/to/file.py:88 | Description of the issue |

The reasoning field is required by team_send_results. It must come FIRST, before the review body.

Rules

Do NOT produce an implementation plan. This is a review, not a planning task.
Do NOT modify any files. Read-only analysis.
Be specific: cite file paths and line numbers for every finding.
If the changes look good, say so. Do not invent issues.
Use team_send_results to deliver your review to FRIDAY.

More from this repository

same repository

darwin-dockerfile-safety

The-Darwin-Project/Blackboard

Safety rules for modifying Dockerfiles and Containerfiles. Use when editing container build files.

2026-07-217

darwin-reporting-context

The-Darwin-Project/Blackboard

MR/PR context gathering and diagnostic reporting guidelines. Activates when working on events that reference MRs/PRs or when reporting investigation findings.

2026-07-217

darwin-team-huddle

The-Darwin-Project/Blackboard

Team coordination for implement and test modes. Developer and QE use team_send_results for final reports, team_huddle for mid-task questions to FRIDAY.

2026-07-217

darwin-gitops

The-Darwin-Project/Blackboard

GitOps workflow rules for modifying infrastructure via git. Use when cloning repos, modifying Helm values, committing, pushing, or verifying deployments.

2026-07-137

darwin-mr-lifecycle

The-Darwin-Project/Blackboard

MR/PR lifecycle operations -- pipeline check, retest, merge, conflict reporting. Extends darwin-gitlab-ops.

2026-07-137

darwin-comms

The-Darwin-Project/Blackboard

Report findings and status updates to the Darwin FRIDAY. Use team_send_results for final reports (task modes). In message mode, use team_send_message instead.

2026-07-097

name	darwin-code-review
description	Code and MR/PR review workflow for plan mode. Use when reviewing merge requests, pull requests, or code changes.
roles	["architect"]
modes	["plan","review"]

Darwin Code Review Workflow

When to Use

You are in review mode. FRIDAY wants a code review, NOT an implementation plan. Do NOT produce a plan or write code.

Review Process

Fetch the diff: Obtain the MR/PR diff for the changes under review
Read the context: Check related files to understand the impact
Assess each change against the criteria below

Review Criteria

For each finding, assign a severity:

HIGH: Security issues, data loss risk, breaking changes, missing error handling
MEDIUM: Logic errors, missing edge cases, performance concerns, API contract violations
LOW: Style issues, naming, documentation gaps, minor improvements

Output Format

Structure your review with YAML frontmatter wrapping the body:

---
reasoning: "APPROVE | REQUEST CHANGES | NEEDS DISCUSSION: brief justification"
---

## Review Summary
<1-2 sentence overview>

## Findings
| Severity | File | Issue |
| -------- | ---- | ----- |
| HIGH     | path/to/file.py:42 | Description of the issue |
| MEDIUM   | path/to/file.py:88 | Description of the issue |

The reasoning field is required by team_send_results. It must come FIRST, before the review body.

Rules

Do NOT produce an implementation plan. This is a review, not a planning task.
Do NOT modify any files. Read-only analysis.
Be specific: cite file paths and line numbers for every finding.
If the changes look good, say so. Do not invent issues.
Use team_send_results to deliver your review to FRIDAY.