otomatty/create-pull-request

Create Pull Request

This skill uses develop as the default --base branch for Zedi. Do not use main as --base unless the user explicitly asks for a release or mainline merge PR.

Skills / .cursor/skills/ (and similar workflow-only changes): Open the PR so it merges into the branch you were on when you created the topic branch (the current integration line)—typically develop after git checkout -b from develop, or a parent feature branch if you branched from there. Never open Skills-only PRs with --base main by default.

If the current branch already contains the intended commits, reuse that branch and create or update the PR from it. When creating a new branch, obtain the branch name from the user (e.g. feature/add-login) or derive it from an issue number (e.g. 123 → feature/123). If neither is provided, ask the user.

Recording BASE_BRANCH: Right before git checkout -b <topic>, note the branch name you are leaving (e.g. PARENT=$(git branch --show-current)); use that as BASE_BRANCH for gh pr create --base. If you did not create a new branch, use develop when it is the integration branch, or the branch the user specifies.

Preflight

git status                          # current state
git branch --show-current           # develop → new branch; other → reuse if has commits
gh auth status                      # GitHub CLI authenticated

Step 1: Decide whether to reuse the current branch or create a new one

1. If current branch is develop

   • If the working tree is dirty, ask the user to commit or stash first, or create the new branch from the current state explicitly.
   • Run git pull --ff-only origin develop.
   • Determine the new branch name: from user (e.g. feature/add-login) or issue number (e.g. 123 → feature/123). If missing, ask: "ブランチ名（例: feature/add-login）またはイシュー番号（例: 123）を教えてください."
   • Before creating the topic branch, set the PR merge target: BASE_BRANCH=$(git branch --show-current) (on develop, this is develop—use this for gh pr create --base, not main).
   • Create the branch: git checkout -b <ブランチ名>.
   • If the new branch is dirty after creation, commit with an appropriate message (Conventional Commits recommended).

2. If current branch is not develop

   • If git log develop..HEAD --oneline is non-empty, keep using the current branch (reuse for PR create/update).
   • If the working tree is dirty, do not switch to develop and pull with carried-over changes; ask the user to commit or stash first, or to branch from the current state explicitly.
   • If the current branch has no commits ahead of develop, you may switch to develop after a clean state, then follow the "If current branch is develop" path.

Step 2: Investigation workflow

Run Phase 1 commands in parallel (they are independent), then Phase 2.

Phase 1: Gather context (run in parallel)

# BASE_BRANCH: branch to merge into (never default to main for Skills / routine work).
# Prefer PARENT captured before `git checkout -b`, else develop for Zedi.
BASE_BRANCH="${BASE_BRANCH:-develop}"
CURRENT=$(git branch --show-current)
echo "Branch: $CURRENT -> $BASE_BRANCH (merge target)"

# 1b. Commit list (chronological)
git log ${BASE_BRANCH}..HEAD --format="%h %s" --reverse

# 1c. Changed files summary
git diff ${BASE_BRANCH}..HEAD --stat

# 1d. Changes grouped by directory
git diff ${BASE_BRANCH}..HEAD --dirstat=files,0

# 1e. Commit type breakdown (Conventional Commits)
git log ${BASE_BRANCH}..HEAD --format="%s" | grep -oP '^\w+(\(\w+\))?' | sort | uniq -c | sort -rn

# 1f. Related issue numbers
git log ${BASE_BRANCH}..HEAD --format="%s" | grep -oP '#\d+' | sort -u

# 1g. Check for existing PR
gh pr list --base ${BASE_BRANCH} --head ${CURRENT} --state all --json number,title,state

# 1h. Recent PRs for style reference
git log ${BASE_BRANCH} --oneline -5

Phase 2: Detect breaking changes and review points

# 2a. DB migrations
git diff ${BASE_BRANCH}..HEAD --name-only -- '*.sql' '**/drizzle/**' '**/migrations/**'

# 2b. Environment variable changes
git diff ${BASE_BRANCH}..HEAD -- '*.env.example' '*.env.sample'

