adobe-codeup-push

name	adobe-codeup-push
description	Use when committing, pushing, creating a merge request, self-merging, or requesting review for verified YiChongmimi Adobe add-on changes in the Alibaba Cloud Codeup adobe monorepo. Applies after adobe-codeup-local-sync, preserves GitHub push workflows, uses simple commit messages plus handoff-first context, and defines light internal Codeup MR/review standards.

Adobe Codeup Push

Use this skill only for the Codeup company monorepo stage. It starts after local source sync and target verification are complete.

Do not use this skill for GitHub project repos. If the target remote is GitHub or the user asks for GitHub PR/management sync, use adobe-addons-push. If the task is only GitHub-local-to-Codeup-local alignment, use adobe-codeup-local-sync.

Workflow Position

Use the three Adobe Git skills as separate stages:

GitHub project repo push/PR        -> adobe-addons-push
GitHub local -> Codeup local sync  -> adobe-codeup-local-sync
Codeup remote push/MR/main merge   -> adobe-codeup-push

This skill owns:

• Codeup branch naming
• Codeup commit message style
• handoff inclusion standard
• Codeup push branch
• Codeup merge request wording
• self-merge vs reviewer decision
• no-artifact staging rules

It does not own:

• GitHub commit/PR/management sync
• Code repair strategy
• local sync verification design
• remote permission changes

Preconditions

Before Codeup push, require evidence that:

• adobe-codeup-local-sync or equivalent local sync standard was completed.
• GitHub local source was verified before sync.
• Codeup target directory was re-verified after sync.
• generated artifacts and temporary dependency links were cleaned.
• handoff.html or a project-specific handoff exists and reflects the current state.

If these are missing, stop and complete the local sync gate first.

Preflight

Work from the Codeup monorepo root:

cd /Users/Dario/Documents/Codex/adobe-projects/adobe
git remote -v
git status --short --branch
git fetch origin

Confirm the remote points to Codeup, for example:

[e-mail]:.../adobe.git

Do not push if the remote is a GitHub repo; switch to adobe-addons-push.

Branch Standard

Prefer a short-lived branch even when self-merging is allowed. Keep branch names simple and searchable:

sync/<project>
fix/<project>-<short-topic>
chore/<project>-<short-topic>
test/<project>-<short-topic>

Examples:

sync/ai-font-generator
fix/ai-font-generator-credits
chore/ai-font-generator-codeup-sync

If currently on main, create a branch:

git switch main
git pull --ff-only origin main
git switch -c sync/<project>

If already on a task branch, update safely:

git fetch origin
git rebase origin/main

Do not use long-lived shared work branches for ordinary project syncs.

Branch Lifecycle

Use short-lived task branches for ordinary Codeup sync work, especially multi-project, subscription, credits, login, payment, or release-related changes. Branches are review and rollback handles, not long-term records.

Default lifecycle:

create branch -> commit -> push branch -> self-check/MR/check diff -> merge main -> verify main -> delete completed branch

After a task branch has been merged or fast-forwarded into main, clean it up unless the user explicitly asks to keep it, a reviewer still needs it, or it is the active branch for unfinished work. The durable record should be main history, Codeup MR/change record when available, Feishu status, and the handoff page, not stale branches.

Before deleting any completed branch, verify all of these:

• origin/main contains the branch tip.
• local main is up to date with origin/main.
• the branch is not the current active work branch for another task.
• the branch name and commit are recorded in the handoff or final answer when useful.

Cleanup commands, after verification:

git fetch origin
git branch --contains <branch-tip> main
git branch -d <branch>
git push origin --delete <branch>

Never delete unmerged, disputed, reviewer-needed, or user-preserved branches.

Handoff-First History

Keep commit messages short and searchable. Put the real context in the handoff.

The handoff is not a rigid "why/verify/risk" report. Treat it as:

previous-episode recap + current state cockpit + commit/MR summary module

It should help the next human or AI answer:

• what previous decisions led here
• what code paths were intentionally changed
• what tests already covered
• what failures were known historical noise
• whether a new task may relate to this prior change
• what should not be re-litigated without new evidence

Include a clear commit module inside the handoff:

Suggested Commit

sync(ai-font-generator): align verified local source

Scope:
- adobe-ai-font-generator

Includes:
- subscription/credits guardrail logic
- focused regression tests
- Codeup local sync evidence

Not included:
- backend changes
- generated dist artifacts
- GitHub remote push

Prefer storing handoffs under:

handoffs/<project>.html

For the current transition, an existing root-level phase*-handoff.html is acceptable. For new projects, prefer handoffs/.

Commit Message Standard

