tobihagemann/update-pr
skills/update-pr/SKILL.md
Update an existing GitHub pull request's title and description to reflect the current state of the branch. Use when the user asks to "update the PR", "update PR description", "update PR title", "refresh PR description", or "sync PR with changes".
$ install --global
skillsauthnpx skillsauth add tobihagemann/turbo update-prInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 24, 2026, 8:49 PM1.8s1 file scanned
SKILL.md
- name:
- update-pr
- description:
- Update an existing GitHub pull request's title and description to reflect the current state of the branch. Use when the user asks to \"update the PR\", \"update PR description\", \"update PR title\", \"refresh PR description\", or \"sync PR with changes\".
Update PR Title and Description
Read the current PR title and body, analyze what changed in the session, and draft an updated title and description that preserves the original writing style.
Step 1: Fetch Current PR
Fetch the current PR details:
gh pr view [PR_NUMBER] --json number,title,body,baseRefName,headRefName,updatedAt,commits
Omit PR_NUMBER to auto-detect from current branch.
Step 2: Analyze the Existing Style
Before drafting, study the current title and body to identify:
- Title format — length, prefix conventions (e.g.,
feat:,fix:), capitalization - Body structure — headings, bullet points, sections, line length
- Tone — formal vs. casual, terse vs. detailed
- Content patterns — does it explain the "why", list changes, include test plans?
- Diagrams — does the body contain Mermaid code blocks (sequence, state, or other)?
Step 3: Evaluate Whether an Update Is Needed
Use the PR's updatedAt field and commit timestamps to determine whether new commits were added since the body was last edited.
If commits_since_body_change is empty, the description is already up to date — say so and stop.
If there are commits since the last body change, check the incremental diff to assess significance:
git diff origin/<base>...HEAD --diff-filter=d --stat -- $(git diff --name-only --since="<body_last_changed>" origin/<base>..HEAD)
Skip the update if the incremental changes are trivial (formatting, typos, config-only). Proceed if they add, remove, or modify meaningful behavior.
Step 4: Analyze the Full Diff
Derive the PR description from the full diff, not from individual commits. The description should reflect the net change — what the code looks like now vs. the base — not the development journey. Intermediate bug fixes, reverted approaches, and implementation pivots that happened during development are not relevant to the reader.
- Check
git diff origin/<base>...HEADfor the full scope of changes — this is the primary source of truth - Use the incremental diff (since last body edit) to understand what's new, but frame everything in the context of the whole PR
- Check if the changes introduce runtime flows or state transitions that warrant diagrams (see Diagrams section below)
Step 5: Draft Updated Title and Description
Run /github-voice to load writing style rules before drafting.
Write an updated title and body that:
- Matches the original style — same structure, tone, formatting, and level of detail
- Reflects the net change — describe what the full diff shows, not the development history
- Preserves what still applies — keep existing text that remains accurate
- Adds what's new — integrate new changes naturally into the existing structure
- Removes what's stale — drop descriptions of work that was reverted or replaced
- Updates diagrams — if existing Mermaid diagrams are present, update them to reflect the current state; if they describe reverted code, remove them; if new changes warrant diagrams, add them
Step 6: Confirm with User
Output the drafted title and description as text, alongside the original for comparison. Then use AskUserQuestion for confirmation.
Step 7: Apply the Update
After confirmation, update the PR:
gh pr edit <PR_NUMBER> --title "<TITLE>" --body "$(cat <<'EOF'
<BODY CONTENT HERE>
EOF
)"
Diagrams
GitHub renders Mermaid natively in PR descriptions via ```mermaid code blocks. Include diagrams only when they add clarity a text description can't.
Sequence Diagram
Include when the changes introduce or modify a clear runtime flow: API endpoints, event handlers, pipelines, multi-service interactions, webhook flows.
```mermaid
sequenceDiagram
Client->>API: POST /payments
API->>PaymentService: processPayment()
PaymentService->>StripeClient: charge()
StripeClient-->>PaymentService: confirmation
PaymentService->>DB: save()
```
State Diagram
Include when the changes add or modify entity states, status enums, workflow transitions, or lifecycle hooks.
```mermaid
stateDiagram-v2
[*] --> Draft
Draft --> Pending: submit()
Pending --> Approved: approve()
Pending --> Rejected: reject()
Approved --> [*]
```
Rules
- Keep diagrams focused — max ~10 nodes/transitions
- Use descriptive labels on arrows (method names, HTTP verbs)
- Place diagrams after the summary paragraph under a
## Flowor## State Machineheading - One diagram per type max — don't include both unless the PR truly has both patterns
Rules
- If the existing body is empty or minimal, infer a style from the title and commit messages
- Keep titles under 72 characters
- Preserve any existing sections the user clearly cares about (test plans, checklists, links)
Related Skills
tobihagemann/user-experience
development
VerifiedTrustedCommunity
Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path through it holds together, using the Understanding, Bridging, and Flowing contexts. Use when scoping, planning, or assessing any change that affects what a user sees or does. Loaded as a lens during planning and assessment.
377SKILL.mdUpdated Jun 18, 2026
tobihagemann/user-experience
development
VerifiedTrustedCommunity
Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path through it holds together, using the Understanding, Bridging, and Flowing contexts. Use when scoping, planning, or assessing any change that affects what a user sees or does. Loaded as a lens during planning and assessment.
377SKILL.mdUpdated Jun 18, 2026
tobihagemann/assess-technical-debt
development
VerifiedTrustedCommunity
Assess project-wide structural technical debt: complexity hotspots, deprecated API usage, duplication clusters, and architecture rot. Ranks findings by impact and refactor effort into a report at .turbo/technical-debt.md. Use when the user asks to "assess technical debt", "find technical debt", "review technical debt", "what should we refactor", "find refactoring candidates", "where is the code rot", or "what's our worst code". Analysis-only — does not modify code.
377SKILL.mdUpdated Jun 15, 2026
tobihagemann/simplify-docs
development
VerifiedTrustedCommunity
Run a multi-agent review of code comments and markdown documentation for unnecessary content, then fix the issues. Covers what-restating comments, name-mirroring doc comments, status-update prose, and other documentation noise. Use when the user asks to "simplify docs", "simplify documentation", "clean up comments", "clean up docs", "review documentation", "strip unnecessary comments", "reduce doc noise", or "run simplify-docs".
377SKILL.mdUpdated May 15, 2026