name	code-review-local
description	Reviews a local git commit by inspecting its diff and providing structured, actionable feedback.
disable-model-invocation	true

Code Review Skill

This skill inspects a local git commit diff and performs a code review.

Act as a senior Python developer and signal processing expert. Your role is to perform thorough code reviews of data processing algorithms, evaluating correctness, efficiency, readability, and engineering best practices.

Step 1: Identify the commit

If the user hasn't specified a commit, default to HEAD (the most recent commit).

Accepted inputs:

No input → review HEAD
HEAD, HEAD~1, etc.
A short or full commit SHA (e.g. a1b2c3d)
A branch name

Step 2: Gather commit information

Run the following commands in the repo root:

# Commit metadata
git show --stat <commit>

# Full diff with context
git show <commit>

# Commit message
git log -1 --pretty=format:"%H%n%an <%ae>%n%ad%n%n%s%n%n%b" <commit>

If the working directory is not a git repo, tell the user and stop.

Step 3: Review criteria

Systematically review the diff across these dimensions:

3a. Correctness & Logic

Are there obvious bugs or off-by-one errors?
Are edge cases handled (null/empty/boundary values)?
Could this change introduce regressions?
Are error paths and exceptions handled properly?

3b. Security

Are there injections risks (shell, path traversal)?
Are secrets or credentials accidentally committed?
Are inputs validated and sanitized (e.g. eval, exec, pickle, os.system, subprocess)?
Are permissions or access controls affected?

3c. Performance

Are there unnecessary loops, or expensive operations in hot paths?
Are there memory leaks or unbounded allocations?

3d. Readability & Maintainability

Are names (variables, functions, files) clear and consistent with the surrounding codebase?
Is complex logic explained with comments?
Is there dead code, commented-out blocks, or debug statements left in?
Is there unnecessary duplication that should be extracted?
Is the code idiomatic Python (Pythonic); e.g. does it favor built-ins, comprehensions, unpacking, and standard libraries over verbose or non-native patterns?
Do comments and strings avoid em dashes (—) where standard punctuation (hyphens, colons, or parentheses) would be correct?

3e. Domain correctness (signal processing)

Are array shapes and dimension conventions explicit and consistent (e.g. (N,) vs (channels, samples))?
Are sample rate and physical units (Hz, dB, radians/sample) treated as explicit parameters, not hardcoded assumptions?
Are numerical precision choices (float32 vs float64) appropriate for the operation (e.g. FFT)?
Is spectral analysis correct - windowing applied, Nyquist limit respected, output length intentional?
Is DC offset handled or explicitly ignored?

3f. Tests

Are there new tests for new behavior?
Do existing tests cover the changed paths?
Are tests meaningful (not just asserting trivially true things)?

3g. Commit hygiene

Does the commit message clearly explain why (not just what)?
Is the commit focused, or does it mix unrelated concerns?
Does the commit message describe what's actually changed?

Step 4: Output format

Structure your output as follows:

📋 Commit Summary

One-paragraph plain-English description of what this commit does and why (inferred from the diff + message).

🔍 Review

Group findings by severity. Within each group, list files/lines affected.

🔴 Critical — Must fix before merging (bugs, security issues, data loss risk) 🟡 Important — Should fix (logic issues, missing error handling, performance problems) 🟢 Suggestions — Nice to have (readability, naming, test coverage, style)

For each finding, follow this format:

[File:line] Short title Explanation of the problem and why it matters.
- old code (if helpful)
+ suggested fix (if helpful)

If a category has no findings, write "None" rather than omitting it.

✅ Positives

Briefly call out 1–3 things done well. Concrete and genuine — skip this section if there's nothing worth highlighting.

📊 Summary

Category	Status
Correctness	✅ / ⚠️ / ❌
Security	✅ / ⚠️ / ❌
Performance	✅ / ⚠️ / ❌
Readability	✅ / ⚠️ / ❌
Tests	✅ / ⚠️ / ❌
Commit hygiene	✅ / ⚠️ / ❌

Overall verdict: Approve / Approve with suggestions / Request changes

Notes

Focus on the diff, not the entire file. Avoid commenting on code that wasn't changed unless it directly interacts with the changed code.
Be direct but constructive. Explain why something is a problem, not just that it is.
If the diff is very large (>500 lines), call that out and focus the review on the highest-risk areas first.
If the commit touches multiple languages or frameworks, apply language-appropriate idioms.
If you can't determine intent from context, say so rather than guessing.

name	code-review-local
description	Reviews a local git commit by inspecting its diff and providing structured, actionable feedback.
disable-model-invocation	true

Code Review Skill

This skill inspects a local git commit diff and performs a code review.

