adobe-addons-collaboration

name	adobe-addons-collaboration
description	Use for YiChongmimi Adobe add-on Git/GitHub collaboration: cloning one private repo per project, starting from latest main, branch naming, commit and PR rules, local Git hooks, forbidden artifacts, project registry updates, and collaborator handoffs.
metadata	{"short-description":"Git workflow for YiChongmimi Adobe add-ons"}

Adobe Add-ons Collaboration

Use this skill before editing, reviewing, packaging, or handing off any YiChongmimi Adobe add-on repository.

Related Adobe Skills

This skill owns repo collaboration setup and branch safety. After the repo is identified and prepared, combine it with the specialized Adobe repair skill that matches the actual code change:

• migrate-adobe-app-to-template-v2 for template-v2 migration, Adobe sandbox cleanup, ErrorAlert/reporting, and broad app modernization.
• adobe-add-on-request-params for public request params, request context, wrappers, ownHosts, Accept-Language, and CSV 传参数 work.
• adobe-add-on-login-loop-fix for repeated login/status calls, unstable callbacks, and status refresh loops.
• adobe-add-on-credits-flow for generic credits lifecycle, payment-return refresh, balance drift, cache, and successful-use deduction.
• subscription-credits-guardrails for cancelled-but-not-expired subscriptions, subscription monthly quota, subscribed footer totals, upgrade return, and monthly-then-purchased deduction.
• adobe-addons-push when the local work is ready to commit, open a PR, merge with approval, or refresh management status.

Keep this skill independent: it should not replace specialized repair rules, and specialized repair skills should not replace these Git/GitHub guardrails.

Start

1. Identify the exact add-on repo from the user's request or projects.json.
2. Work in that add-on's own repository, not in the management repo.
3. Start from latest main:

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

Use feat/, fix/, chore/, docs/, refactor/, build/, test/, or codex/ prefixes with lowercase kebab-case names.

Local Guardrails

If the management repo is available, install shared hooks inside the add-on repo:

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

Hooks block direct commits or pushes to main, stale-branch pushes, and obvious local artifacts.

Commit And PR Standard

• One focused task per branch.
• One add-on per PR unless the user explicitly asks for a coordinated multi-repo change.
• Commit style: fix(table-ocr): refresh credits after payment return.
• PR must include summary, changed project, verification commands, packaging status if relevant, and known risk.
• Do not push directly to main; use PR review.

Never Commit

Block or remove these before commit:

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

Verification

Run checks that exist in the project. For most Adobe add-ons, at least run:

npm run build

If packaging is requested, verify dist.zip and the embedded manifest.json, not only command success.

When behavior changes, prefer runtime evidence over static inference: command output, local URL, network request, screenshot, or generated artifact.

Management Sync

The management repo tracks project status, not source code. Each project should have:

.github/workflows/notify-management.yml

Install it from the management repo when missing:

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

After main updates, the workflow dispatches adobe_project_update to YiChongmimi/adobe-addons-management, which updates project-status.json.

If sync fails, check that the project or organization has MANAGEMENT_REPO_TOKEN with permission to dispatch events to the management repo.

The management repo also has .github/workflows/refresh-project-status.yml for scheduled/manual reconciliation once the same token is configured.

If a project changed before its workflow existed, refresh the ledger from the management repo:

scripts/refresh-project-status-from-github.mjs

Registry Updates

Use projects.json as the machine-readable source of truth. Do not edit README tables, projects.yaml, and projects.json independently unless the user asks for registry maintenance.

Keep absolute local paths out of portable instructions. They can remain in the registry as local coordination metadata.

Handoff

Final handoffs should say:

• Repo and branch
• Files changed
• Verification performed
• Whether a PR is needed or already opened
• Any skipped checks and why