Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From base
Create GitHub pull requests following required project conventions. Always consult this skill when creating a PR, opening a pull request, or submitting changes for review — including "PR作って", "プルリクエスト作成", "create a PR", "make a pull request", "submit for review", "gh pr create", or any request to prepare changes for review on GitHub. Contains mandatory title format [base-branch] type: description, required --draft flag, and --assignee kkhys that differ from defaults and cannot be inferred without this skill.
npx claudepluginhub kkhys/claude-code-marketplaceHow this skill is triggered — by the user, by Claude, or both
Slash command
/base:creating-prThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
```
Creates GitHub PRs using .github/PULL_REQUEST_TEMPLATE.md: removes comments, adds 'Closes [Issue#]', assigns current user via gh CLI, bases on default branch, reports URL.
Creates GitHub pull requests with formatted descriptions, labels, issue references, draft mode, reviewers, and base branch selection from pushed branches. Use for 'create PR' or 'submit for review'.
Creates GitHub pull requests from branch changes using git analysis and gh CLI, with conventional commit titles and standardized templated descriptions including summary, changes, testing, and checklists.
Share bugs, ideas, or general feedback.
[base-branch] type: description
The base branch name goes in brackets, followed by a Conventional Commits type and a lowercase description. This format makes it immediately clear where the PR targets and what kind of change it is when scanning a PR list.
Examples:
[main] feat: add user authentication system[develop] fix: resolve null pointer in login handler[main] refactor: extract validation logicWhen changes span multiple types, select by primary purpose:
feat > fix > perf > refactor > test > docs > style > ci > build > chore
A feature branch that includes bug fixes and tests is still feat. A bug fix with some refactoring is still fix. Choose the type that captures the main intent.
Before generating a description, check if the repository has a PR template (.github/pull_request_template.md or similar standard locations). If found, use it as the body structure and fill in sections based on the actual changes. If multiple templates exist, ask the user which to use.
When no template exists, write a flat bullet-point list in English. Each bullet uses imperative mood ("Add", "Fix", "Remove", "Update") and describes one concrete change. No headings, no "Summary" / "Test plan" sections, no sub-bullets — just a plain list. Aim for 3-5 bullets that capture the meaningful changes; omit trivial ones.
Good:
- Switch image discovery from frontmatter field to directory-based auto-detection
- Consolidate getImage/getImages into getImagesForMemo
- Remove images field from content schema
Bad (too verbose, has sections):
## Summary
画像取得をフロントマターの images フィールドによる明示的なリスト指定から、ディレクトリベースの自動検出方式に変更
## Test plan
- ローカルで pnpm dev を実行し、画像付きメモが正しく表示されることを確認
Use --base <branch> to explicitly set the merge target. Determine the base branch from:
mainThe base branch name also goes into the title brackets: [develop] fix: ...
Always use these flags with gh pr create:
--draft — All PRs start as drafts. This gives the author a chance to self-review before requesting reviews.--assignee kkhys — Always assign to kkhys.Print the PR URL returned by gh pr create so the user can open it directly.