Skip to content

docs: add written procedures to Ollama and PR review guides #315

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
rachaelrenk wants to merge 11 commits into
base: main
Choose a base branch
from
+280 −102
Open

docs: add written procedures to Ollama and PR review guides #315

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
2f3501e
docs: add written procedures to Ollama and PR review guides
rachaelrenk Jul 9, 2026
68b4387
fix: correct factual errors in Ollama guide after review
rachaelrenk Jul 9, 2026
a751589
Update src/content/docs/guides/external-tools/how-to-set-up-ollama.mdx
rachaelrenk Jul 9, 2026
01f33ca
Update src/content/docs/guides/agent-workflows/how-to-review-prs-like…
rachaelrenk Jul 9, 2026
e0e49c5
Merge branch 'main' into rrenk/guides-written-procedures
rachaelrenk Jul 10, 2026
a439052
Apply suggestion from @rachaelrenk
rachaelrenk Jul 10, 2026
2717d4a
fix: address PR review comments
rachaelrenk Jul 10, 2026
391a6a8
fix: correct 6 factual errors found in full truthiness review
rachaelrenk Jul 10, 2026
1013809
Merge branch 'main' into rrenk/guides-written-procedures
rachaelrenk Jul 10, 2026
2063047
refactor: restructure PR review guide per hongyi-chen feedback
rachaelrenk Jul 12, 2026
845261a
Merge branch 'main' into rrenk/guides-written-procedures
rachaelrenk Jul 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
161 changes: 102 additions & 59 deletions src/content/docs/guides/agent-workflows/how-to-review-prs-like-a-senior-dev.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
---
title: "Review PRs like a senior dev"
description: >-
Prompt Warp's coding agent to generate structured PR reviews with risk
assessment, critical issues, and merge confidence scoring.
Use Warp's agent to understand large pull requests, identify risky changes,
and investigate potential issues before leaving review comments.
sidebar:
label: "Review PRs like a senior dev"
tags:
Expand All @@ -11,92 +11,135 @@ tags:

---
import VideoEmbed from '@components/VideoEmbed.astro';
import { Steps } from '@astrojs/starlight/components';

Learn how to prompt Warp’s AI to review pull requests like an experienced engineer — focusing on structure, red flags, and clarity.
Warp's agent can help you understand a large pull request, identify risky changes, and investigate potential issues before you leave review comments. This guide walks through how to give the agent enough context, ask for focused feedback, and verify its findings.

<VideoEmbed url="https://youtu.be/NVwqQyphlAw?si=zcMR1ZHt-xnIS_ME" title="Reviewing pull requests with Warp Agent video" />

---
## Prerequisites

@hongyi-chen hongyi-chen Jul 10, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should rethink the framing here. Right now this reads like “paste this giant template and get a senior-engineer-quality review,” which feels a bit heavy handed.

A stronger guide would focus on the actual workflow:

  1. Give the agent the PR goal and relevant context
  2. Ask it to inspect the diff and surrounding code
  3. Prioritize correctness, regressions, security, and missing tests
  4. Verify any findings before leaving review comments
  5. Use follow-ups to investigate specific concerns

The structured output can still be useful, but it should support the review process rather than be the main point of the guide.

@hongyi-chen hongyi-chen Jul 10, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a few specific changes:

  • drop most of the emojis
  • ask the agent to inspect surrounding code
  • add an explicit verification step (link to computer use)
  • use the GH pR directly wherever possible: gh pr diff only gives the patch. gh pr view, the checked-out-branch, tests, etc, would provide more context

generally, i think we can simplify this instead of recommending such a specific step by step guide to code review


