diff-review

Estrellas11

Forks2

Actualizado1 de julio de 2026 a las 18:08

Open the current branch's diff (or a specific PR) in Plannotator's browser-based code review UI and act on the returned feedback. Use when the user says "review my changes in plannotator", "open the diff for review", "review this PR in plannotator", "let me annotate the diff", or returns to a session to gate code the agent produced.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Fuente

hay-kot

hay-kot/dotfiles

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Analistas de garantía de calidad de software y probadoresOcupaciones informáticas y matemáticas·SOC 15-1253

SKILL.md

readonly

name	diff-review
description	Open the current branch's diff (or a specific PR) in Plannotator's browser-based code review UI and act on the returned feedback. Use when the user says "review my changes in plannotator", "open the diff for review", "review this PR in plannotator", "let me annotate the diff", or returns to a session to gate code the agent produced.
allowed-tools	Bash(plannotator:*),Read
disable-model-invocation	true

Diff Review

Open code changes in Plannotator's review UI, then act on the user's feedback in the same conversation. Plannotator's review mode handles both the current worktree (no args) and a specific PR (URL).

Argument handling

$ARGUMENTS controls what gets reviewed:

Argument	Behavior
empty	Current branch's working changes vs base
GitHub PR URL	That pull request
Gitea/Forgejo PR URL	That pull request (if Plannotator supports the host)

Don't try to detect or resolve the current PR yourself — plannotator review already inspects the worktree when called with no args. Just pass $ARGUMENTS through.

Run

plannotator review $ARGUMENTS

Run the command yourself. Don't ask the user to copy it into a terminal.

After plannotator returns

Feedback or annotations returned — address each one in the same conversation. For each comment, locate the referenced file/line, make the change, and summarize what was fixed. Offer to re-run review when done.
Approval / LGTM — acknowledge the review passed and continue (commit, push, open PR, whatever the next step is).
No feedback returned — the user closed the session without comment. Say so briefly and continue.

Notes

Plannotator review surfaces diff-anchored annotations; treat each one as a request for a specific code change, not a general suggestion.
For deep multi-dimensional review (correctness, design, tests, comments) use /review instead — that runs parallel sub-agents. This skill is for the human-in-the-loop browser review, not automated review.
If the user wants to gate a markdown plan or research doc instead of code, use /doc-review.

Más de este repositorio

mismo repositorio

hay-kot/dotfiles

Best practices for working with Go codebases. Use when writing, debugging, or exploring Go code, including reading dependency sources and documentation.

2026-07-1611

hc-loop

hay-kot/dotfiles

Autonomous orchestration loop for hive hc tasks. The high-capability manager model reads pending tasks, delegates implementation to cheaper worker sub-agents, critically reviews their output, and commits only code that passes quality checks. Runs to completion without stopping to ask questions.

2026-07-1311

rethink

hay-kot/dotfiles

Post-implementation design re-evaluation. After a feature reaches a working state through iteration, step back and re-examine what actually got built: are the data structures and algorithms the right fit for the access patterns that emerged, can code paths that grew through iteration be consolidated, and what iteration residue (tests for abandoned designs, dead flags/scaffolding, debug logging) should be deleted. Produces a tiered proposal report and applies only approved changes. Use when the user says "rethink this", "step back and re-evaluate", "is this the right design/data structure", "apply CS fundamentals", or wants a design pass on a working feature branch before PR. Not for bug-hunting (/review) or expression-level polish (/simplify) — this questions the design those skills preserve.

2026-07-0411

agent-orchestrator

hay-kot/dotfiles

Orchestrate parallel claude and codex CLI agents through tmux to deliver a feature end-to-end. The orchestrator delegates planning, work, and review to spawned agents in tmux windows; it does NOT write or edit code itself. User-invoked only.

2026-07-0111

review

hay-kot/dotfiles

Single-pass code review of the current branch (or a diff) that routes the changes to relevant concerns, dispatches fresh-context reviewer sub-agents, verifies findings to strip false positives, and reports a ranked, evidence-backed review. Use when the user asks to review local changes, a branch, or a PR before it goes to humans.

2026-07-0111

review-with-codex

hay-kot/dotfiles

Spawn codex as an independent external reviewer in a new tmux window. Codex performs a general PR review and publishes findings back via hive messaging. Use standalone for an external second opinion, or alongside /review to run both concurrently.

2026-07-0111

name	diff-review
description	Open the current branch's diff (or a specific PR) in Plannotator's browser-based code review UI and act on the returned feedback. Use when the user says "review my changes in plannotator", "open the diff for review", "review this PR in plannotator", "let me annotate the diff", or returns to a session to gate code the agent produced.
allowed-tools	Bash(plannotator:*),Read
disable-model-invocation	true

Diff Review

Open code changes in Plannotator's review UI, then act on the user's feedback in the same conversation. Plannotator's review mode handles both the current worktree (no args) and a specific PR (URL).

Argument handling

$ARGUMENTS controls what gets reviewed:

Argument	Behavior
empty	Current branch's working changes vs base
GitHub PR URL	That pull request
Gitea/Forgejo PR URL	That pull request (if Plannotator supports the host)

Don't try to detect or resolve the current PR yourself — plannotator review already inspects the worktree when called with no args. Just pass $ARGUMENTS through.

Run

plannotator review $ARGUMENTS

Run the command yourself. Don't ask the user to copy it into a terminal.

After plannotator returns

Feedback or annotations returned — address each one in the same conversation. For each comment, locate the referenced file/line, make the change, and summarize what was fixed. Offer to re-run review when done.
Approval / LGTM — acknowledge the review passed and continue (commit, push, open PR, whatever the next step is).
No feedback returned — the user closed the session without comment. Say so briefly and continue.

Notes

Plannotator review surfaces diff-anchored annotations; treat each one as a request for a specific code change, not a general suggestion.
For deep multi-dimensional review (correctness, design, tests, comments) use /review instead — that runs parallel sub-agents. This skill is for the human-in-the-loop browser review, not automated review.
If the user wants to gate a markdown plan or research doc instead of code, use /doc-review.