SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsseed-submit-change

seed-submit-change

Deployment & operations

View repository

Updated 10-16 05:05

About this skill

SEED change submission

seed-change-plan의 targetBranch, targetRef, prBaseis used as a single contract. The base branch is read-only, and only the current feature branch is changed.

1. Freeze the state before submission

  1. Record the current branch, working tree, feature HEAD, and current upstream.
  2. If the current branch is dev, minor, major, stop. Do not submit directly from the base branch.
  3. origin/dev, origin/minor, origin/major.
  4. Determine the existing base branch that created the current feature branch and the fork SHA. Check the upstream, reflog, fork points with the three base branches, and the commit graph together. Do not choose merely because it is the nearest merge base, and do not merge branch names with the same SHA.
  5. Pass the existing base branch as --base-refand run seed-change-planagain. Also pass through --lane과 --bump or --no-releaseexactly as determined in the initial plan. If any of the three values is unknownor they differ from each other, do not rebase.
  6. Record the selected target base branch name and SHA together. Even if the SHA is the same, do not change the name.

Stop if the existing base branch is not determined to be a single one, or if the list after the fork SHA contains lane commits that are not the current work. targetRefis the base to move onto, and the existing fork SHA oldBaseis the boundary of the commits to move, so they may differ.

2. Commit and rebase

If there are uncommitted changes, do not use automatic stash and git rebase --autostash. Show the files to include, the files to exclude, and the commit message, get user confirmation, then stage and commit only the approved files. Use the English Conventional Commits format for the commit message.

Before rebasing, show the commit list of oldBase..HEADto confirm that only the current work is being moved. Also recheck that the target ref has not moved from the recorded SHA. If the feature commits contain a merge commit, do not arbitrarily decide how to preserve it; stop.

On the confirmed feature branch, use the following command to move only the commits after the existing base onto the new base.

git rebase --onto <targetRef> <oldBase>

Do not use a simple git rebase <targetRef>. This is because it can replay even existing lane commits between diverged release lanes. Do not switch to the dev, minor, major local branch or modify that branch.

If a conflict occurs, read both files and the intent of the base branch directly. Handle only conflicts that can be resolved with certainty within the current work scope. If there is insufficient basis, restore the original state with git rebase --abortand stop.

3. Re-verification

After the rebase is complete, targetRefVerify that it is an ancestor of the new HEAD, and cross-check that the list of moved commits corresponds to the feature commits before the rebase. Then keep the options confirmed in the initial plan and --base-ref만 targetRefand run it again.

bun skills/seed-change-plan/scripts/change-plan.ts --base-ref <targetRef> --lane <minor|major|none> --bump <patch|minor|major>
bun skills/seed-change-plan/scripts/change-plan.ts --base-ref <targetRef> --lane <minor|major|none> --no-release

--bump와 --no-release , use only the one confirmed initially. In the initial plan, --laneif you did not confirm it, do not arbitrarily add a new value. Execute the generation, focused tests, build, and manual verification proposed by the plan in that order. Do not report failures or new unknownas success.

4. push

Get user confirmation immediately before push.

  • If the remote feature branch does not exist, use a normal push.

  • If the remote branch exists and the SHA changed due to rebase, read the remote SHA again. After the user confirms, specify the exact ref and expected SHA as shown below.

    git push --force-with-lease=refs/heads/<feature>:<expected-remote-sha> origin HEAD:refs/heads/<feature>

If the remote SHA differs from the expected value, do not push and replan from the latest state. --forceDo not use a lease without an expected SHA.

5. PR base

Get user confirmation immediately before creating a PR or changing the base of an existing PR.

  • 새 PR은 gh pr create --base <prBase> --head <feature>Specify the base and head as shown.
  • If the base of the existing PR is different, finish the rebase and verification first, then gh pr edit --base <prBase>change it to.
  • Use the English Conventional Commits format for the PR title.

After completion, read the PR's baseRefName, headRefName, and head SHA again. Report the feature SHA before and after the work, the base branch name and SHA, the verification results, and the actual PR base together.