Stats
Actions
Tags
From pr-develop
Analyze the current branch and create a PR to `develop` following GitFlow conventions and Conventional Commits standard.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pr-develop:pr-developThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Analyze the current branch and create a PR to `develop` following GitFlow conventions and Conventional Commits standard. Follow these steps exactly:
Analyze the current branch and create a PR to develop following GitFlow conventions and Conventional Commits standard. Follow these steps exactly:
Version policy: PRs to
developnever touchpackage.jsonversion. Version bumps happen only onrelease/*branches, cut via the/pr-stagingskill.
GitFlow reminder: The release flow is
develop→release/vX.X.X→staging→master. Never bump version directly ondeveloporstaging.
Run git branch --show-current to get the current branch.
If the current branch is any of: develop, staging, master, main — stop immediately and tell the user:
"You are currently on
<branch>, which is a protected branch. PRs must be created from a working branch (feature/, fix/, chore/*, etc.), never directly from<branch>. Please switch to your working branch and try again."
Do not continue with any further steps.
If the current branch matches release/*, stop immediately and tell the user:
"You are on a
release/*branch. This branch is managed by/pr-staging(release → staging) and/pr-production(staging → master). Run/pr-staginginstead."
Do not continue with any further steps.
Verify the branch follows GitFlow naming:
feature/<ticket-or-description> → new featurefix/<ticket-or-description> or bugfix/<ticket-or-description> → bug fixhotfix/<ticket-or-description> → urgent production fixchore/<ticket-or-description> → maintenance, deps, configrefactor/<ticket-or-description> → code refactor without behavior changedocs/<ticket-or-description> → documentation onlytest/<ticket-or-description> → tests onlyIf the branch name does NOT match any of these patterns, warn the user and ask for confirmation before continuing.
The base branch for the PR is always develop, except for hotfix/* branches — see Step 6.
First, sync with the remote to ensure comparisons are accurate:
git fetch origin
Then run in parallel:
git log origin/develop..HEAD --oneline — list commits not yet in develop (uses remote, not stale local)git diff origin/develop...HEAD --stat — summary of changed filesgit diff origin/develop...HEAD — full diff (to understand what changed and why)Carefully read all diffs and commit messages to understand:
Run git status. If there are uncommitted changes:
git add -p is NOT available in non-interactive mode — instead, stage all tracked changes with git add -u and new relevant files explicitly (avoid .env, secrets, binaries)<type>(<scope>): <short imperative summary, max 72 chars>
<body — what was done and why, wrapped at 72 chars>
<footer — breaking changes, issue refs if available>
Types: feat, fix, chore, refactor, docs, test, perf, ci, build
Scope: the module, package, or domain affected (e.g., the directory name, feature area, or service that changed)
Rules:
- bulletsBefore committing: show the proposed commit message to the user and ask for explicit approval. Only run git commit after the user confirms.
Commit using a HEREDOC to avoid escaping issues.
Before pushing: show the user the branch name and target remote, then ask:
"Ready to push
<branch>to origin. Confirm?"
Only run git push -u origin HEAD after the user explicitly approves.
If the push fails because the remote branch has diverged (non-fast-forward), explain the situation to the user and ask whether to rebase or force-push. Never force-push without explicit user approval.
develop using gh CLIFirst check if a PR already exists for this branch:
gh pr list --head "$(git branch --show-current)" --base develop --json number,url,title
If a PR already exists, show the URL and skip creation.
Otherwise, draft the full PR (title + body) and show it to the user for approval before creating it. Ask:
"Ready to create this PR to
develop. Confirm?"
Only run gh pr create after the user explicitly approves.
The PR title must follow Conventional Commits format (same as the commit subject if there's only one commit, otherwise a summary of all commits).
PR body structure:
## Summary
<!-- 2-4 bullet points describing what this PR does -->
## Changes
<!-- Grouped by service/module. For each group: -->
### <Service or Module Name>
- <change 1>
- <change 2>
## Type of change
<!-- Check the box that matches the branch prefix: feature/* → New feature, fix/bugfix/* → Bug fix, hotfix/* → Hotfix, refactor/* → Refactor, chore/* → Chore, docs/* → Documentation, test/* → Tests -->
- [ ] New feature
- [ ] Bug fix
- [ ] Hotfix
- [ ] Refactor
- [ ] Chore / maintenance
- [ ] Documentation
- [ ] Tests
## Database migrations
<!-- YES/NO. If yes, list the migration files -->
## Breaking changes
<!-- YES/NO. If yes, describe impact and migration path -->
## Testing
<!-- Briefly describe how changes were tested or how to test manually -->
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Fill every section based on your analysis of the diff. Do not leave placeholder text — write real content.
For "Type of change", mark the correct checkbox with [x] based on the branch prefix (e.g., feature/* → New feature, fix/* or bugfix/* → Bug fix, hotfix/* → Hotfix, refactor/* → Refactor, chore/* → Chore, docs/* → Documentation, test/* → Tests).
Run:
gh pr create --base develop --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"
After creation, run gh pr view --json url,title,number to get the PR details.
master AND developIf the current branch is hotfix/*, GitFlow requires merging to both master and develop — and master comes first because the goal is to fix production urgently. Hotfixes bypass staging entirely to avoid deploying unvalidated features.
After the PR to develop is created (Step 5), also create a PR to master:
"This is a hotfix. In GitFlow, hotfixes must be merged to
masterfirst (to fix production immediately) and then back-merged todevelop. Do you want me to create the PR tomasternow?"
If the user confirms, run:
gh pr create --base master --title "<same-title>" --body "$(cat <<'EOF'
<same-body>
EOF
)"
After both PRs are created, remind the user:
⚠️ Merge the
masterPR first to fix production. Then merge thedevelopPR to back-merge the fix. Once merged tomaster, tag the hotfix release:git tag -a v<hotfix-version> -m "Hotfix v<hotfix-version>" git push origin v<hotfix-version>
After the PR is created (or already existed), output:
gh pr view).env files, secrets, credentials, or binary blobsdevelop unless the branch is hotfix/* (which also targets master — see Step 6)gh CLI for all GitHub operations (PR creation, listing, viewing). Never construct GitHub URLs manually.gh CLI is not authenticated, tell the user to run ! gh auth login in the promptProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub lety-ai/lety-skill-hub --plugin pr-develop