with one click
planning-docs
Planning skill for documentation - no changelog updates
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
Planning skill for documentation - no changelog updates
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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-docs |
| description | Planning skill for documentation - no changelog updates |
Use this skill when creating or updating documentation.
**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 documentation-specific rules below. Documentation changes do NOT require changelog updates.
Identify what type of documentation is being created/updated:
Consider who will read this documentation:
Plan the documentation structure before writing:
Save to planning/docs-<name>.md:
# Documentation: <Doc Name>
## Goal
<What documentation is being created/updated>
## Type
<API/User Guide/Developer Guide/Code Comments/README/Architecture>
## Audience
<Who will read this, their skill level, what they need>
## Analysis
<Current state, gaps, related docs>
## Tasks
- [ ] Task 1
- [ ] Task 2
- [ ] Review for clarity
## Structure
<Outline of documentation sections>
## Notes
<Style guides, templates to follow, related links>
User request: "Document the authentication flow"
Planning output:
# Documentation: Authentication Flow
## Goal
Create comprehensive documentation of the authentication system
## Type
Developer Guide + Architecture
## Audience
- Backend developers integrating with auth system
- New team members understanding the codebase
- Skill level: Intermediate developers
## Analysis
- Current state: Only inline code comments exist
- Gaps: No flow diagrams, no token lifecycle explanation
- Related: API docs mention auth but don't explain it
## Tasks
- [ ] Create auth flow diagram (login, refresh, logout)
- [ ] Document token lifecycle and storage
- [ ] Explain role-based access control
- [ ] Add code examples for common auth operations
- [ ] Review and link from main README
## Structure
1. Overview
2. Authentication Flow Diagram
3. Token Management
- Access tokens
- Refresh tokens
- Token storage
4. Role-Based Access Control
5. Code Examples
6. Troubleshooting
## Notes
- Use Mermaid for diagrams
- Follow existing docs/STYLE_GUIDE.md
- Link to API docs for endpoint details