---
name: vrew-create-pr
description: Create a pull request on v6x/vrew from the current feature branch using the GitHub MCP. Use when the user asks to open/create a Vrew PR. Takes the main reviewer and review timing (both required), plus optional sub reviewer / label as args. Covers pulling+rebasing onto the base branch before pushing, pushing to the origin remote (personal fork), and the PR body template rules.
argument-hint: "<main-reviewer> <review-timing> [sub-reviewer] [label]"
---

# Create a Vrew PR

## Scope guard

This skill is only for Vrew and its worktrees. Before applying it, confirm the current repository appears to be Vrew by checking repository context such as path, git remote, package metadata, or known Vrew files. If it is not clearly Vrew, stop and say this skill is repo-specific.

## Arguments
Invoked as `/vrew-create-pr <main-reviewer> <review-timing> [sub-reviewer] [label]`:
- **main-reviewer** (required, first arg) — GitHub login. Registered as a formal review request (gets the review-request notification).
- **review-timing** (required) — Desired review timing. Fill the PR body's "리뷰 희망 시점" line exactly with this value. If it is missing from the args, ask the user before creating the PR.
- **sub-reviewer** (optional) — GitHub login. **Only @mentioned in the body, NOT added as a reviewer** (no review-request notification sent).
- **label** (optional) — e.g. `team-review`.

Distinguishing the two optional trailing args: resolve each against the v6x/vrew collaborator list (step 3) — the value that matches a collaborator login is the **sub-reviewer**; the value that doesn't (e.g. `team-review`) is the **label**. If ambiguous, ask. (You may also pass them explicitly as `sub:<login>` / `label:<name>`.) If no label is given, skip the label in step 5.

## Context (normal fork PR)
- Upstream repo: **v6x/vrew**. Base branch is usually **`develop`**.
- Remotes: `origin` = personal fork (e.g. `jongwonlee-nemo/vrew`), `vx` = `v6x/vrew`.
- **The GitHub MCP token is now a classic token, so it can access the personal fork.**
- Therefore: **push the branch to `origin` and open a cross-fork PR** against v6x/vrew. Do not push feature branches to `vx` unless the user explicitly asks.

## Steps

### 1. Confirm branch & commits
- Feature branch named `feature/VREW-XXXXX`, work committed.
- `git status -sb` and `git log --oneline -5` to confirm.

### 2. Update the base branch, rebase onto it, THEN push  ← always before pushing
- You are in a feature worktree. **`develop` is always checked out at `/Users/ejong/Workspace/vrew`** (a sibling worktree), so you CANNOT `git checkout develop` here. Update develop there, then rebase here:
```
git -C /Users/ejong/Workspace/vrew pull vx develop   # update develop in the worktree that holds it
git rebase develop                                    # in the current feature worktree
git push origin feature/VREW-XXXXX
```
- Resolve conflicts during the rebase (`git rebase --continue`).
- If the rebase rewrote history on a branch that was already pushed, a plain push will be rejected. **Do NOT force-push on your own — stop and tell the user, let them decide.**
- Network git ops (pull/push) may need the Bash sandbox disabled.

### 3. Resolve reviewer login(s)
- `mcp__github__list_repository_collaborators` (owner=v6x, repo=vrew, perPage=100) → substring-match the main reviewer (and sub reviewer if given) to real collaborator logins. A formal reviewer must be a collaborator. (Global `search_users` is useless — too many hits.) Also use this list to tell an optional sub-reviewer arg from a label arg.

### 4. Create the PR
- `mcp__github__create_pull_request`:
  - owner=`v6x`, repo=`vrew`
  - head=`<origin-owner>:feature/VREW-XXXXX` (derive `<origin-owner>` from the `origin` remote; e.g. `jongwonlee-nemo:feature/VREW-XXXXX`)
  - base=`develop`
  - title=`(VREW-XXXXX) <short title>`
  - **reviewers=`["<main-reviewer>"]`** — main reviewer ONLY. Never put the sub reviewer here.
  - body: see rules below

### 5. Set assignee (+ label if given)
- `mcp__github__issue_write` (method=`update`, owner=v6x, repo=vrew, issue_number=`<PR#>`, assignees=`["<author login>"]`, and `labels=["<label arg>"]` only if a label was provided).
- Note: `update_pull_request` has NO label/assignee fields — use `issue_write` for those. Reviewers are handled by `create_pull_request` / `update_pull_request`.

### 6. Verify
- `mcp__github__pull_request_read` (method=`get`) → confirm `requested_reviewers` (main only), `labels`, `assignees`, and head/base.

## PR body rules
- **Summary is ONE short line** — it becomes the CI/CD commit message.
- Any extra explanation goes **after** the 3 template bullets (메인 리뷰어 / 리뷰 희망 시점 / 서브 리뷰어), on the line below them.
- **Do NOT put Jira links or keys in the body.** An automated tool inserts `## [VREW-XXXXX(JIRA LINK)](...)` at the top from the branch name; a manual one causes parse errors / duplication.
- The template's HTML `<details>` guidance block can be omitted.
- The **sub reviewer** appears ONLY as an @mention on the 서브 리뷰어 line — never as a formal reviewer.
- **Always keep all 3 bullet lines, even when a value is missing.** If there's no sub reviewer, leave the 서브 리뷰어(opt.) line's value empty — do NOT delete the line itself.
- If generated artifacts exist, add a `## Appendix` section to the PR body and list or link them there.

Body template:
```
## Summary
<one-line summary in Korean>

- 메인 리뷰어: @<main-reviewer>
- 리뷰 희망 시점: <review-timing>
- 서브 리뷰어(opt.): @<sub-reviewer>     ← if no sub reviewer, leave this value blank but keep the line

<optional extra explanation in Korean>

<optional ## Appendix section for generated artifacts>
```