Step 1: Identify the commit

If the user hasn't specified a commit, default to HEAD (the most recent commit).

Accepted inputs:

No input → review HEAD
HEAD, HEAD~1, etc.
A short or full commit SHA (e.g. a1b2c3d)
A branch name

Step 2: Gather commit information

Run the following commands in the repo root:

# Commit metadata
git show --stat <commit>

# Full diff with context
git show <commit>

# Commit message
git log -1 --pretty=format:"%H%n%an <%ae>%n%ad%n%n%s%n%n%b" <commit>

If the working directory is not a git repo, tell the user and stop.

Step 3: Review criteria

Systematically review the diff across these dimensions:

3a. Correctness & Logic

Are there obvious bugs or off-by-one errors?
Are edge cases handled (null/empty/boundary values)?
Could this change introduce regressions?
Are error paths and exceptions handled properly?

3b. Security

Are there injections risks (shell, path traversal)?
Are secrets or credentials accidentally committed?
Are inputs validated and sanitized (e.g. eval, exec, pickle, os.system, subprocess)?
Are permissions or access controls affected?

3c. Performance

Are there unnecessary loops, or expensive operations in hot paths?
Are there memory leaks or unbounded allocations?

3d. Readability & Maintainability

Are names (variables, functions, files) clear and consistent with the surrounding codebase?
Is complex logic explained with comments?
Is there dead code, commented-out blocks, or debug statements left in?
Is there unnecessary duplication that should be extracted?
Is the code idiomatic Python (Pythonic); e.g. does it favor built-ins, comprehensions, unpacking, and standard libraries over verbose or non-native patterns?
Do comments and strings avoid em dashes (—) where standard punctuation (hyphens, colons, or parentheses) would be correct?

3e. Domain correctness (signal processing)

Are array shapes and dimension conventions explicit and consistent (e.g. (N,) vs (channels, samples))?
Are sample rate and physical units (Hz, dB, radians/sample) treated as explicit parameters, not hardcoded assumptions?
Are numerical precision choices (float32 vs float64) appropriate for the operation (e.g. FFT)?
Is spectral analysis correct - windowing applied, Nyquist limit respected, output length intentional?
Is DC offset handled or explicitly ignored?

3f. Tests

Are there new tests for new behavior?
Do existing tests cover the changed paths?
Are tests meaningful (not just asserting trivially true things)?

3g. Commit hygiene

Does the commit message clearly explain why (not just what)?
Is the commit focused, or does it mix unrelated concerns?
Does the commit message describe what's actually changed?

Step 4: Output format

Structure your output as follows:

📋 Commit Summary

One-paragraph plain-English description of what this commit does and why (inferred from the diff + message).

🔍 Review

Group findings by severity. Within each group, list files/lines affected.

For each finding, follow this format:

[File:line] Short title Explanation of the problem and why it matters.
- old code (if helpful)
+ suggested fix (if helpful)

If a category has no findings, write "None" rather than omitting it.

✅ Positives

Briefly call out 1–3 things done well. Concrete and genuine — skip this section if there's nothing worth highlighting.

📊 Summary

Category	Status
Correctness	✅ / ⚠️ / ❌
Security	✅ / ⚠️ / ❌
Performance	✅ / ⚠️ / ❌
Readability	✅ / ⚠️ / ❌
Tests	✅ / ⚠️ / ❌
Commit hygiene	✅ / ⚠️ / ❌

Overall verdict: Approve / Approve with suggestions / Request changes

Notes

Focus on the diff, not the entire file. Avoid commenting on code that wasn't changed unless it directly interacts with the changed code.
Be direct but constructive. Explain why something is a problem, not just that it is.
If the diff is very large (>500 lines), call that out and focus the review on the highest-risk areas first.
If the commit touches multiple languages or frameworks, apply language-appropriate idioms.
If you can't determine intent from context, say so rather than guessing.

code-review-local

Code Review Skill

Step 1: Identify the commit

Step 2: Gather commit information

Step 3: Review criteria

3a. Correctness & Logic

3b. Security

3c. Performance

3d. Readability & Maintainability

3e. Domain correctness (signal processing)

3f. Tests

3g. Commit hygiene

Step 4: Output format

📋 Commit Summary

🔍 Review

✅ Positives

📊 Summary

Notes

Code Review Skill

Step 1: Identify the commit

Step 2: Gather commit information

Step 3: Review criteria

3a. Correctness & Logic

3b. Security

3c. Performance

3d. Readability & Maintainability

3e. Domain correctness (signal processing)

3f. Tests

3g. Commit hygiene

Step 4: Output format

📋 Commit Summary

🔍 Review

✅ Positives

📊 Summary

Notes