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.