القائمة
Template and rules for writing PR descriptions
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Transform a plan (from session memory, a markdown file, or inline description) into agent-executable tasks in docs/IMPLEMENTATION.md following the project's established format. Use when the user says "add to implementation", "convert plan to tasks", "create tasks from this plan", "add a phase", or similar.
Check a PR for unresolved review comments, assess each one, apply fixes where needed, and resolve addressed threads via the GitHub API. Use this skill whenever the user mentions PR comments, review threads, unresolved feedback, or addressing reviewer suggestions — even if they just say "fix the comments", "close out the review threads", or "address the feedback".
Perform a thorough, project-aware code review on the current PR and post it to GitHub as a real review with inline comments via the GitHub API. Use this skill whenever the user says "review", "review this PR", "review my changes", "do a code review", "give me feedback on this branch", or "check my PR" — especially when working in a git worktree. Trigger even if the user just says "review" with no other context.
Implements a project task from docs/IMPLEMENTATION.md when the user says "implement task X.XX" (e.g. "implement task 1.11", "implement task 2.02"). Reads the task spec, sets up a git worktree on the correct branch, then implements the task end-to-end following project conventions. Use this skill whenever the user says "implement task", "do task", "work on task", or references a task ID like "1.07", "2.03", etc. in this project.
Systematic process for diagnosing and fixing a failing test
Process for safely adding or updating npm dependencies
| name | pr-description |
| description | Template and rules for writing PR descriptions |
| disable-model-invocation | true |
Every PR description must contain these sections:
## What
[One paragraph: what changed and why. Link the Hive task ID.]
## How
[Technical approach: key decisions made, alternatives considered, trade-offs.]
## Testing
[How was this verified? Which test commands were run? Include output for non-obvious cases.]
## Screenshots / recordings
[For UI changes: before/after screenshots or a screen recording. Delete section if not applicable.]
## Checklist
- [ ] Tests added or updated
- [ ] `npm test` passes locally
- [ ] No new lint errors (`npm run lint`)
- [ ] Breaking changes documented in the PR body
- [ ] Dependent PRs linked in description
Keep the "What" section readable by non-engineers — it will end up in the changelog.