Adrienenjalbert/github-pr-workflow
nextjs-app/ai-src/skills/github-pr-workflow/SKILL.md
Use only when the user explicitly asks to create/open a GitHub pull request after a finished feature, or explicitly invokes this skill. Handles final verification, git status review, commit/push, and pull request creation with the GitHub CLI (`gh`).
tools
Updated Apr 21, 2026
$ install --global
skillsauthnpx skillsauth add Adrienenjalbert/flex-carrer-hub github-pr-workflowInstall 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 22, 2026, 2:59 AM41.7s1 file scanned
SKILL.md
- name:
- github-pr-workflow
- description:
- Use only when the user explicitly asks to create/open a GitHub pull request after a finished feature, or explicitly invokes this skill. Handles final verification, git status review, commit/push, and pull request creation with the GitHub CLI (`gh`).
GitHub PR Workflow
Strict Trigger Rule
Use this skill only if at least one is true:
- the user explicitly asks to create/open/make a pull request
- the user explicitly says to use this skill
- the user explicitly says the feature is finished and wants it pushed as a PR
Do not use this skill automatically just because code changes exist.
Goal
Publish a finished feature to GitHub with a clean PR workflow using:
gitgh
Remote currently expected in this repo:
origin [email protected]:Adrienenjalbert/flex-carrer-hub.git
Reviewability Priorities
Optimize for a reviewer who is checking AI-generated PRs and wants:
- one feature per PR
- minimal change scope
- easy-to-understand PR summaries
- as few review corrections as possible
These priorities override convenience.
Branch And PR Scope Rules
One Feature Per PR
Mandatory rule:
- never combine multiple features in one PR
If the branch contains unrelated work, do not create the PR until scope is reduced or the user explicitly decides otherwise.
Base Branch Rule
Default base branch:
main
Exception:
- if the current feature explicitly depends on another unfinished feature branch, and this feature directly derives from that branch, create the PR against that feature branch instead
Do not guess this dependency. Use a non-main base only when:
- the user explicitly says so, or
- the branch relationship is explicit and necessary for stacked feature delivery
Minimal Diff Rule
The PR should contain only the files needed for the finished feature.
Do not include:
- opportunistic refactors
- unrelated cleanup
- formatting-only churn outside touched files
- separate features bundled for convenience
Preconditions
Before creating a PR, confirm all are true:
- the requested feature/change is finished
- the user asked for PR creation explicitly
- local changes are reviewed
- appropriate verification has run, or skipped status is clearly stated
- PR scope is limited to one feature
Required Sequence
1. Review Working Tree
Check:
git status --shortgit diff --statgit difffor changed files if needed
Goal:
- confirm only intended changes are included
- identify unrelated dirty files before committing
- verify the diff represents one feature only
2. Verify Changes
Use verification-checklist logic.
Default checks for code changes:
pnpm checkpnpm typecheckpnpm build
Also run when relevant:
pnpm smokepnpm seo:audit
If checks are skipped or failing, say so explicitly before PR creation.
3. Review Branch State
Check:
- current branch name
- whether branch already has an upstream
- what the correct PR base branch should be
Useful commands:
git branch --show-currentgit status -sbgit rev-parse --abbrev-ref --symbolic-full-name @{upstream}when useful
4. Commit Intentionally
Stage only intended files.
Use:
git add <paths>git commit -m "<type>: <summary>"
Commit rules:
- keep the message specific to the finished feature
- do not amend old commits unless the user explicitly asks
- do not include unrelated changes
5. Push Branch
Use:
git push -u origin <branch>if upstream is missing- otherwise
git push
6. Create Pull Request With gh
Preferred flow:
gh pr create --fill --base <base-branch> --head <branch>
If --fill is weak, provide explicit title/body:
gh pr create --base <base-branch> --head <branch> --title "<title>" --body "<body>"
Base branch rule:
- use
mainby default - use another feature branch only for explicit stacked feature work
PR Body Standard
Keep the PR body practical and short.
Include:
- the single feature delivered
- what changed
- why it changed
- verification run
- notable risks or follow-ups
Also include, when useful:
- explicit statement that the PR is intentionally limited to one feature
- explicit base branch choice if not
main
Suggested structure:
## Summary
- ...
## Verification
- `pnpm check`
- `pnpm typecheck`
- `pnpm build`
## Notes
- ...
Safety Rules
- Do not create a PR without explicit user intent.
- Do not combine multiple features in one PR.
- Do not target a non-
mainbase branch unless explicitly required by stacked feature work or the user says so. - Do not commit unrelated dirty files.
- Do not use
git add .blindly in a dirty tree. - Do not force-push unless the user explicitly asks.
- Do not amend or rewrite history unless the user explicitly asks.
Reviewer-Friendly PR Rules
- Prefer the smallest reviewable diff that completes the feature.
- Prefer explicit titles over clever titles.
- Prefer a short, factual PR body over long prose.
- Mention any intentionally excluded follow-up work so the reviewer knows the scope is controlled.
- If scope drift is detected, stop and split the work rather than bundling it.
Output Standard
When done, report:
- branch name
- base branch
- commit created
- checks run
- PR URL
- confirmation that the PR contains one feature only
If blocked, report the exact blocker:
ghauth missing- push failed
- checks failed
- working tree contains unrelated changes needing user direction
- branch contains multiple features and should be split before PR creation
Related Skills
Adrienenjalbert/verification-checklist
development
VerifiedTrustedCommunity
Use when finishing a code change, validating generated code, or deciding which repo checks must run before presenting work in this repo.
SKILL.mdUpdated Apr 21, 2026
Adrienenjalbert/tool-page-builder
tools
VerifiedTrustedCommunity
Use when creating or editing Career Hub tool pages, calculator pages, tool metadata, tool registry entries, or tool-specific support sections in this repo.
SKILL.mdUpdated Apr 21, 2026
Adrienenjalbert/seo-page-rules
data-ai
VerifiedTrustedCommunity
Use when editing public pages, metadata, canonical URLs, structured data, sitemaps, robots rules, or any SEO-sensitive behavior in this repo.
SKILL.mdUpdated Apr 21, 2026
Adrienenjalbert/safe-refactor
development
VerifiedTrustedCommunity
Use when refactoring existing code, moving files, normalizing structure, or improving architecture without changing user-visible behavior in this repo.
SKILL.mdUpdated Apr 21, 2026