adobe-addons-push

name	adobe-addons-push
description	Use when pushing, committing, submitting, publishing, or syncing YiChongmimi Adobe add-on project changes to GitHub. Covers branch safety, business-specific checks, PR creation/merge, forbidden artifacts, management repo status refresh, and AI-assisted handoff wording.

Adobe Add-ons Push

Use this skill when the user asks an AI agent to push project changes, submit code, publish an update, open a PR, merge a PR, or refresh YiChongmimi/adobe-addons-management after an Adobe add-on change.

This skill is the push-time companion to adobe-addons-collaboration. Use both when starting from a fresh task; use this one when the code change already exists and needs to be safely sent to GitHub.

Related Adobe Skills

This skill owns push, PR, merge, package-artifact safety, and management sync. It should be used after one or more specialized Adobe repair skills produced local changes:

• adobe-addons-collaboration before editing or when branch/repo setup is not already safe.
• migrate-adobe-app-to-template-v2 for broad migration changes that need final verification and PR.
• adobe-add-on-request-params for public-parameter fixes that need PR and optional CSV/status follow-up.
• adobe-add-on-login-loop-fix for login/status-loop fixes that need network evidence summarized in the PR.
• adobe-add-on-credits-flow for credits/payment-return fixes that need build/package verification and clear risk notes.
• subscription-credits-guardrails for subscription quota fixes, including cancelled-but-not-expired subscription regressions, that need scenarios recorded before merge.

Keep this skill independent: it should not decide the code repair strategy, and repair skills should not skip these push-time safeguards.

Business Rules

• Treat each add-on as one private repo under YiChongmimi.
• Treat main on the project repo as the source of truth.
• Treat YiChongmimi/adobe-addons-management as status and coordination only; it does not contain project source code.
• Do not push directly to main unless the owner explicitly approves an emergency override.
• Prefer PR flow: local branch -> push branch -> open PR -> merge -> refresh management status.
• One project per PR unless the user explicitly asks for a coordinated multi-repo update.
• Keep generated release artifacts out of Git unless the project already intentionally tracks them.

Interpret User Intent

If the user says:

• "帮我 push" or "提交一下": commit current project changes, push a branch, and open/update a PR.
• "同步到 GitHub": push the project repo, not the management repo, unless they name the management repo.
• "完成闭环": after project main changes, verify adobe-addons-management/project-status.json has the latest commit, manually refreshing if needed.
• "发布/打包后 push": run build/package checks first, but do not commit dist, dist.zip, or other generated packages unless explicitly approved.
• "AI 帮我完成": perform the whole PR and management refresh flow if permissions are available; stop only for missing auth, merge approval, or failed checks.

Preflight

Work from inside the project repo unless the user explicitly names the management repo.

git remote -v
git status --short --branch
git fetch origin

Verify the repo belongs to YiChongmimi or is intended to be migrated there. If the remote points to another owner, clarify or fix the remote before pushing.

If on main, create a task branch before committing:

git switch main
git pull --ff-only origin main
git switch -c fix/<short-task-name>

If already on a branch, rebase onto the latest origin/main before push:

git fetch origin
git rebase origin/main

Do not overwrite user work. If unrelated local changes exist, leave them unstaged and mention them in the handoff.

Install Guardrails

If the management repo is available locally, install hooks before committing:

/path/to/adobe-addons-management/scripts/install-project-hooks.sh .

If .github/workflows/notify-management.yml is missing, install the project sync workflow:

/path/to/adobe-addons-management/scripts/install-project-sync-workflow.sh .

The project sync workflow is useful after merge to main; it dispatches a status update to YiChongmimi/adobe-addons-management when its token is configured.

Stage Safely

Inspect the diff before staging:

git diff --stat
git diff

Never stage these unless the user explicitly asks and the repo intentionally tracks them:

.env
.env.*
.npmrc
node_modules/
.npm-cache/
dist/
dist.zip
*.zip
*.pem
*.key
*.csr
*.srl
*.xls
*.xlsx
output/
release/
logs
screen recordings

Prefer path-specific staging:

git add <changed-source-files>

Then re-check:

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

Verify Before Commit

Run checks appropriate to the change. For most Adobe add-ons:

npm run build

If package scripts include lint, typecheck, or test, run the ones relevant to the touched code.

If packaging was part of the task, verify both:

• dist.zip exists after packaging.
• the embedded manifest.json is the expected project manifest.

Do not commit the package artifact unless the owner explicitly wants release artifacts tracked.

Commit

Use concise conventional commits:

fix(table-ocr): refresh credits after payment return
feat(word-cloud): add Adobe request context
chore(jigsaw-explorer): install management sync workflow

Allowed types:

fix feat chore docs test refactor build ci revert

Commit only after checks pass or after clearly recording why a check could not run.

Push And PR

Before pushing:

git fetch origin
git rebase origin/main
git status --short --branch

Push the current branch:

git push -u origin HEAD

Open or update a PR into main:

gh pr create --base main --head <branch> --title "<commit-style title>" --body "<summary, verification, risk>"

If a PR already exists:

gh pr view --web
gh pr edit --body "<updated body>"

PR body must include:

• changed project
• what changed
• verification commands and result
• packaging status if relevant
• known risk or "none known"

Merge Policy

If the user has explicitly approved merging, merge the PR after checks pass:

gh pr checks
gh pr merge --squash --delete-branch

If checks are pending, wait or tell the user exactly what remains pending.

If checks fail, do not merge. Fix or report the failure with the failing job name.

Management Refresh

After project main changes, complete the status loop.

First wait briefly for the project-side notify-management.yml workflow to dispatch. Then verify the management ledger:

gh workflow run refresh-project-status.yml -R YiChongmimi/adobe-addons-management --ref main
gh run list -R YiChongmimi/adobe-addons-management --workflow refresh-project-status.yml --limit 1
gh run watch -R YiChongmimi/adobe-addons-management

If GitHub Actions cannot refresh because a token/secret is missing, refresh locally from the management repo if the current gh auth can read private repos:

cd /path/to/adobe-addons-management
scripts/refresh-project-status-from-github.mjs
git status --short

If project-status.json changed locally, commit it in the management repo using PR flow unless the owner explicitly approves a direct management commit.

New Project Repos

When adding a new add-on repo:

1. Create or confirm the private repo under YiChongmimi.
2. Add the project to projects.json in adobe-addons-management.
3. Install project hooks and .github/workflows/notify-management.yml.
4. Push the project source through PR flow.
5. Refresh project-status.json.
6. Open/merge the management repo PR that records the new project metadata and status.

AI Handoff

End with a compact status:

Repo:
Branch:
PR:
Commit:
Verification:
Management refresh:
Skipped checks:

Say "management refresh complete" only when project-status.json has the latest project main SHA or the refresh workflow completed successfully.

Useful User Prompt

The user can trigger this skill with:

用 adobe-addons-push 帮我把这个项目 push 到 GitHub：先检查不要提交产物和密钥，开 PR，合并后刷新 adobe-addons-management。