josealvaradoo/growatt-toolbar/create-pull-request

Name: create-pull-request
Author: josealvaradoo

Claude Code and agent skill by josealvaradoo/growatt-toolbar

Trust tier 3

community

By josealvaradoo
Coding
josealvaradoo/growatt-toolbar
docs/skills/create-pull-request/SKILL.md
Updated 18 Oct 2026
Version 1.0.01 version recorded

Source check pending

Checking that the SKILL.md file is still in the repository.

Push a feature or fix branch to the remote and open a pull request on GitHub following the project's git-workflow conventions. Use when the user asks to open, create, or submit a PR, or when a feature branch with committed work is ready to be merged.

Install

npx vskill@latest install josealvaradoo/growatt-toolbar/create-pull-request

SKILL.md

The same SKILL.md was published earlier as josealvaradoo/battery-api/create-pull-request.

Create Pull Request

Push the current branch to the remote and open a GitHub pull request using gh or the GitHub API. PR title, body, and base branch follow the project's git-workflow conventions.

When to use

Use this skill when:

The user asks to "open a PR", "create a pull request", "submit a PR", or "push and open PR".
A feature/* or fix/* branch has been committed locally and is ready for review.
The user wants to merge work from a feature branch into main.

Pre-flight checks

Before pushing, verify the branch is ready:

bash

git status                          # must be clean
git log main..HEAD --oneline        # must have commits ahead of main
git branch --show-current           # must be feature/<name> or fix/<name>

If working tree is dirty, ask the user to commit or stash first. If there are no commits ahead of main, there is nothing to merge.

How to use

1. Push the branch

bash

git push -u origin $(git branch --show-current)

Use -u only on the first push for this branch. Subsequent pushes can use git push.

2. Gather PR context

bash

git log main..HEAD --oneline
git diff main...HEAD --stat

Read the recent commit messages — they inform the PR title and the changelog. The diff stat shows which files changed and how much.

If a spec directory exists (e.g. specs/NNN-name/), read spec.md and tasks.md to understand the full scope. Reference it in the PR body as refs specs/NNN-name/.

3. Open the PR with `gh`

bash

gh pr create \
  --base main \
  --head $(git branch --show-current) \
  --title "<type>: <short description>" \
  --body "<PR body>"

4. PR title format

Follow the same convention as commit messages (see git-workflow skill):

English and lowercase
Prefix: feat:, fix:, refactor:, chore:, or docs:
Imperative verb, under 50 characters

Examples:

feat: add monthly profit historical data persistence
fix: prevent empty emails from being sent
refactor: split property domain into use case and types

5. PR body template

Use this structure and fill every section. Remove lines that do not apply.

markdown

## Summary
 
<1-3 bullet points describing what this PR does and why.>
 
## Changes
 
-<layer or area>: <change> (e.g. `domains: add history repository with dual-parsing flow`)
-<layer or area>: <change>
 
## Spec
 
`refs specs/NNN-name/` — link the related spec directory if one exists.
 
## Verification
 
-[ ] `bun run typecheck` passes (or `bunx tsc --noEmit`)
-[ ] `bun test` passes
-[ ] Manual smoke test via `docs/http/<resource>.http` (if applicable)
-[ ] `git-workflow` conventions followed (branch name, commit messages)
-[ ] `CHANGELOG.md` updated (if user-facing change)
 
## Notes
 
<Any breaking changes, migration steps, or follow-up work.>

6. Confirm and share

After gh pr create succeeds, report the PR URL to the user. If the user wants to set the PR as a draft, add --draft to the flags. If they want to auto-merge after CI, mention they can do that from the GitHub UI.

Examples

Example 1: Feature PR with spec

bash

# Pre-flight
git status                          # clean
git log main..HEAD --oneline        # 8 commits
git branch --show-current           # feature/monthly-profit-historical-data
 
# Push and open
git push -u origin feature/monthly-profit-historical-data
 
gh pr create \
  --base main \
  --head feature/monthly-profit-historical-data \
  --title "feat: add monthly profit historical data" \
  --body "$(cat <<'EOF'
## Summary
 
- Persist all monthly property snapshots to SQLite via Drizzle ORM.
- Expose query endpoints for historical data (all, by period, by property).
- Add dashboard upload section for .xls/.xlsx files.
- The analysis flow continues to use only the last 3 months (CSV file).
 
## Changes
 
- storage: add Drizzle schema, client, and auto-migration on startup
- domains: add history repository with dual-parsing flow
- handlers: add getAll, getByPeriod, getByProperty endpoints with auth
- ui: add dashboard upload section with htmx
 
## Spec
 
refs specs/002-monthly-profit-historical-data/
 
## Verification
 
- [x] bunx tsc --noEmit passes
- [x] bun test passes (35/35)
- [x] Manual smoke test via docs/http/history.http
- [x] git-workflow conventions followed
- [x] CHANGELOG.md updated to 0.10.0
 
## Notes
 
- Zero new dependencies in production (drizzle-orm was user-approved)
- Migrations run programmatically on server startup for fly.io compatibility
EOF
)"

Example 2: Bug fix PR

bash

gh pr create \
  --base main \
  --head fix/empty-email-prevention \
  --title "fix: prevent sending emails with empty property list" \
  --body "$(cat <<'EOF'
## Summary
 
- Validate property list before sending the email.
- Retry analysis once if the list is empty, and notify the admin.
- Fixes the empty email issue reported in #1.
 
## Spec
 
refs specs/001-empty-email-prevention/
 
## Verification
 
- [x] bunx tsc --noEmit passes
- [x] bun test passes
- [x] Manual smoke test via docs/http/properties.http
- [x] git-workflow conventions followed
- [x] CHANGELOG.md updated to 0.9.1
EOF
)"

Don't

Do not push directly to main — always use a feature or fix branch.
Do not open a PR with a vague title like "updates" or "fixes" — use the conventional commit format.
Do not skip the pre-flight checks — a clean working tree and a branch with commits ahead of main are required.
Do not open a PR without a body — reviewers need context.
Do not use git push --force unless the user explicitly asks for it.

Related skills

git-workflow — branch naming and commit message conventions
code-review — review checklist applied during PR review
planning — creates specs/NNN-name/ directories referenced in PR bodies
changelog — registers user-facing changes that PRs typically introduce

Security

Security scanPassed, 90 of 100Pattern checks on the skill's files.
Model reviewPassed

See the full security report

Quality evaluation

Task evaluationNot runNo evaluation yet. Run one in Skill Studio.

See evaluation results

Source

SKILL.md in the repositoryCheckingdocs/skills/create-pull-request/SKILL.md

Popularity

7-day trend score: 0

Not refreshed yet.

Works with

Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.

Claude Code
Cursor
GitHub Copilot
Windsurf
Codex
Gemini CLI
Cline
Amp
Roo Code
Goose
Continue
Kilo Code
Junie
Trae
OpenHands
Qwen Code
AI Agent
Tabnine Chat
Sourcegraph Cody
Amazon Q
Firebase Genkit
Sweep
Devin
Phind
Mentat
Claude Desktop
Aider
GPT Pilot
Plandex
bolt.new
v0
Replit Agent
Anse
TypingMind
BetterChatGPT
LibreChat
Warp AI
Pieces
Fig AI

Embed badge

[![vskill VERIFIED](https://verified-skill.com/api/v1/skills/josealvaradoo/growatt-toolbar/create-pull-request/badge)](https://verified-skill.com/skills/josealvaradoo/growatt-toolbar/create-pull-request)

Something wrong with this skill or its page? Tell us.

Install

SKILL.md

Create Pull Request

When to use

Pre-flight checks

How to use

1. Push the branch

2. Gather PR context

3. Open the PR with gh

4. PR title format

5. PR body template

6. Confirm and share

Examples

Example 1: Feature PR with spec

Example 2: Bug fix PR

Don't

Related skills

Security

Quality evaluation

Source

Popularity

Works with

3. Open the PR with `gh`