con un clic
planning-bugfix
Planning skill for bug fixes - includes optional changelog update
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Menú
Planning skill for bug fixes - includes optional changelog update
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Given a TheRock nightly build (URL or run-id), return the rocm-systems pin_sha used in that build
Check whether a given rocm-systems commit is included in a specific TheRock nightly build
Find the first TheRock nightly build that includes a given rocm-systems commit
Reviews Pull Requests or local diffs with an 8-agent fan-out covering static analysis, dead code, code smells + quality (naming, complexity, single-responsibility, magic numbers), language rules (C++/Python/CMake), architecture, simplification, performance (hot-path classification, allocations, locks, I/O), and undefined behaviour (signed overflow, lifetime, strict aliasing, data races, sanitizer coverage; C/C++/unsafe-Rust only). Use when the user asks to "review this PR", "review the diff", "audit this branch", "/pr-review", or when staging changes before push.
Walk through a PR review interactively, one finding at a time. Generate review via pr-review, then for each issue present analysis + proposed inline comment, let user accept/edit/skip, accumulate into a PENDING GitHub review, submit at end.
Use when user wants to list, analyze, review, or summarize GitHub PR comments on a pull request number or URL
| name | planning-bugfix |
| description | Planning skill for bug fixes - includes optional changelog update |
Use this skill when fixing bugs, errors, or unexpected behavior.
**Prerequisites:** Invoke `planning-base` skill first if not already loaded. It provides the core planning phases (0-5).Follow all base planning rules, plus the bugfix-specific rules below.
Before proposing fixes, identify:
After analysis, ASK the user:
"Should this bugfix be added to the changelog?
- Yes: If it's a user-facing bug that affected functionality
- No: If it's an internal fix or minor issue
Add to changelog? (yes/no)"
If yes, include changelog entry:
## Changelog Entry
### Fixed
- <Brief description of what was broken and how it's fixed>
After COMPLETING the bugfix:
planning/testplan-<bugfix-name>.mdtesting-testplan skill for the templateThen ASK the user:
"Bugfix is complete. Would you like me to add a regression test to prevent this bug from recurring?"
If user agrees:
testing-gtest-gmock (C++) or testing-pytest (Python)After tests (if any), ASK the user:
"Ready to create a Pull Request. Should I proceed?"
If yes, invoke git-create-pull-request skill and create PR with:
Save to planning/bugfix-<name>.md:
# Bugfix: <Bug Description>
## Problem
<What is broken, error messages, symptoms>
## Root Cause
<Why the bug occurs>
## Analysis
<Affected files, related code, risks of fix>
## Tasks
- [ ] Task 1
- [ ] Task 2
- [ ] Verify fix works
## Changelog
<Entry if requested, or "Not added to changelog">
## Regression Test
<Test description if requested, or "No regression test">
## Notes
<Any additional context>
User request: "Fix login timeout - users getting logged out after 5 minutes"
Planning output:
# Bugfix: Premature Session Timeout
## Problem
Users are being logged out after 5 minutes instead of the expected 30 minutes.
Error: "Session expired" toast appears unexpectedly.
## Root Cause
Token refresh interval was set to 5 minutes (300000ms) but the condition
checked for token age > 5 minutes, causing immediate refresh failure loop.
## Analysis
- File: src/auth/tokenService.ts, line 45
- The refresh check uses `>` instead of `>=`, causing edge case failure
- Risk: Low - isolated fix in token handling
## Tasks
- [ ] Fix comparison operator in tokenService.ts
- [ ] Verify token refresh works correctly
- [ ] Update CHANGELOG.md
## Changelog
### Fixed
- Session timeout now correctly respects 30-minute duration
## Regression Test
- [ ] Unit: Token refresh timing edge cases
## Notes
- Also found: TOKEN_REFRESH_INTERVAL constant should be moved to config