# 2c. Package dependency changes
git diff ${BASE_BRANCH}..HEAD -- '**/package.json' '**/bun.lockb' '**/pnpm-lock.yaml'

# 2d. Schema / type changes
git diff ${BASE_BRANCH}..HEAD -- '**/schema/**' '**/*.d.ts'

# 2e. API route changes
git diff ${BASE_BRANCH}..HEAD --name-only -- '**/routes/**' '**/api/**'

# 2f. CI / workflow changes
git diff ${BASE_BRANCH}..HEAD --name-only -- '.github/**'

# 2g. Terraform / infra changes
git diff ${BASE_BRANCH}..HEAD --name-only -- '**/terraform/**'

Phase 3: Read the PR template

cat .github/PULL_REQUEST_TEMPLATE.md

Always use the project's PR template as the output format.

Step 3: Pre-push checks

Run before pushing:

bun run lint
bun run format:check
bun run test:run

If any command fails, fix the issues and amend or add a commit, then re-run until all pass.

Step 4: PR description assembly

Using the investigation results, fill in the PR template. Follow these rules:

概要 (Summary)

• 1-3 sentences explaining what changed and why.
• Mention the feature/fix name clearly.

変更点 (Changes)

• Group changes by area (e.g., admin/, server/api/, terraform/).（ローカル専用の docs/ はコミットに含まれないため PR の変更一覧には通常出ない）
• Each group: 1-line heading + bullet list of key changes.
• For large PRs (>30 files), use a table format:

| 領域          | 主な変更                             |
| ------------- | ------------------------------------ |
| `admin/`      | 管理画面UI、認証ガード、AIモデル管理 |
| `server/api/` | admin用ミドルウェア、ロール追加      |

変更の種類 (Change type)

• Check the boxes based on commit type breakdown from Phase 1-1e.

テスト方法 (Test plan)

• Provide concrete steps a reviewer can follow to verify the changes.
• Include setup steps if migrations or new env vars are required.

チェックリスト (Checklist)

• Confirm lint/format/test were run in Step 3 and note that in the checklist.

スクリーンショット

• If UI changes exist (files in admin/src/pages/, src/components/, etc.), note that screenshots should be added.

関連 Issue

• Use Closes #NNN for each related issue found in Phase 1-1f.
• Use Related to #NNN for issues that are referenced but not fully resolved.

Step 5: Push and create or update the PR

New PR

git push -u origin HEAD

gh pr create \
  --base "${BASE_BRANCH}" \
  --title "PR title here" \
  --body "$(cat <<'EOF'
<assembled PR body here>
EOF
)"

Existing PR (update description only)

If Phase 1-1g found an existing PR for the current branch, update its body instead of creating a new branch and PR:

gh pr edit <NUMBER> --body "$(cat <<'EOF'
<assembled PR body here>
EOF
)"

Title convention

Derive the PR title from commit messages:

• Single-topic PR: use the main commit message as-is.
• Multi-topic PR: write a summary title covering all areas.
• Follow Conventional Commits if all commits use it.
• Write in the same language as the majority of commit messages (Japanese or English).

Decision points

| Situation | Action | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Not on develop (has commits) | Reuse current branch; create or update PR from it | | On develop | Pull, create new branch (get name from user), then create or update PR | | Branch name / issue missing | Ask user for branch name or issue number | | Working tree dirty on branch | Commit on the new branch before investigation | | Existing PR found | Update that PR's body instead of creating a new PR | | Base branch not specified | Default to develop; never main unless user asks for release PR. For stacked work, use parent branch captured before git checkout -b | | PR is very large (>50 files) | Suggest splitting, but proceed if user confirms | | Lint/format/test fail | Fix, commit, then re-run Step 3 before pushing |

Response format

After creating or updating the PR, return:

1. PR URL
2. Summary of what was included (branch name, main changes)
3. Any items that need manual attention (screenshots, env vars to set, migrations to run)