Skip to main content

code-review-report

Turn code changes into a single-file HTML code review report that pairs the diff with context a diff can't show — design decisions, rejected alternatives, tradeoffs, unfinished work — plus prioritized review points. Use when preparing for review after finishing a sizable change, refactor, or feature, or whenever the user asks for a review report, change report, or an HTML summary of their changes.

الانتقال إلى التثبيت

معلومات المصدر

المستودع
2ykwang/agent-skills
آخر نشاط في المصدر
٢٧ يوليو ٢٠٢٦ في ٠٧:٥٩
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
١٨
التفرعات
١

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

مستكشف الملفات
7 ملفات

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
name
code-review-report
version
0.1.1
category
development
description
Turn code changes into a single-file HTML code review report that pairs the diff with context a diff can't show — design decisions, rejected alternatives, tradeoffs, unfinished work — plus prioritized review points. Use when preparing for review after finishing a sizable change, refactor, or feature, or whenever the user asks for a review report, change report, or an HTML summary of their changes.
# Code Review Report Build a single-file HTML report a reviewer reads before digging through the raw diff. A diff shows what changed; it doesn't show why, what was rejected, or what's still missing. Filling that gap with the context accumulated in this conversation is what separates this from a diff viewer. ## 1. Collect the change Check the change with `git status` and `git diff`. Default scope: current branch vs the default branch, plus the uncommitted working tree. - `git diff <base>...HEAD` (committed), `git diff HEAD` (uncommitted) - Untracked files don't appear in diffs — find them with `git status` and read them directly. If the scope is mixed or contains unrelated changes, ask the user. Exclude unrelated changes or mark them separately. ## 2. Collect the working context Gather from this conversation the things a diff never records: - What was changed and why - Design decisions and their reasons, rejected alternatives, tradeoffs - Unfinished work and next steps - Concerns raised and reversals made along the way If the conversation lacks this (e.g., the skill was invoked fresh), reconstruct from `git log`, commit messages, PRs, and related docs. If still empty, ask the user. ## 3. Extract review points Hand the changed code and the working context to subagents, and collect what they flag as P1–P3 findings. Read `references/review-perspectives.md` for the perspective list and the subagent prompt skeleton. The context injection is the point — without it you only get surface-level remarks, not findings like spec mismatches or contradictions between decisions. For large changes, run one subagent per perspective in parallel. ## 4. Write the HTML Start from `assets/template.html`. Follow `references/report-structure.md` for sections and `references/style-guide.md` for visual rules. Two things are non-negotiable: - Syntax highlighting on code blocks (add `language-*` classes) - Bidirectional anchors between change details and the review checklist Write the report in the language the user works in: translate the template's headings and set `<html lang>`. Keep code as-is. Before finalizing, run the self-check at the end of `references/report-structure.md`. ## 5. Finalize 1. Save to the project root as `<task-slug>-review-report.html` (kebab-case task name). 2. Inline the vendored highlight.js — replaces the template's placeholder, keeps the report self-contained and offline-friendly: `python3 <skill-dir>/scripts/inline_hljs.py <report-path>` 3. Open it for the user: `open <report-path>` (macOS), `xdg-open` (Linux), `start` (Windows). ## Principles - State tradeoffs, limitations, and unfinished work plainly. - Every change gets a "why", not just a "what". - Quote code; show before→after where possible. - Hierarchy through typography and spacing, not color.
عرض على GitHub