Run any Skill in Manus with one click

code-review

Stars21

Forks1

UpdatedJune 21, 2026 at 13:51

This skill should be used when a user asks for a code review, feedback on a PR or MR, diff assessment, or says things like 'can you review my changes', 'look at this diff', 'is this ready to merge', 'check my code', 'review this branch', 'what do you think of these changes', or 'LGTM check'. Covers correctness, performance, security, structural concerns, repo-specific review rules, and questions of intent on pull/merge requests or raw diffs from any platform (GitHub, GitLab).

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

srtab

srtab/daiv

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

File Explorer

15 files

SKILL.md

readonly

name	code-review
description	This skill should be used when a user asks for a code review, feedback on a PR or MR, diff assessment, or says things like 'can you review my changes', 'look at this diff', 'is this ready to merge', 'check my code', 'review this branch', 'what do you think of these changes', or 'LGTM check'. Covers correctness, performance, security, structural concerns, repo-specific review rules, and questions of intent on pull/merge requests or raw diffs from any platform (GitHub, GitLab).
metadata	{"version":"3.5.0"}

Code Review

This skill runs in two phases. The review workflow finds and verifies high-signal issues; delivery optionally publishes them to GitLab. Each phase has its own reference — read it as you enter the phase, so its detail is fresh when you act on it. This file is the router: it picks the mode, lists the stages, and states the rules that hold in every mode. The detailed procedure lives in the references, not here.

Pick a mode

Delivery mode — the runtime has merge-request context (Scope.MERGE_REQUEST with a merge_request_id) and the platform is GitLab. The review is delivered as inline discussions on specific lines plus one top-level summary discussion, posted via the gitlab tool. Delivery requires the gitlab tool: if it's not loaded, tool_search for it; if it can't be loaded (or returns 403 on the discussion endpoint), demote to interactive mode. The pick is provisional: gitlab-delivery.md Step 1 re-confirms that merge_request_id, the project, and the SHA triplet are all present and demotes to interactive if any is missing.
Interactive mode — anything else: a local diff, a referenced MR/PR with no runtime context, a GitHub PR, or ambiguous scope. The review is returned as a markdown final message; the harness handles delivery.

Run the review

Read references/review-workflow.md and follow it. It walks scope → Stage 0 (per-repo review rules) → Stage 1 (detector fan-out) → Stage 2 (merge + adversarial verification) → severity, and hands off the verified findings.
Interactive mode: render the survivors using the interactive output protocol at the end of review-workflow.md, and return it as the final message. Done.
Delivery mode: once the workflow hands off verified findings, read references/gitlab-delivery.md and follow it to post them. Read it before posting anything — the marker, anchor, and dedup machinery is not reconstructable from memory.

Non-negotiables (every mode)

Precision over recall. Adversarially refute every finding; over-pruning is acceptable. Present only confirmed survivors — no strikethrough, no "on closer reading this is fine."
Never post style, formatting, whitespace, or import-ordering findings. That's a linter's or formatter's job.
Detectors run as cr-* subagents, never general-purpose. A general-purpose dispatch returns prose with no findings array and breaks the merge. If a cr-* type didn't load, skip it and report the gap in the status line — never substitute.
Never compute markers or anchors by hand. scripts/marker.py is the only source of markers, anchors, and note parsing; hand-rolling them silently breaks dedup across reruns.
In delivery mode the posted comments are the deliverable. Do not also return the review markdown after a successful post.
Never re-invoke the skill tool to restart the review. On a tool failure, switch to an alternative and continue — each phase reference lists its fallbacks.

References

references/review-workflow.md — the review itself (scope, detect, verify, severity, interactive output). Required reading every run.
references/gitlab-delivery.md — posting to GitLab (markers, dedup, inline + summary, pending replies, status line). Required in delivery mode.
references/principles.md, references/few-shot-examples.md — the why behind a finding and how short a useful comment can be; open a section when a finding's framing is unclear.
references/marker-format.md, examples/example-review-output.md — marker field semantics and a complete delivery example; open during delivery if a field's purpose is unclear or you need the output shape.

More from this repository

same repository

plan

srtab/daiv

This skill should be used when the user asks to explore a codebase and design implementation plans without making any changes. Trigger when users say 'plan how to implement X', 'design an approach for Y', 'explore the codebase before changing Z', 'create an implementation strategy', 'analyze how to refactor X', 'map out dependencies for Y', 'I want a plan before we start coding', 'plan to fix issue

