|
| 1 | +--- |
| 2 | +name: create-pr |
| 3 | +description: Create a pull request with Conventional Commits formatting, a templated body, and local verification. Use when the user asks to create a PR, open a PR, submit changes for review, or put code up for review. |
| 4 | +--- |
| 5 | + |
| 6 | +# Create Pull Request |
| 7 | + |
| 8 | +Create a PR with proper conventions: local verification, Conventional Commits title, a templated body, and an optional linked ticket. This skill is language- and framework-agnostic — substitute your project's actual build, lint, test, and format commands where examples are shown. |
| 9 | + |
| 10 | +## Prerequisites |
| 11 | + |
| 12 | +Before starting, verify: |
| 13 | +1. Current branch has commits not on the base branch (`git log origin/<base-branch>..HEAD --oneline`) |
| 14 | +2. Branch is pushed to remote (`git push -u origin HEAD` if not) |
| 15 | +3. No uncommitted changes that should be included (`git status`) |
| 16 | + |
| 17 | +## Workflow |
| 18 | + |
| 19 | +### 1. Understand the Changes |
| 20 | + |
| 21 | +Run in parallel: |
| 22 | +```bash |
| 23 | +git log origin/<base-branch>..HEAD --oneline |
| 24 | +git diff origin/<base-branch>..HEAD --stat |
| 25 | +``` |
| 26 | + |
| 27 | +Determine: |
| 28 | +- **What changed**: Which modules, packages, services, or directories were modified |
| 29 | +- **Change type**: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `perf`, `ci`, `build`, `revert` |
| 30 | +- **Scope**: Primary module/package/service affected (use directory name or `monorepo` / `repo` for cross-cutting changes) |
| 31 | +- **Is this a code change?**: If the PR modifies source code (not only docs, markdown, or config-only changes), run the local verification checklist in step 2 before creating the PR. |
| 32 | + |
| 33 | +### 2. Local Verification (for code changes) |
| 34 | + |
| 35 | +**Skip this step** if the PR only touches documentation, markdown files, or other non-code files. For any change that touches source files, run your project's verification commands locally before creating the PR. |
| 36 | + |
| 37 | +Discover the commands by reading the repo root (e.g. `Makefile`, `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `build.gradle`, `mix.exs`, `Gemfile`, `composer.json`, `justfile`, `Taskfile.yml`, `README.md`, or the CI workflow config). Use filter/target flags where available (e.g. `turbo --filter`, `nx --projects`, `pnpm --filter`, `bazel //path/...`, `cargo -p <crate>`, `pytest <path>`, `go test ./<pkg>/...`) to run only the affected portions — it is faster than running the whole repo. |
| 38 | + |
| 39 | +Common verification categories to run when applicable: |
| 40 | + |
| 41 | +#### Typecheck / Compile |
| 42 | +Run the project's static type check or compile step if it has one. |
| 43 | + |
| 44 | +Examples across ecosystems (use whatever the repo defines): |
| 45 | +- TypeScript: `npm run typecheck`, `pnpm -r typecheck`, `tsc --noEmit` |
| 46 | +- Python (typed): `mypy .`, `pyright`, `ty check` |
| 47 | +- Rust: `cargo check` |
| 48 | +- Go: `go build ./...`, `go vet ./...` |
| 49 | +- Java/Kotlin: `./gradlew compileJava`, `./mvnw compile` |
| 50 | + |
| 51 | +#### Lint / Format |
| 52 | +Run the project's linter and formatter. Prefer an autofix target if one exists. |
| 53 | + |
| 54 | +Examples: |
| 55 | +- JS/TS: `npm run fix`, `npm run lint`, `eslint .`, `prettier --check .` |
| 56 | +- Python: `ruff check --fix .`, `ruff format .`, `black .`, `flake8` |
| 57 | +- Rust: `cargo clippy --all-targets`, `cargo fmt --check` |
| 58 | +- Go: `golangci-lint run`, `gofmt -l .` |
| 59 | +- Shell: `shellcheck`, `shfmt -d .` |
| 60 | + |
| 61 | +#### Tests |
| 62 | +Run the unit/integration tests for affected packages. |
| 63 | + |
| 64 | +Examples: |
| 65 | +- JS/TS: `npm run test -- --filter=<workspace>`, `pnpm -r test`, `vitest run <path>`, `jest <path>` |
| 66 | +- Python: `pytest <path>`, `tox -e <env>`, `python -m unittest` |
| 67 | +- Rust: `cargo test -p <crate>` |
| 68 | +- Go: `go test ./<pkg>/...` |
| 69 | +- Java/Kotlin: `./gradlew test`, `./mvnw test` |
| 70 | +- Ruby: `bundle exec rspec <path>`, `rake test` |
| 71 | + |
| 72 | +#### Additional checks (run when relevant) |
| 73 | +- **Unused exports / dead code**: Run your project's dead-code check if it has one (e.g. `knip`, `ts-prune`, `vulture` for Python, `deadcode` / `unused` for Go, `cargo udeps` for Rust). |
| 74 | +- **Dependency hygiene**: Run your project's dependency check if it has one (e.g. `depcheck`, `pip check`, `cargo audit`, `bundle audit`). |
| 75 | +- **Lockfile in sync**: If you modified any dependency manifest (`package.json`, `requirements.txt`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `Gemfile`, etc.), run the install command (`npm install`, `pnpm install`, `uv sync`, `poetry lock --no-update`, `cargo update -w`, `go mod tidy`, `bundle install`) and commit any lockfile changes. CI commonly fails if the lockfile is out of date. |
| 76 | +- **Generated code / codegen**: If the repo has an OpenAPI spec, protobuf, GraphQL schema, SQL migrations, or any other generated artifacts, regenerate and commit any changes. |
| 77 | +- **Style / asset linters**: Run stylesheet linters (`stylelint`, etc.) or asset linters if you changed those files. |
| 78 | +- **Security scans**: Run any security/secret scanners configured in the repo (`trivy`, `semgrep`, `gitleaks`, etc.). |
| 79 | + |
| 80 | +### 3. Link to a Ticket (optional) |
| 81 | + |
| 82 | +If your org uses an issue tracker, ask the user whether to: |
| 83 | +- **Create a new ticket**: Use the appropriate tool (Linear, Jira, GitHub Issues, etc.) |
| 84 | +- **Link an existing ticket**: Ask for the identifier (e.g. `TEAM-1234`, `JIRA-567`, `#42`) |
| 85 | +- **Skip**: Only if user explicitly says no ticket is needed |
| 86 | + |
| 87 | +Most CI systems can be configured to require the ticket identifier in the PR body. Follow your org's convention. |
| 88 | + |
| 89 | +### 4. Format PR Title |
| 90 | + |
| 91 | +Follow Conventional Commits: `type(scope): description` |
| 92 | + |
| 93 | +- `type`: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `perf`, `ci`, `build`, `revert` |
| 94 | +- `scope`: Name of the affected module/package/service/directory, or `monorepo` / `repo` for cross-cutting changes. Multiple scopes can be comma-separated: `fix(a, b, c): ...` |
| 95 | + |
| 96 | +Examples: |
| 97 | +- `feat(web): add dark mode toggle` |
| 98 | +- `fix(cli, daemon): load shell env at entrypoint` |
| 99 | +- `fix(api): handle nil response from upstream` |
| 100 | +- `chore(repo): bump dependencies` |
| 101 | + |
| 102 | +### 5. Generate PR Body |
| 103 | + |
| 104 | +Fill in all sections from your PR template. A typical template has four sections: |
| 105 | + |
| 106 | +```markdown |
| 107 | +## Description |
| 108 | + |
| 109 | +<concise summary of what changed and why> |
| 110 | + |
| 111 | +## Related Issue |
| 112 | + |
| 113 | +Closes TEAM-XXXX |
| 114 | +<!-- or: Part of TEAM-XXXX --> |
| 115 | + |
| 116 | +## Potential Risk & Impact |
| 117 | + |
| 118 | +<list risks, performance implications, technical debt> |
| 119 | +<!-- Use "N/A" only if truly no risk --> |
| 120 | + |
| 121 | +## How Has This Been Tested? |
| 122 | + |
| 123 | +<describe testing performed: unit tests, manual testing, typecheck, lint> |
| 124 | +``` |
| 125 | + |
| 126 | +### 6. Create the PR |
| 127 | + |
| 128 | +```bash |
| 129 | +gh pr create \ |
| 130 | + --base <base-branch> \ |
| 131 | + --head <branch-name> \ |
| 132 | + --title "<type>(<scope>): <description>" \ |
| 133 | + --body "<generated body>" |
| 134 | +``` |
| 135 | + |
| 136 | +If the body is long, write it to a temp file and use `--body-file`: |
| 137 | +```bash |
| 138 | +gh pr create --base <base-branch> --head <branch> --title "..." --body-file /tmp/pr-body.md |
| 139 | +``` |
| 140 | + |
| 141 | +### 7. Report Result |
| 142 | + |
| 143 | +Return the PR URL to the user. |
| 144 | + |
| 145 | +## CI Checks Reference (template) |
| 146 | + |
| 147 | +These are typical check categories that run on every PR. Map them to your repo's actual commands when adapting this skill. |
| 148 | + |
| 149 | +### Always-run checks |
| 150 | +| Category | What it does | How to find the local command | |
| 151 | +|---|---|---| |
| 152 | +| **Typecheck / compile** | Verifies the project compiles or passes static types | Check `package.json`, `Makefile`, `pyproject.toml`, `Cargo.toml`, `go.mod`, CI config | |
| 153 | +| **Lint** | Enforces code style / correctness rules | Check for `lint`, `check`, or equivalent scripts in the repo root | |
| 154 | +| **Format** | Enforces consistent formatting | Check for `format`, `fmt`, `prettier`, `black`, `gofmt`, `rustfmt`, etc. | |
| 155 | +| **Tests** | Runs unit and integration tests | Check for `test` script / target | |
| 156 | +| **Dead code / unused exports** | Flags unused code | Check for `knip`, `ts-prune`, `vulture`, `cargo udeps`, etc. | |
| 157 | +| **Dependency check** | Flags unused / vulnerable dependencies | Check for `depcheck`, `audit`, `cargo audit`, etc. | |
| 158 | +| **Lockfile in sync** | Fails if lockfile is stale relative to the manifest | Run your package manager's install command and commit the lockfile | |
| 159 | +| **PR Conventions** | Validates branch name, semantic title, ticket presence | Follow the formatting rules above | |
| 160 | + |
| 161 | +### Conditional checks (run only when affected files change) |
| 162 | +- **API / schema validation**: Triggered by API or schema changes. Regenerate locally. |
| 163 | +- **Platform-specific builds**: Triggered when desktop/mobile/embedded targets are affected. |
| 164 | +- **E2E tests**: Triggered when the consumer app or top-level binary is affected. |
| 165 | + |
| 166 | +### Typical PR conventions CI enforces |
| 167 | +- **Branch name**: Max length, allowed characters (e.g. `[A-Za-z0-9/-]`). |
| 168 | +- **Title**: Conventional Commits format with a valid scope. |
| 169 | +- **Ticket reference**: PR body must contain a ticket identifier (often skipped for `chore:` and `revert:` types). |
| 170 | + |
| 171 | +## Common Mistakes to Avoid |
| 172 | + |
| 173 | +- **Wrong base branch**: Use the branch your org takes PRs into (e.g. `dev`, `main`, `develop`, `trunk`). |
| 174 | +- **Missing scope**: PR title CI check often requires a valid scope. |
| 175 | +- **Missing ticket reference**: Description must reference your ticket ID for CI to pass (except `chore:`/`revert:`). |
| 176 | +- **Forgetting to push**: Branch must be on remote before `gh pr create`. |
| 177 | +- **Lockfile drift**: Always run the install command and commit lockfile changes after dependency changes. |
| 178 | +- **Skipping local checks on code PRs**: Typecheck/compile, lint, and tests should be run locally before sending out code changes to catch issues early and avoid CI round-trips. |
| 179 | +- **Uncommitted generated artifacts**: After API/schema changes, regenerate and commit. |
0 commit comments