بنقرة واحدة
custom-rebase
// Guide for rebasing feature branches onto main in the Fusion Framework monorepo, including handling pnpm-lock.yaml conflicts
// Guide for rebasing feature branches onto main in the Fusion Framework monorepo, including handling pnpm-lock.yaml conflicts
Explain what Fusion MCP is and guide users through setting it up when they need Fusion-aware MCP capabilities in Copilot workflows.
Batch-process Dependabot PRs end-to-end: checkout, rebase, review, changeset, validate, and auto-merge high-confidence PRs. USE FOR: process all Dependabot PRs, clear dependency backlog, batch-merge safe Dependabot updates, batch-process dependency PRs. DO NOT USE FOR: single-PR deep review (use fusion-dependency-review), feature PRs, non-Dependabot dependency PRs, or PRs requiring manual code changes.
Review dependency PRs with structured research, existing-PR-discussion capture, multi-lens analysis (security, code quality, impact), and a repeatable verdict template. USE FOR: dependency update PRs, Renovate/Dependabot PRs, library upgrade reviews, "review this dependency PR", "should we merge this update". DO NOT USE FOR: feature PRs, application code reviews, dependency automation/bot configuration, or unattended merge without confirmation.
Classify issue type, activate the matching agent mode for type-specific drafting, and enforce shared safety gates before GitHub mutation.
Handles GitHub issue resolution end-to-end for prompts like "solve #123", "lets solve #123", "work on #123", "work on https://github.com/owner/repo/issues/123", or by pasting a direct GitHub issue URL as the request. USE FOR: solve #123, continue work on issue #123, work on https://github.com/owner/repo/issues/123, paste a GitHub issue URL for implementation work. DO NOT USE FOR: issue drafting only, PR review only, or non-implementation research.
Plan and break down user-story issues into ordered, traceable task issue drafts with explicit publish gates.
| name | custom-rebase |
| description | Guide for rebasing feature branches onto main in the Fusion Framework monorepo, including handling pnpm-lock.yaml conflicts |
This skill helps you rebase feature branches onto the latest main branch, handling common conflicts in a pnpm monorepo.
When rebasing a feature branch, you'll often encounter conflicts in pnpm-lock.yaml due to parallel dependency changes. The correct approach is to regenerate the lockfile rather than manually resolving conflicts.
# Navigate to your worktree or branch
cd /path/to/worktree
# Ensure you're on the correct branch
git branch
# Fetch latest changes from origin (including main)
git fetch origin
git fetch origin main:refs/remotes/origin/main
# Rebase your branch onto the latest main
git rebase origin/main
CRITICAL: When pnpm-lock.yaml has conflicts during rebase:
# Regenerate it from package.json files
pnpm install
# Stage the regenerated lockfile
git add pnpm-lock.yaml
# Continue the rebase
git rebase --continue
When you encounter a "Version Packages (next)" commit with conflicts:
This happens when your feature branch has pre-release versions (e.g., 2.0.0-next.0) but main has been updated with newer regular versions.
Resolution strategy:
--ours (HEAD version from main)--ours (HEAD changelog from main)# For all package.json conflicts, keep HEAD version
git checkout --ours "packages/*/package.json"
git add "packages/*/package.json"
# For all CHANGELOG.md conflicts, keep HEAD changelog
git checkout --ours "packages/*/CHANGELOG.md"
git add "packages/*/CHANGELOG.md"
# Also check other affected files
git checkout --ours "vue-press/package.json" 2>/dev/null || true
git add "vue-press/package.json" 2>/dev/null || true
# Continue the rebase
git rebase --continue
Why? The main branch has the authoritative versions and changelogs. Your feature branch's pre-release versions will be regenerated when you create a new changeset after rebasing.
For conflicts in source files (.ts, .tsx, etc.):
# Manually resolve conflicts in the files
# Then stage the resolved files
git add path/to/resolved-file.ts
# Continue the rebase
git rebase --continue
After all commits are rebased successfully:
# Verify the branch is clean
git status
# Force push to update the remote branch
git push --force-with-lease origin YOUR_BRANCH_NAME
If .changeset/pre.json exists (pre-release mode), align initialVersions to current package versions for packages changed by the rebase:
# From repo root
node .agents/skills/custom-rebase/scripts/align-pre-initial-versions.cjs
What it does:
.changeset/pre.json to get the tag (e.g., next)initialVersions when the current package version does NOT end with -TAG.NUMBER (e.g., 2.0.0 or 2.1.0)-TAG.NUMBER (e.g., 2.0.0-next.0), preserving ongoing pre stateBefore pushing, verify local rebase result against the remote branch.
# Ensure you have latest remote
git fetch origin
# Set a helper var for current branch
BRANCH=$(git rev-parse --abbrev-ref HEAD)
# Quick overview of what will change on the remote
git diff --stat origin/$BRANCH...HEAD
# See the file list (useful to spot unintended changes)
git diff --name-only origin/$BRANCH...HEAD | sort
# Review commit differences (left/right) without merges
git log --oneline --left-right --cherry --no-merges origin/$BRANCH...HEAD
# Optional: preview the push without sending any data
git push --force-with-lease --dry-run origin $BRANCH
Proceed to push only if the changes match expectations.
Run the data extraction script:
# From repo root
node .agents/skills/custom-rebase/scripts/generate-rebase-report.cjs --no-fetch
This generates .tmp/skills/custom-rebase/<timestamp>-rebase-report.md with raw data:
zod: ^3.23.8 → ^4.3.5)@azure/search-documents: ^12.2.0)After the raw report is generated, the AI agent will automatically:
.tmp/skills/custom-rebase/<timestamp>-rebase-report.mdThe summary will be displayed in the chat for review before you push.
Open the SUMMARY.md file in your editor to review before pushing.
If your local branch has diverged incorrectly:
# Fetch latest
git fetch origin
# Hard reset to remote branch
git reset --hard origin/YOUR_BRANCH_NAME
If you need to start over:
git rebase --abort
# After resolving conflicts and staging changes
git rebase --continue
Only if the commit is no longer needed:
git rebase --skip
origin/mainpnpm-lock.yaml conflicts:
git rm pnpm-lock.yamlpnpm install to regenerategit add pnpm-lock.yamlgit rebase --continue--force-with-leaseThe lockfile contains exact dependency resolutions for the entire monorepo. During a rebase:
By regenerating with pnpm install:
package.json files (including your changes)Your local branch has commits that aren't on remote. Common causes:
Fix: Reset to remote and rebase:
git fetch origin
git fetch origin main:refs/remotes/origin/main
git reset --hard origin/YOUR_BRANCH_NAME
git rebase origin/main
You may be rebasing in the wrong direction. Ensure:
git rebase origin/mainCheck:
package.json changes are staged/committedpackage.json files# 1. Navigate and prepare
cd /Users/odin.rochmann/dev/GitHub/fusion-framework.worktree/react-19
git fetch origin
git fetch origin main:refs/remotes/origin/main
# 2. Ensure clean state
git status # Should show "nothing to commit, working tree clean"
# 3. Start rebase
git rebase origin/main
# 4. If pnpm-lock.yaml conflict appears:
git rm pnpm-lock.yaml
pnpm install
git add pnpm-lock.yaml
git rebase --continue
# 5. Repeat step 4 for each commit with lockfile conflicts
# 6. When rebase completes:
git push --force-with-lease origin react-19
fusion-dependency-review - Review dependency pull requests that need branch refresh or conflict follow-up