Menu
Generate comprehensive PR descriptions following repository templates. Use when creating, updating, or describing a pull request for review.
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
Write, refactor, restructure, edit, or audit technical documentation using the Diátaxis framework (tutorials, how-to guides, reference, explanation). Produces clear, concise, scannable docs and fights the default tendency toward bloated, over-explained AI prose. Use this skill for ANY documentation work — README and CONTRIBUTING files, API/reference docs, runbooks, guides, getting-started pages, conceptual write-ups, docs-site content, or doc reviews — even when the user just says "document this," "write docs for X," "clean up these docs," "explain how this works in the docs," or "what's missing from our documentation." If the deliverable is documentation, reach for this skill rather than writing prose freehand.
Retroactively create Linear tickets and PRs from untracked commits. Use for commits without tickets, "founder mode", or formalizing experimental work.
Create well-structured git commits from analyzed changes. Use when the user asks to commit, save work, or create a commit.
Find architectural friction and propose deep-module refactors as RFC issues. Use to improve architecture, find refactoring opportunities, or deepen shallow modules.
Initialize the AI Engineering Harness (AGENTS.md + thoughts/ structure). Use on /init_harness or when setting up the harness in a repo.
Interview the user relentlessly to stress-test a plan or design. Use to validate design decisions, "drill in", or "ask me questions" before implementation.
| name | pr-description-generator |
| description | Generate comprehensive PR descriptions following repository templates. Use when creating, updating, or describing a pull request for review. |
| allowed-tools | Read, Bash, Grep, Glob, Edit, Write |
Activate this skill when the user:
Check for template in standard locations:
# Project-specific template
test -f thoughts/shared/pr_description.md && echo "Found"
# Alternative locations
test -f .github/pull_request_template.md && echo "Found"
test -f docs/pr_template.md && echo "Found"
If no template exists, offer to use a standard format or create one.
Check current branch for associated PR:
gh pr view --json url,number,title,state 2>/dev/null
If no PR exists, offer to describe changes for a new PR or list open PRs.
Collect all PR context:
# Full diff of changes
gh pr diff {number}
# Commit history
gh pr view {number} --json commits
# Metadata
gh pr view {number} --json url,title,number,state
For new PRs (not yet created):
git diff main...HEAD
git log main..HEAD --oneline
git diff --name-only main...HEAD
Deep analysis required - Think carefully about:
Process checklist items from template:
npm test, make build, etc.Fill out each section from the template:
## Summary
[2-3 sentence overview of what this PR does and why]
## Problem
[What problem does this solve? Why is it needed?]
## Solution
[How does this PR solve the problem? Technical approach]
## Changes
- [Key change 1]
- [Key change 2]
## Breaking Changes
[List any breaking changes, or "None"]
## How to Verify It
### Automated Checks
- [x] Tests pass: `npm test`
- [x] Build succeeds: `npm run build`
- [ ] Manual: UI verification required
### Manual Testing
1. [Specific step to verify feature]
2. [Another verification step]
## Changelog Entry
`Added: [concise description for changelog]`
Save the description:
mkdir -p thoughts/shared/prs/
# Write to thoughts/shared/prs/{number}_description.md
Apply to PR:
gh pr edit {number} --body-file thoughts/shared/prs/{number}_description.md
Good:
Adds Redis-based rate limiting to all API endpoints to prevent abuse.
Implements sliding window algorithm with configurable limits per user tier.
Bad (too vague):
Updates the API stuff to make it better.
Good:
Problem: Users reported inconsistent rate limiting across multiple API servers.
Solution: Migrated from in-memory to Redis-backed rate limiting to ensure
consistent limits across all instances in the cluster.
Always explicitly call out breaking changes:
## Breaking Changes
The `/auth/login` endpoint now requires the `client_id` parameter.
Existing API clients must be updated to include this field.
Automated checks (you can verify):
- [x] Unit tests pass: `npm test` (42 tests, 0 failures)
- [x] Build succeeds: `npm run build`
- [ ] Linting has warnings: `npm run lint` (3 warnings - non-blocking)
Manual checks (require human verification):
- [ ] Login form displays correctly in Chrome, Firefox, Safari
- [ ] Error messages are clear and user-friendly
## Summary
Adds social authentication (Google, GitHub) to user login flow.
## Problem
Users requested faster login without creating new accounts.
## Solution
Implements OAuth 2.0 integration with Google and GitHub.
## How to Verify
- [x] Tests pass: `npm test`
- [ ] Manual: Test Google login flow in browser
## Summary
Fixes race condition causing duplicate webhook deliveries.
## Problem
Under high load, webhooks were occasionally delivered twice.
## Solution
Added distributed lock using Redis to ensure only one worker processes each event.
gh) for consistency