2026-03-1321

security-audit

srtab/daiv

This skill should be used when the user asks to review code for security vulnerabilities, audit a pull request or merge request for risks, check if code is safe, find injection flaws or hardcoded secrets, or assess the security posture of a feature or codebase area. Use this skill even when the user doesn't say "security audit" explicitly — trigger on phrases like "is this code safe?", "audit this PR", "check for vulnerabilities", "any security issues here?", "review my changes for risks", "are there hardcoded secrets?", "check for SQL injection", "security review", or "assess the risk in this diff". When in doubt, use this skill — it's better to over-trigger on security reviews than to miss one.

2026-03-1221

init

srtab/daiv

This skill should be used when a user asks to initialize a repository for AI agents, create or update an AGENTS.md file, scaffold agent instructions for a codebase, or improve existing agent guidance. Triggers include phrases like 'create an AGENTS.md', 'set up agent instructions', 'initialize this repo for coding agents', 'update my AGENTS file', or 'analyze this repo and generate agent docs'.

2026-02-2421

skill-creator

srtab/daiv

Guide for creating effective skills that extend DAIV agent with specialized knowledge, workflows, or tool integrations. Use this skill when the user wants to create a new skill, update an existing skill, or get guidance on skill design patterns.

2026-02-1921

name	code-review
description	This skill should be used when a user asks for a code review, feedback on a PR or MR, diff assessment, or says things like 'can you review my changes', 'look at this diff', 'is this ready to merge', 'check my code', 'review this branch', 'what do you think of these changes', or 'LGTM check'. Covers correctness, performance, security, structural concerns, repo-specific review rules, and questions of intent on pull/merge requests or raw diffs from any platform (GitHub, GitLab).
metadata	{"version":"3.5.0"}

Code Review

Pick a mode

Delivery mode — the runtime has merge-request context (Scope.MERGE_REQUEST with a merge_request_id) and the platform is GitLab. The review is delivered as inline discussions on specific lines plus one top-level summary discussion, posted via the gitlab tool. Delivery requires the gitlab tool: if it's not loaded, tool_search for it; if it can't be loaded (or returns 403 on the discussion endpoint), demote to interactive mode. The pick is provisional: gitlab-delivery.md Step 1 re-confirms that merge_request_id, the project, and the SHA triplet are all present and demotes to interactive if any is missing.
Interactive mode — anything else: a local diff, a referenced MR/PR with no runtime context, a GitHub PR, or ambiguous scope. The review is returned as a markdown final message; the harness handles delivery.

Run the review

Read references/review-workflow.md and follow it. It walks scope → Stage 0 (per-repo review rules) → Stage 1 (detector fan-out) → Stage 2 (merge + adversarial verification) → severity, and hands off the verified findings.
Interactive mode: render the survivors using the interactive output protocol at the end of review-workflow.md, and return it as the final message. Done.
Delivery mode: once the workflow hands off verified findings, read references/gitlab-delivery.md and follow it to post them. Read it before posting anything — the marker, anchor, and dedup machinery is not reconstructable from memory.

Non-negotiables (every mode)

Precision over recall. Adversarially refute every finding; over-pruning is acceptable. Present only confirmed survivors — no strikethrough, no "on closer reading this is fine."
Never post style, formatting, whitespace, or import-ordering findings. That's a linter's or formatter's job.
Detectors run as cr-* subagents, never general-purpose. A general-purpose dispatch returns prose with no findings array and breaks the merge. If a cr-* type didn't load, skip it and report the gap in the status line — never substitute.
Never compute markers or anchors by hand. scripts/marker.py is the only source of markers, anchors, and note parsing; hand-rolling them silently breaks dedup across reruns.
In delivery mode the posted comments are the deliverable. Do not also return the review markdown after a successful post.
Never re-invoke the skill tool to restart the review. On a tool failure, switch to an alternative and continue — each phase reference lists its fallbacks.

References

references/review-workflow.md — the review itself (scope, detect, verify, severity, interactive output). Required reading every run.
references/gitlab-delivery.md — posting to GitLab (markers, dedup, inline + summary, pending replies, status line). Required in delivery mode.
references/principles.md, references/few-shot-examples.md — the why behind a finding and how short a useful comment can be; open a section when a finding's framing is unclear.
references/marker-format.md, examples/example-review-output.md — marker field semantics and a complete delivery example; open during delivery if a field's purpose is unclear or you need the output shape.