Run any Skill in Manus with one click

review-pr

Stars4

Forks0

UpdatedJuly 16, 2026 at 04:58

Address a requested pull-request comment against the real code at the PR head. Read the thread, source, and covering test; reproduce behavioral claims in the right KIND-backed environment; apply only the minimum valid fix; prove it; then reply and resolve that thread. Trigger when the user asks to address or review a PR comment, a Greptile finding, or a named review thread. For a request covering several comments, repeat this narrow action for each one without combining their scopes.

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

neon-law-foundation

neon-law-foundation/navigator

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

review-pr

description

`/review-pr` — address a PR comment

The authoritative procedure is Address a PR comment. Read it before acting and keep the detail there.

The action is narrow:

Identify the PR and requested comment.
Read the PR head, complete thread, cited source, and covering test.
Reproduce the claim against the right KIND-backed topology when practical.
Adjudicate it as valid, invalid, or valid-but-not-worth-changing, with evidence.
Apply only the valid comment's minimum fix and covering test.
Run the affected gate and prove the changed behavior.
Push, reply with the proof, and resolve only the handled thread.
Report unrelated comments, CI failures, and branch state without changing them.

For a dirty tree that needs a new PR, use create-pr. For a failed GitHub Action, use the separate failed-Action flow in docs/agent-workflows.md.

More from this repository

same repository

create-pr

neon-law-foundation/navigator

Turn a dirty working tree into a clean pull request against `main`: survey every change, group the files into Conventional Commits by blast radius (one concern per commit), run the gate, branch off `main`, capture a visual for any user-visible change, push, and open the PR. Trigger when the user says "/create-pr", "create a PR", "open a pull request", "commit and PR these changes", "group these into commits and ship them", or has a dirty working tree they want landed. Stops at "PR open"; building images and deploying to prod is a separate flow.

2026-07-174

rust

neon-law-foundation/navigator

Workspace Rust guardrails. Trigger on the sharpest moments: a change that adds `unsafe`, `unwrap`, `expect`, or `panic!` outside `main()`/tests; introducing a new public API, error type, or module; reaching for a different web framework, ORM, or async runtime (we standardize on Axum + SeaORM + Tokio); or wiring a new binary's `main()`. Read [`docs/rust-programming.md`](../../../docs/rust-programming.md) before acting — it is the authoritative reference.

2026-07-174

pr-image-upload

neon-law-foundation/navigator

Embed a local screenshot or GIF into a GitHub PR (or issue) body so it actually RENDERS on github.com, driven from the CLI — no drag-drop, no committing the file, no image-hosting branch, no release/tag. It uploads the `/tmp` capture to GitHub's native `user-attachments` CDN via the `gh-image` extension (which borrows your logged-in github.com browser session) and returns a real `https://github.com/user-attachments/assets/…` URL to drop into the body. Trigger as the embed half of [[create-pr]] Step 6 (after [[web-preview]] captures the visual), when a reviewer comment on a PR asks for a "live walkthrough"/screenshot during [[review-pr]], or any time you have a `/tmp` image that must appear in a PR/issue body or comment. This is the LOCAL/`gh` path for hosting and embedding a capture. Capture lives in [[web-preview]] — a walkthrough defaults to a GIF of the real interaction (§5), a still (§3) only for a genuinely static change; this skill only hosts + embeds it.

2026-07-164

web-preview

neon-law-foundation/navigator

Run the `web` app locally against the KIND dependency stack and look at it in a real browser — the canonical "spin up web, drive Chrome, capture to /tmp, verify" loop. Trigger whenever asked to run, preview, screenshot, or visually verify `web` / a page / a UI change, to "open the design page", "check it in chrome", or to prove a front-end behavior (syntax highlighting, a toast, a layout, a keyboard shortcut) actually renders. A PR walkthrough defaults to a GIF of the real interaction (§5); a still is only for a genuinely static change. This is the browser half of the local loop; `kind-local-dev` is the cluster half it builds on. Skip for pure logic/unit work — `cargo test` uses testcontainers and needs no cluster.

2026-07-164

kind-local-dev

neon-law-foundation/navigator

Local Kubernetes-in-Docker (KIND) workflow for the navigator workspace — cluster lifecycle, ingress, port-forwarding, the "host runs `web`, deps run in cluster" iteration pattern via the `navigator` CLI. Trigger when running any `navigator` orchestration subcommand (`dev up`, `dev down`, `dev deploy`, `dev kind up`, `dev kind down`, `dev e2e`, `dev logs`, `dev worktree-env`), editing `k8s/kind-config.yaml`, debugging an in-cluster service from the host, or onboarding the cluster from a fresh machine. Also trigger before installing a different local-Kubernetes flavor — we standardize on KIND. Also trigger before proposing to run, preview, screenshot, or manually exercise the app, or before any action that runs on the user's machine (cluster, browser, or cloud commands) — those resolve to this KIND loop, and the move is to propose the commands for the user to run.

2026-07-164

client-council

neon-law-foundation/navigator

Twelve-perspective review pattern for the people the firm serves ("The Client Council") — the demand-side sibling of the engineering `/council` (the people who *build* Neon Law Navigator) and the `legal-council` (the counsels who *draft* it). Each voice fuses a zodiac stance with a real client walking in the door across the firm's practice areas — Libra the prospective client at the threshold chairs (weighs whether to hire a lawyer at all, then closes on "does this make me walk in and stay?"), Aries the tenant facing eviction names the fire, Pisces the overwhelmed person who almost didn't reach out guards access-to-justice, Capricorn the elder planning their legacy thinks in decades, Leo the wronged client who wants to sue tests the firm's featured litigation practice, and so on. Use it when building Neon Law Navigator — intake flows, questionnaire prompts, pricing copy, portal UX, onboarding — to pressure-test "does this actually serve the human who shows up?" Trigger when the user says "client council", "cu

2026-07-154

name

review-pr

description

`/review-pr` — address a PR comment

The authoritative procedure is Address a PR comment. Read it before acting and keep the detail there.

The action is narrow:

Identify the PR and requested comment.
Read the PR head, complete thread, cited source, and covering test.
Reproduce the claim against the right KIND-backed topology when practical.
Adjudicate it as valid, invalid, or valid-but-not-worth-changing, with evidence.
Apply only the valid comment's minimum fix and covering test.
Run the affected gate and prove the changed behavior.
Push, reply with the proof, and resolve only the handled thread.
Report unrelated comments, CI failures, and branch state without changing them.

For a dirty tree that needs a new PR, use create-pr. For a failed GitHub Action, use the separate failed-Action flow in docs/agent-workflows.md.

review-pr

/review-pr — address a PR comment

More from this repository

More from this repository

/review-pr — address a PR comment

`/review-pr` — address a PR comment

`/review-pr` — address a PR comment