ilamanov/pr
skills/pr/SKILL.md
Commit changes and create or update a pull request following project standards. Use when the user wants to commit work, create a PR, update an existing PR, or use the /pr command.
tools
Updated May 14, 2026
$ install --global
skillsauthnpx skillsauth add ilamanov/skills 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: May 14, 2026, 2:36 AM202.6s1 file scanned
SKILL.md
- name:
- pr
- description:
- Commit changes and create or update a pull request following project standards. Use when the user wants to commit work, create a PR, update an existing PR, or use the /pr command.
- argument-hint:
- [description]
- allowed-tools:
- Bash(git:*), Bash(gh:*)
PR Workflow
Context
- User's notes: $ARGUMENTS
- Current branch: !
git branch --show-current - Git status: !
git status --short - Existing PR: !
gh pr view --json number,title,url 2>/dev/null || echo "No PR exists" - Recent commits: !
git log main..HEAD --oneline 2>/dev/null || git log -3 --oneline
Step 0: Handle merged PR branches
If not on main and a PR already exists for the current branch, check if it has been merged:
gh pr view --json state --jq '.state'
If the state is MERGED:
- Stash any uncommitted changes:
git stash --include-untracked(skip if working tree is clean) - Switch to main:
git checkout main - Pull latest:
git pull - Create a new branch with a descriptive name based on the user's notes or the staged changes
- Pop the stash if one was created:
git stash pop - Continue to Step 1 on the new branch
Step 1: Prepare the branch
- If on main, create a new branch with a descriptive name
- Check for staged changes (
git diff --cached --stat):- If there are staged changes: commit only the staged changes (do NOT
git addanything else) - If nothing is staged: stage and commit all changes (except API keys or explicitly private content)
- If there are staged changes: commit only the staged changes (do NOT
- Push changes to the remote
Step 2: Create or update the PR
If no PR exists: Create a new PR following the standards below.
If a PR already exists (and is OPEN):
-
Show the user the existing PR (number, title, URL) and ask for confirmation using AskUserQuestion:
- Update existing PR — push new commits to the current branch and update the PR title/description if needed
- Create new branch & PR — create a new branch from the current one, push there, and open a fresh PR
-
If the user chose "Update existing PR":
a. Read the existing PR:
gh pr view --json title,body,labels,number gh pr diff --statRead specific files directly rather than dumping the full diff.
b. Review whether the PR content accurately reflects the current diff:
- Does the title follow semantic format?
- Does the description accurately describe all commits?
- Is the test plan still accurate?
- Are the release notes complete?
c. Update if needed:
gh pr edit <number> --title "new title" --body "new body"d. Push any new commits (regular push, not force push)
-
If the user chose "Create new branch & PR":
a. Create a new branch from the current HEAD with a descriptive name based on the user's notes or the staged changes b. Push the new branch to the remote c. Create a new PR following the standards below
Step 3: Link related issues
Search for related issues and link them using Closes #123 or Relates to #123.
When paired with fix-pr-reviews
If the user invokes this skill together with fix-pr-reviews, finish the PR creation/update first, then immediately hand off to the review-finding workflow for the resulting PR:
- Create or update the PR and push the branch as this skill normally requires.
- Start or refresh the PR review watcher for that PR immediately, even if there are no review comments yet.
- Fetch and triage the current PR review streams once.
- Keep checking for new or changed findings through the watcher while the PR is open.
Do not wait for review findings or review fixes before creating the watcher in the combined workflow.
Handling problems
Committing automatically runs the linter. Fix any lint/type errors unless they require meaningful code changes—in that case, notify the user:
I can't create/update this PR because [reason]. Would you like me to [suggestion]?
Never force commit or force push.
PR Standards
Title format
Use semantic PR titles (Conventional Commits):
<type>(<scope>): <description>
Types
feat- New featurefix- Bug fixdocs- Documentation onlyrefactor- Code change that neither fixes a bug nor adds a featureperf- Performance improvementtest- Adding or fixing testschore- Maintenance tasks
Scope (optional)
A noun describing the affected area: fix(editor):, feat(sync):, docs(examples):
Examples
feat(editor): add snap threshold configuration optionfix(arrows): correct binding behavior with rotated shapesdocs: update sync documentation
Body template
<description paragraph>
### Change type
- [x] `bugfix` | `improvement` | `feature` | `api` | `other`
### Test plan
1. Step to test...
- [ ] Unit tests
- [ ] End to end tests
### Release notes
- Brief description of changes for users
Description paragraph
Start with: "In order to X, this PR does Y."
- Keep it specific—avoid vague phrases like "improve user experience"
- Link related issues in the first paragraph
- Don't expect readers to also read the linked issue
Change type
- Tick exactly one type with
[x] - Delete unticked items
Test plan
- List manual testing steps if applicable
- Remove the numbered list if changes cannot be manually tested
- Tick checkboxes for included test types
Release notes
- Write brief notes describing user-facing changes
- Use imperative mood: "Add...", "Fix...", "Remove..."
- Omit entirely for internal work with no user-facing impact
API changes section
Include when changes affect api-report.md:
### API changes
- Added `Editor.newMethod()` for X
- Breaking! Removed `Editor.oldMethod()`
PR readiness
- Default to opening the PR as ready for review
- Use a draft PR only when the changed area is failing verification, incomplete, blocked, or otherwise not actually ready for review
- If only unrelated or clearly flaky verification failures remain, still open the PR as ready for review and explicitly call out the residual risk in the PR body
Important
- Never include AI attribution ("Generated with Claude Code", "Co-Authored-By: Claude", etc.) in commits, PR titles, or descriptions
- Never use title case for descriptions—use sentence case
- Never put yourself as co-author of any commits
Related Skills
ilamanov/codebase-conventions
tools
VerifiedTrustedCommunity
Generally-applicable conventions for how code is written and arranged — tooling/package manager, import style, file & component naming, comments, and where files live (colocation vs. global folders). Use whenever creating, naming, moving, or importing a file, running project commands, or deciding where a new module belongs. Consult BEFORE writing the code so the conventions are baked in, not retrofitted. If a convention below matches the work, apply it — don't ask, just follow it (call out the choice in one line so the user can override).
SKILL.mdUpdated May 30, 2026
ilamanov/frontend-patterns
development
VerifiedTrustedCommunity
Generally-applicable frontend/UI best practices. Use whenever building, modifying, or reviewing UI — adding a form/button/dialog/modal, wiring keyboard shortcuts, creating any interactive surface that submits a form, or any time TSX/JSX is being written or edited. Consult BEFORE writing the code so the patterns are baked in, not retrofitted. If a scenario described in the skill body matches the work, apply the pattern — don't ask, just follow it (call out the choice in one line so the user can override).
SKILL.mdUpdated May 26, 2026
ilamanov/backend-patterns
tools
VerifiedTrustedCommunity
Generally-applicable backend/data best practices. Use whenever writing or modifying backend/data code — API routes, server actions, DB writes, background jobs, agent tools, import flows, webhooks, paste handlers, or anywhere data enters the system. Consult BEFORE writing the code so the patterns are baked in, not retrofitted. If a scenario described in the skill body matches the work, apply the pattern — don't ask, just follow it (call out the choice in one line so the user can override).
SKILL.mdUpdated May 26, 2026
ilamanov/skill-improver
development
VerifiedTrustedCommunity
Runs on a schedule to mine recent Codex and Claude Code conversations across configured projects, find moments where things went off plan (the user had to steer, correct, abort, or re-explain), and propose targeted improvements to the specific skills that were in use at the time. Opens one pull request per run against the skills repo, with each proposed edit annotated with the concrete steering moment that motivated it. Also analyzes its own runs (the `skills` repo is one of the configured projects) so it iteratively improves itself. Use this skill when the user asks to "analyze recent conversations", "find what went wrong", "improve skills based on past runs", or sets up a scheduled run of skill-improver. Make sure to use this skill whenever the user mentions recursive skill improvement, post-mortem analysis of agent conversations, or automating skill quality based on real usage.
SKILL.mdUpdated May 25, 2026