/pr-to-main

name: pr-to-main
description: Create a PR to the main branch for feature/fix changes in this pnpm + Changesets monorepo. Use when the user says "PRを作成", "mainにPR", or wants to submit changes for review. Always run this in the monorepo-aware way — identify the affected package(s) and make sure a changeset exists, because the release pipeline is Changesets-driven.

PR to Main Branch

Create a PR for a feature/fix branch targeting `main` in the cc-wf-studio monorepo.

This is a **pnpm monorepo with four packages** (`packages/core`, `packages/mcp`, `packages/cli`, `packages/vscode`) and versioning is driven by **Changesets**, not commit messages. Two monorepo facts shape this workflow:

• A release-worthy change must ship with a `.changeset/*.md` file in the same PR. Without it, the change merges but **never gets released** — and pending changesets later block promotion to production.
• Knowing *which package(s)* changed drives the changeset target, the PR scope, and the commit scope (e.g. `fix(vscode):`).

So the job here is not just "open a PR" — it's "open a PR that the release pipeline can actually act on."

Workflow

1. **Gather context** (run in parallel):

• `git status` (no `-uall`)
• `git diff` (staged + unstaged) and `git diff origin/main...HEAD` for the full branch delta
• `git log origin/main..HEAD --oneline` for every commit on the branch
• Check whether the branch tracks a remote and needs pushing
• `ls .changeset/*.md` to see whether a changeset already exists

2. **Identify scope and type**:

• **Affected package(s)**: map changed paths to packages — `packages/core` → `@cc-wf-studio/core`, `packages/mcp` → `@cc-wf-studio/mcp`, `packages/cli` → `@cc-wf-studio/cli`, `packages/vscode` → `cc-wf-studio` (the VSCode extension). Changes outside `packages/` (root config, `.github/`, docs) usually need no release.
• **Type**: read the commit prefix, allowing an optional scope — `fix:` / `fix(vscode):` → fix, `feat:` / `feat(core):` → feat, `improvement:` → improvement. Review **all** commits on the branch, not just the latest.

3. **Ensure a changeset exists** (the monorepo-critical step):

• If a `.changeset/*.md` already covers this change, confirm it names the right package(s) and bump level, and move on.
• If the change should be released and no changeset exists, create one with `pnpm changeset` — select the affected package(s) from step 2, choose patch/minor/major, and write a one-line summary (this becomes the CHANGELOG entry). Note: bumping `@cc-wf-studio/core` auto-bumps its dependents, so you don't author separate changesets for `cli`/`mcp`.
• If the change genuinely needs no release (CI-only, tooling, docs), record that intent explicitly with `pnpm changeset add --empty` so the pipeline isn't left guessing.
• Why this matters: releases are cut later by manually opening the Release PR (which consumes the accumulated changesets) and merging it — that merge auto-publishes. A PR that lands without the right changeset silently never gets released. (See `docs/release-flow.md` for the release side — releasing is a human-only action, not something to self-trigger.)

4. **Verify the build is green** before opening the PR:

• Run `pnpm check && pnpm build` from the repo root (Biome + type-checks, then full compilation). Reviewers and CI expect a clean tree, and catching breakage now is cheaper than after review.

5. **Select the PR template** based on type (from step 2):

• `fix:` → `assets/fix-template.md`
• `feat:` → `assets/feat-template.md`
• `improvement:` → `assets/improvement-template.md`

6. **Create the PR**:

• Push the branch with `git push -u` if it has no upstream.
• Open it with `gh pr create --base main`, filling the chosen template.

PR Format

• **Language**: always write the PR title and body in English (repo rule).
• **Title** — `main` merges via **squash**, so the PR title *becomes* the squash commit subject. It must therefore follow the commit convention: `<type>(<scope>): <description>`.
• `<type>`: matches the change type from step 2 — `fix` / `feat` / `improvement` / `docs` / `refactor` / `chore` / `ci`.
• `<scope>`: the affected package/area from step 2 — `vscode`, `cli`, `mcp`, `core` (use the directory name, not the npm name). List several as `(cli, mcp)`. **Omit the scope** for repo-wide changes (root config, `.github/`, top-level docs), e.g. `ci: guard against pending changesets`.
• `<description>`: imperative mood, no trailing period, concise (aim ≤50 chars per the commit guideline; GitHub appends a `(#NN)` suffix, with a leading space, on squash — so don't pad it).
• Examples (from this repo's history): `fix(vscode): parse Changesets-format CHANGELOG`, `feat(cli): ccwf install-skills subcommand`, `docs: add root README for the monorepo`.
• **Body**: in the **Changes** section, write real monorepo paths (`packages/vscode/src/...`, `packages/core/...`), not generic placeholders.
• Mention the changeset in the body so reviewers can see the intended release effect — e.g. "Adds a `patch` changeset for `cc-wf-studio`" or "No release needed (empty changeset)".

Templates

• **fix:** `assets/fix-template.md` — Problem/Solution with Current vs Expected behavior.
• **feat:** `assets/feat-template.md` — Summary/Motivation/Changes.
• **improvement:** `assets/improvement-template.md` — Before/After comparison.