| name | ddr |
| description | Use when the user runs /ddr to get a pre-commit review of the currently staged Git diff in SDRLoggerPlus. |
| disable-model-invocation | true |
ddr — Pre-Commit Review of Staged Changes
Perform a read-only pre-commit review of SDRLoggerPlus, a C# Windows desktop radio-logging and SDR-adjacent application.
Procedure
- Run
git diff --cached to get the staged diff. Also run git diff --cached --stat for an overview.
- If nothing is staged, stop immediately and tell the user: "Nothing is staged — stage changes with
git add before running /ddr." Do not review the working tree instead.
- Review only code introduced, removed, or behaviorally affected by the staged diff. Read nearby unchanged code (with Read/Grep) when needed to understand the diff — but do not conduct a general codebase audit.
- Never modify files, stage changes, or commit. This skill is strictly read-only.
Review priorities (in order)
- Correct behavior and data integrity
- Logging accuracy
- Reliability and recoverability
- UI responsiveness and thread safety
- Maintainability
Check for
- Logic, state, boundary, and off-by-one errors
- Null-reference and object-lifetime risks
- Incorrect async, cancellation, synchronization, or exception behavior
- UI-thread violations, blocking work, deadlocks, races, and re-entrancy
- Incorrect or duplicated event subscriptions
- Resource leaks involving streams, files, timers, devices, subscriptions, or disposable objects
- Unsafe file I/O, partial writes, concurrent access, encoding, and serialization compatibility
- Culture-sensitive parsing
- Timestamp, time-zone, frequency-unit, rounding, and logging-accuracy errors
- Dropped, duplicated, or incorrectly ordered log records
- Settings load, save, migration, validation, and compatibility regressions
- Weak error handling that hides failures or leaves inconsistent state
- Meaningful readability, duplication, maintainability, and test gaps
C# desktop concerns (pay particular attention)
async void outside legitimate event handlers- Unobserved fire-and-forget tasks
- Synchronously blocking asynchronous operations
- Updating UI-bound state from background threads
- Callbacks or timers surviving window shutdown
- Cancellation and disposal during shutdown
- Shared mutable state across callbacks or threads
- Incorrect
IDisposable or IAsyncDisposable ownership
Rules
- Distinguish newly introduced problems from pre-existing issues exposed by the change.
- Do not speculate or manufacture findings. Explain the concrete execution path behind every claimed defect.
- Order findings by severity and impact.
- Avoid duplicate findings with the same root cause.
- Do not report generic best practices.
- State when additional context is required to confirm a concern.
- Include replacement code only for small, unambiguous fixes.
- If no findings exist, explicitly say so.
- Use
Fix Before Commit only when there is at least one substantiated must-fix issue.
Severity definitions
- Critical: Likely crash, deadlock, data loss/corruption, materially inaccurate logging, or severe workflow regression
- Medium: A real correctness or reliability problem under plausible conditions
- Low: A worthwhile maintainability, clarity, resilience, or testability improvement
Finding format
For every finding, output:
[Severity] Concise title
- Location: File, method/type, and changed lines when available
- Classification: Must fix or Should improve
- Confidence: High, Medium, or Low
- Problem: The specific defect or risk
- Impact: A realistic failure mode
- Evidence: The relevant execution path or changed behavior
- Recommended fix: The smallest safe correction
- Verification: A focused test or manual check
Required ending
End with exactly:
Pre-Commit Recommendation
- Status: Approve | Fix Before Commit
- Must fix: <count and concise list, or "None">
- Nice to improve: <count and concise list, or "None">
- One-paragraph summary: <decision, highest-risk area, and what should be verified>