- A **Git-tracked project** with a branch or open PR to review
- The [GitHub CLI](https://cli.github.com) (`gh`) if you want to pull diffs or view PR metadata

## 1. Give the agent context

The quality of the review depends on the quality of context you provide. Before prompting, gather the pieces the agent needs:

**Pull the PR goal.** The diff alone doesn't tell the agent why changes were made. Start with the PR description:

```bash
gh pr view PR_NUMBER
```

**Get the diff.** The most focused way is:

```bash
# Patch-level diff via GitHub CLI
gh pr diff PR_NUMBER

# Or, if the branch is checked out locally
git diff main...<your-branch>
```

**Point the agent at key files.** If you know which areas the PR touches, use `@path/to/file` in your prompt to give the agent direct access to those files. This lets it read the surrounding code — not just the changed lines — which is important for catching regressions and missing test coverage.

<Steps>
**Run the test suite first.** If you have the branch checked out locally, run your tests before asking for a review. A failing test is faster to identify than a regression buried in prose.

1. #### Intro
Open a new agent session in Warp, navigate to the project directory, then attach context by selecting terminal output blocks or using `@file` references in your prompt.

This tutorial teaches you how to use Warp to make **pull-request reviews faster and smarter**.\
Instead of relying on AI summaries, you’ll prompt Warp to generate an **index and priority list**, guiding your review order while flagging risky sections.
## 2. Ask for focused feedback

Although this example focuses on large PRs, the same workflow applies to **code reviews**, **design docs**, or **feature diffs**.
With context attached, give the agent a clear, goal-oriented prompt. Keep it direct — focused prompts produce more actionable output than heavy templates:

2. #### The problem
```
I'm reviewing PR #PR_NUMBER. The goal is: [paste or summarize the PR description].

Large PRs are difficult to parse.\
AI summaries gloss over nuance and may miss subtle issues — you need structured, prioritized insight instead.
I've attached the diff. Please:
1. Check correctness — look for logic errors, off-by-one issues, or incorrect assumptions.
2. Check for regressions — does anything touch code paths that existing tests don't cover?
3. Flag security concerns — missing input validation, improper auth checks, hardcoded secrets.
4. Note missing or inadequate tests.
5. For each changed file, look at the surrounding code too, not just the changed lines. Call out anything that looks off in context.
```

3. #### The prompt
Adjust the emphasis based on what the PR does — a database migration warrants different scrutiny than a UI refactor.

Use this in Warp’s AI input:
## 3. Verify the agent's findings

```
## Prompt: Structured PR Review Format
Don't treat the agent's output as final. Before leaving review comments:

> Review this pull request and format your response for rapid scanning by a busy maintainer. Follow the structure below.
- **Run the tests.** If the agent flags a potential regression, check whether the test suite catches it.
- **Read the flagged code yourself.** The agent can miss context or misread intent. Treat its output as a starting checklist, not a verdict.
- **Test behavior changes manually.** For UI or interaction changes, check out the branch and verify in a browser. For cloud agent runs, you can use [Computer use](/agent-platform/capabilities/computer-use/) to let the agent verify behavior in a sandboxed environment.

---
## 4. Use follow-up prompts to dig deeper

### 1. 🚨 Risk Assessment
The first response is a starting point. Use follow-up prompts to investigate specific findings:

**Overall Risk:** 🔴 HIGH | 🟠 MEDIUM | 🟢 LOW
**Complexity:** [Simple | Moderate | Complex | Very Complex]
**Blast Radius:** [Isolated | Module-wide | System-wide | External APIs affected]
**Requires Immediate Review:** [YES / NO – why]
- **Inspect a specific area**: "Look more closely at `auth/middleware.js` — are there edge cases in the token expiration logic?"
- **Understand a concern**: "Explain the performance risk you flagged. How significant is it at 10k requests per minute?"
- **Draft a fix**: "Write the fix for the input sanitization issue in the login form."
- **Check scope**: "Does this PR include changes unrelated to the stated goal? List anything that seems out of scope."
- **Split a large PR**: "Suggest how to split this PR into smaller, independently reviewable pieces."

---
For large PRs, break the diff into logical groups of files and run the prompt once per group.

### 2. 🔍 Critical Issues
_If none, write “None found” and skip to the next section._
## Reference: structured output format (optional)

#### 1. [CRITICAL ISSUE TITLE]
**File:** `path/to/file.js:L125`
**Impact:** Data loss / Security hole / System crash
**Fix:**
// Quick code fix example here
If you want the agent's findings pre-formatted for rapid scanning — useful for async reviews or sharing with a team — add this format to your prompt. Use it as a structured report, but verify the findings before acting on them.

---
```
Review this pull request and format your response for rapid scanning. Follow the structure below.

### 3. ⚠️ Concerns
_Should discuss or fix before merge. If none, write “None found.”_
### 1. Risk Assessment

**Examples:**
- [PERFORMANCE] Unindexed query on large table
- [SECURITY] Missing input sanitization in login form
**Overall Risk:** HIGH | MEDIUM | LOW
**Complexity:** [Simple | Moderate | Complex | Very Complex]
**Blast Radius:** [Isolated | Module-wide | System-wide | External APIs affected]
**Requires Immediate Review:** [YES / NO – why]

---
---

### 2. Critical Issues
_If none, write "None found."_

#### 1. [ISSUE TITLE]
**File:** `path/to/file.js:L125`
**Impact:** Data loss / Security hole / System crash
**Fix:**
// Suggested code fix

---

### 4. 🎯 Maintainer Decision Guide
### 3. Concerns
_Should discuss or fix before merge. If none, write "None found."_

**Merge confidence:** [0–100]%
- □ Safe to merge after fixing blockers
- □ Needs architecture discussion first
- □ Requires performance testing
- □ Get security team review
- □ Author should split into smaller PRs
- [PERFORMANCE] Unindexed query on large table
- [SECURITY] Missing input sanitization in login form

**Time to properly review:** ~[X] minutes
**Recommended reviewer expertise:** [Backend | Security | Database | Frontend]
---

### 4. Merge decision

**Merge confidence:** [0–100]%
- [ ] Safe to merge after fixing blockers
- [ ] Needs architecture discussion first
- [ ] Requires performance testing
- [ ] Get security team review
- [ ] Author should split into smaller PRs

---
**Time to properly review:** ~[X] minutes
**Recommended reviewer expertise:** [Backend | Security | Database | Frontend]

---

### 5. 🧭 Formatting Rules
Keep sections short. If a section is empty, write "None found." Include code examples only for blockers. Use prefixes like [SECURITY], [PERFORMANCE], [LOGIC] for easy scanning.
```

- Use emoji headers for instant visual recognition
- Keep sections short; if empty, say “None found”
- Blockers get full detail, everything else stays concise
- Include code examples only for blockers
- Bold key impact/risk words
- Use consistent prefixes like [SECURITY], [PERFORMANCE], [LOGIC] for easy scanning
- If PR is genuinely fine, end with: ✅ “This PR is safe to merge as-is.”
## Next steps

```
Explore related guides and features:

</Steps>
- [Review AI-generated code](/guides/agent-workflows/how-to-review-ai-generated-code/) — review and comment on code diffs directly in Warp's Code Review panel
- [Attach agent session context to GitHub PRs](/guides/agent-workflows/how-to-attach-agent-session-context-to-github-prs/) — embed the prompt, plan, and agent decisions into the PR for your reviewers
- [Code Review panel](/code/code-review/) — full reference for visual diffs and inline comments in Warp
Loading
Loading