بنقرة واحدة
planning-docs
Planning skill for documentation - no changelog updates
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Planning skill for documentation - no changelog updates
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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-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