PR to Main Branch

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.