project-changes-reviewer

name	project-changes-reviewer
description	On-demand review of recent changes in tracked external projects (frameworks, dependencies, client codebases) using git history. Produces categorized summaries with since-last-review tracking. Auto-activates when reviewing project updates, checking what changed, or monitoring external codebases. Trigger keywords: what changed, recent changes, project updates, since last review, changelog, upstream changes, dependency updates, framework changes.
license	MIT
metadata	{"version":"1.0.0","hermes":{"tags":["Review","Git","Changelog","Dependencies","Upstream","Categorization"],"related_skills":["git-commit-theme-analyzer","git-limited-history-analysis"]}}

Project Changes Reviewer

On-demand review and categorization of recent changes in tracked external projects. Review when needed, categorize by impact, highlight what affects you.

Key Principles

1. On-Demand Over Continuous — review when needed, not constantly
2. Categorization Over Chronology — group by impact type, not commit order
3. Actionability Over Completeness — highlight what affects you, skip internal refactors
4. Markers Over Memory — track "last reviewed" state per project

Methodology

Step 1: Identify Review Scope

Scope	Use Case	Output
Quick	Daily check-in	One-liners per significant change
Standard	Weekly review	Categorized summary with context
Deep	Major version jump	Full breakdown with file-level detail

Step 2: Extract Changes

git -C <project_path> log --oneline <last_reviewed>..HEAD
git -C <project_path> log --oneline --since="2025-01-01"
git -C <project_path> shortlog -sn <last_reviewed>..HEAD
git -C <project_path> diff --stat <last_reviewed>..HEAD
git -C <project_path> diff --name-status <last_reviewed>..HEAD

Step 3: Categorize & Summarize

Category	Indicators	Impact Level
Features	"add", "implement", "new"	High — new capabilities
Fixes	"fix", "bug", "resolve"	Medium — behavior changes
Refactoring	"refactor", "cleanup", "reorganize"	Low — internal only
Dependencies	Gemfile, package.json changes	Variable — check for breaking
Documentation	README, docs/, CHANGELOG	Low — informational
Breaking	BREAKING, major version, deprecation	Critical — requires action

Step 4: Document & Update

1. Save review note only if breaking changes, major features, or action required
2. Update last reviewed marker with new commit hash
3. Flag follow-ups: breaking changes requiring code updates, new features to explore

Key Rules

• Always use git -C <path> — never rely on working directory
• Always grep for BREAKING, deprecat, removed in commit messages
• Always update last_reviewed marker, even for quick reviews
• Only save notes when breaking changes or significant features found
• Match review frequency to project activity and your usage