plugins/session-review/skills/session-review/SKILL.md
Review code changes made by Claude in the current session. Reads session-tracked file list from /tmp, runs git diff, and produces a prioritized code review. Use when user says "/session-review", "session review", "세션 리뷰", or "이번 세션 리뷰".
npx skillsauth add jaykim88/claude-ai-engineering session-reviewInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Reviews all files that Claude wrote or edited in the current Claude Code session.
Uses a PostToolUse hook (track-files.sh) to track every Write/Edit, then diffs
against HEAD to produce a focused, scoped code review.
/session-reviewRun the following shell commands to get the tracked files for this session:
# Get current session ID
SESSION=$(cat /tmp/cc-current-session.txt 2>/dev/null)
echo "Session: $SESSION"
# Get unique file paths for this session
if [ -n "$SESSION" ]; then
grep "^${SESSION}|" /tmp/cc-files-all.txt 2>/dev/null \
| cut -d'|' -f2- \
| sort -u
fi
If session ID is empty or file list is empty:
track-files.sh 훅이 활성화되어 있는지 확인하세요."git status --short to get currently modified files as a proxyFor each file in the list:
test -f "$FILE"git -C "$(dirname $FILE)" rev-parse 2>/dev/nullReport any skipped files (non-existent or outside git).
Run git diff for all tracked files at once:
# Show all changes (staged + unstaged) vs HEAD
git diff HEAD -- <file1> <file2> ...
# If a file has no diff vs HEAD (was already committed this session):
# show the last commit's diff for that file
git log --oneline -1 -- <file>
git show HEAD -- <file>
Also run:
git status -- <file1> <file2> ...
to show each file's current state (modified / new / staged).
Analyze ALL diffs together, understanding the session's changes as a whole.
For each issue found, classify:
Output format:
## Session Review — [N] files changed
### Summary
[2-3 sentences: what was done this session, overall quality]
### Files Changed
- `path/to/file.ts` — [one-line description of changes]
- `path/to/file.py` — [one-line description of changes]
### Issues
#### Critical
- **[file:line]** Description of critical issue
#### Important
- **[file:line]** Description of important issue
#### Minor
- **[file:line]** Description of minor issue
### Positive Observations
[Non-obvious things that were done well — only include if genuinely notable]
If no issues found: "No significant issues found. Changes look clean."
After the review output, ask:
리뷰 완료. 특정 파일이나 이슈를 더 자세히 살펴볼까요?
또는 발견된 이슈를 바로 수정할 수도 있습니다.
If /tmp/cc-current-session.txt doesn't exist (hook not active):
settings.json에 track-files.sh 훅을 추가해주세요."git diff HEAD --name-only to find all modified files,
and review those instead (with a note that this is not session-scoped).| Situation | Response |
|-----------|----------|
| No session file | Warn + show hook setup instructions + offer git fallback |
| File deleted mid-session | Skip it, note "deleted during session" |
| File outside any git repo | Skip it, note path |
| Binary file | Skip it |
| Empty diff (committed) | Use git show HEAD -- file instead |
| Very large diff (>500 lines) | Summarize by section instead of line-by-line |
development
Design webhooks correctly on both sides — sending (HMAC signing, retries with backoff, at-least-once) and receiving (verify signature on raw body, enqueue + 200 fast, dedupe on event id). Use when adding webhook delivery or consuming a provider's webhooks. Not for internal service-to-service events (use async-messaging) or general outbound-call retry policy (use resilience-patterns).
testing
Use transactions and isolation levels correctly — keep them short, no network calls inside, explicit isolation, retry on serialization conflicts, and choose optimistic vs pessimistic locking. Use when a write spans multiple tables, when concurrent updates corrupt data, or when designing money/inventory flows. Not for cross-service event delivery (use async-messaging Outbox) or schema-level constraints (use schema-design).
development
Backend testing pyramid — unit for pure logic, integration against a real DB (Testcontainers), and consumer-driven contract testing (Pact) for service boundaries. Use before a feature, after a bug fix, or when services break each other on deploy. Not for load testing (use performance-profiling) or security testing (use backend-security-audit).
data-ai
Design a relational schema — normalize to 3NF then denormalize with justification, choose the right Postgres index type per data shape, enforce constraints at the DB. Use when modeling a new domain, when queries are slow, or before a migration. Not for diagnosing slow queries (use query-optimization) or shipping the change without downtime (use migration-strategy).