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-marketplaceThis skill is limited to using the following tools:
```
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
[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.