Use concise conventional-style commits. Do not write long commit bodies unless there is a special reason; the handoff carries context.

Allowed types:

sync fix feat chore test build ci docs refactor revert

Recommended patterns:

sync(ai-font-generator): align verified local source
fix(ai-font-generator): repair credits guardrails
test(ai-font-generator): add credits regression coverage
chore(ai-font-generator): add handoff recap

Avoid:

hu
1
update
fix
misc

Stage Safely

Inspect the diff before staging:

git diff --stat
git diff -- <project> handoffs <handoff-file>

Never stage generated or sensitive artifacts unless explicitly approved and intentionally tracked:

.env
.env.*
.npmrc
node_modules/
dist/
dist.zip
*.zip
*.pem
*.key
*.csr
*.srl
output/
release/
logs
screen recordings

Use path-specific staging:

git add <project-source-files> handoffs/<project>.html

Then re-check:

git status --short
git diff --cached --stat
git diff --cached

Verification Before Commit

Use the verification already completed by adobe-codeup-local-sync as the primary gate. Before committing, re-check that the current index still matches that verified state. The user should not be expected to manually inspect the diff; the agent owns the commit-time review and must report any skipped check clearly.

Minimum commit gate:

• focused business tests passed in Codeup target
• TypeScript/type checks passed when present
• changed-file ESLint passed when ESLint exists
• build/package passed when project supports them
• handoff is included and current
• git diff --check is clean, or every whitespace warning is fixed before commit
• staged diff has been self-reviewed against the requested scope
• no forbidden artifacts staged

If a check is skipped, the handoff and MR must say why.

Review Level

Use convenience-first review levels:

Level 0: Direct Push Main

Allowed only for tiny low-risk changes when the user explicitly asks.

Examples:

• typo/doc-only
• handoff-only correction
• obvious metadata correction

Still require a real commit message. Avoid this as the default.

Level 1: MR Self-Merge

Default for ordinary verified project syncs.

Flow:

commit -> push branch -> create Codeup MR -> self-check diff/handoff -> merge main

The MR is mainly an audit and context container, not a heavy approval gate.

Level 2: MR With Reviewer

Require at least one human reviewer when any of these are true:

• multiple projects are changed in one MR
• payment, subscription, credits, login, identity, auth, or permissions change
• files are deleted, moved, or mass-renamed
• CI, deployment, secrets, or repository settings change
• local verification has failures or skipped important checks
• the user or agent is uncertain about business behavior

Codeup Push And MR

Push the task branch:

git push -u origin HEAD

Create or update a Codeup merge request through the Codeup UI/CLI/API available in the environment. The MR title should match the commit title when possible.

MR body can be short because the handoff carries the context:

Project: adobe-ai-font-generator
Commit: sync(ai-font-generator): align verified local source
Handoff: handoffs/ai-font-generator.html
Verification:
- npm test ... PASS
- npm run lint:types PASS
- changed-file ESLint PASS
- npm run build PASS
- npm run package PASS
Review level: self-merge
Not included: backend changes, generated artifacts, GitHub push

If no Codeup MR tool is available, stop after pushing the branch and give the user the branch name plus MR body to paste.

Merge

The agent owns the merge-time recheck. Do not rely on the user to inspect the final diff. Before merging or fast-forwarding main, re-run the narrow safety checks that prove the branch still matches the verified scope:

git fetch origin
git status --short --branch
git diff --check origin/main..HEAD
git diff --name-only origin/main..HEAD | rg '(^|/)(node_modules|dist|dist\.zip)$|\.zip$|\.pem$|\.key$|\.env|\.npmrc$'
git diff --stat origin/main..HEAD
git merge-base --is-ancestor origin/main HEAD

If the forbidden-artifact grep returns matches, stop and remove them from the branch unless they are intentionally tracked and explicitly approved. If origin/main is not an ancestor, rebase or merge safely and rerun verification.

Merge only when:

• the user asked to complete the Codeup push/MR flow, or self-merge is already the agreed default for this class of change
• branch push succeeded
• MR diff matches the staged/verified scope
• required reviewer rule, if any, is satisfied

After merge or main push, confirm:

git fetch origin
git log --oneline --max-count=5 origin/main
git status --short --branch

Then apply the Branch Lifecycle cleanup rule for completed branches: delete merged local and remote task branches after confirming origin/main contains the branch tip. Do not rewrite history.

Final Handoff

End with:

Codeup repo:
Branch:
Commit:
MR:
Merge status:
Review level:
Handoff:
Verification:
Skipped checks:
Residual risks:
GitHub touched: yes/no

Always say explicitly whether GitHub was untouched. This prevents confusion with adobe-addons-push.