| name | swe:recent-commit-bug-hunt |
| description | Scans recent commits in one or more repositories, identifies likely bugs using concrete repo evidence only, and proposes tightly scoped remediation sessions. Use when a user says `scan recent commits for bugs`, `what did I probably break`, `review yesterday's changes for regressions`, or asks for a commit-scoped bug hunt. Do NOT use for a broad code health review, full security audit, or speculative bug hunting with no repo or time scope. |
| compatibility | Requires local git history and works best with access to CI output, failing tests, linked PR metadata, or other validation signals tied to recent changes. |
| metadata | {"short-description":"Find likely bugs in recent commits"} |
SWE Recent Commit Bug Hunt
What This Skill Does
Use this skill to inspect recent code changes conservatively and separate:
- Real regression signals
- Plausible but weaker suspicions
- Noise that should not become a fix proposal
The outcome should be a ranked list of evidence-backed findings plus small,
behavior-focused remediation sessions for the findings that clear the bar.
When To Use
Use this skill when the user wants to:
- Review recent commits for likely regressions
- Check whether their latest changes introduced bugs
- Mine recent PRs or SHAs for concrete bug signals
- Propose narrowly scoped follow-up fix sessions
Do Not Use
Do not use this skill for:
- A generic code smell review
- A security or dependency audit
- A large-scale refactor plan
- Speculative bug hunting with no commit scope
Inputs To Confirm
Confirm or infer:
- Repository set
- Author filter, if any
- Time window
- Whether linked PR or CI context is available
- Whether local validation can be run
If scope is missing, ask for the repo set, author, and timeframe before
proceeding.
Evidence Sources
Concrete evidence includes:
- Commit SHAs
- Pull requests
- File paths
- Diffs
- Failing tests
- CI failures or warnings
- Local validation signals directly tied to the changed area
If the evidence is weak, report the suspicious finding and skip the fix
proposal.
Hard Constraints
- Use only concrete repo evidence
- Do not invent bugs
- Do not overstate confidence
- Do not propose speculative fixes when the evidence is weak
- Prioritize the smallest safe fix possible
- Avoid refactors, cleanup work, or unrelated improvements
- Keep each remediation proposal tightly scoped to the implicated files and
behavior
Instructions
Step 1: Define The Review Scope
Respect the user-provided repository set, author filter, and time window
exactly.
If the user names a repo group or org surface, stay within that scope.
Step 2: Collect Recent Changes And Context
Gather the relevant commits and any linked:
- PR metadata
- Review context
- CI status
- Failing tests
- Local validation signals
Step 3: Inspect Diffs For Regression Signals
Focus on recent-change failure modes such as:
- Changed conditionals that likely broke a branch or guard
- Removed or inconsistent validation
- Interface mismatches across a call boundary
- Incomplete multi-file updates
- Broken mappings, serializers, or adapters
- Missing null, error, or edge-case handling introduced by the change
- Tests or CI failures directly tied to the changed surface
Step 4: Run Targeted Validation When It Strengthens The Evidence
Run the narrowest useful checks only when they directly strengthen or weaken the
case. Do not run broad unrelated test suites just to fill space.
Step 5: Bucket Findings By Evidence Strength
Separate findings into:
- Strong evidence: concrete failure or very specific regression signal
- Moderate evidence: diff-backed likely bug with clear local impact
- Weak evidence: suspicious but not strong enough to justify a fix proposal
Only propose remediation sessions for strong or moderate findings.
What Counts As A Good Finding
Every proposed issue should:
- Tie back to one or a few recent commits
- Name the exact repo and file surface
- Explain the concrete evidence
- Describe a minimal, behavior-focused fix
- Include a clear validation path
Avoid:
- Old bugs not clearly connected to the scoped commits
- General code smell with no bug signal
- Large rewrites
- Style-only issues
- Findings that require broad product or domain assumptions
Step 6: Propose Minimal Remediation Sessions
For every finding that clears the evidence bar, propose one small remediation
session with:
- Session name
- Objective
- Target repo
- Expected files to touch
- Minimal fix strategy
- Validation plan
Prefer one issue per session unless two issues share the same tiny write
surface and can safely be fixed together.
Output Requirements
Provide a report with these sections:
- Scope reviewed
- Ranked findings
- Weak-signal findings skipped
- Proposed remediation sessions
For each identified issue, include:
- Repo
- Commit SHA or SHAs and PRs, if available
- Relevant files
- Concrete evidence
- Why this is likely a bug
- Minimal fix to attempt
- Suggested validation
- Confidence level
For each weak-signal finding, include:
- Repo
- Commit or file reference
- What looked suspicious
- Why the evidence was insufficient
- Explicit no-fix decision
Examples
Example 1
User says: Review my commits from the last 24 hours in billing-api and tell me what I probably broke.
Actions:
- Filter the commit set to the requested author and timeframe
- Inspect diffs plus CI or test signals
- Rank only evidence-backed findings
- Propose minimal fix sessions for the strong and moderate issues
Result: The user gets a short bug-hunt report instead of generic cleanup ideas.
Example 2
User says: Scan the last two merged PRs in checkout-service for likely regressions and suggest the smallest fixes.
Actions:
- Gather the PRs, SHAs, changed files, and available validation context
- Inspect interface boundaries, conditionals, and missing edge-case handling
- Separate strong findings from weak suspicions
- Propose only the smallest safe remediation sessions
Result: Each proposed fix is directly tied to a recent change and a clear
validation path.
Troubleshooting
Problem: The Scope Is Too Broad
If the request spans too many repos or too much history, narrow it before doing
deep analysis. A focused 24-72 hour window is usually more reliable than a
vague multi-month sweep.
Problem: The Evidence Never Gets Past Weak Suspicion
Say so explicitly. Report the suspicious signals in the
Weak-signal findings skipped section and make the no-fix decision clear.
Problem: Local Validation Cannot Be Run
Rely on diffs, CI, and directly linked repo evidence, but say what validation
was unavailable and lower your confidence accordingly.
Quality Bar
- Be conservative and evidence-led
- Use exact SHAs, PRs, paths, tests, and CI signals whenever available
- If no issues meet the evidence bar, say so clearly
- Keep the proposed fixes minimal and tightly scoped
