The workflow and the script share a configuration surface: where the marketplace lives, which fork to push to, and how to identify the actor that opens pull requests. The workflow reads these from GitHub variables and secrets. The script reads the same names from environment variables.
| Name | Type | Scope | Purpose |
|---|---|---|---|
MARKETPLACE_REPO |
variable | org or repo | Upstream marketplace repo, owner/repo |
MARKETPLACE_FORK |
variable | org or repo | Bot's fork of the marketplace, owner/repo |
BOT_USERNAME |
variable | org or repo | GitHub login for the bot actor |
BOT_EMAIL |
variable | org or repo | Email recorded on bot commits and PRs |
MARKETPLACE_PAT |
secret | org or repo | PAT owned by the bot account, used for the workflow's push and PR-create |
All four variables and the secret can live at the organization level. Repo-level values override org-level on name collision. Organization-level is the recommended default because rotation and renaming only need to happen once.
The PR mechanic — push to a fork, open a PR upstream — needs an actor that owns a fork and can act unattended. A bot account satisfies both:
- It owns its own fork (
alfred-int-bot/claude-marketplacein the canonical setup), so cross-owner permission complications don't arise. - It has a long-lived PAT scoped to its own repos, kept in the workflows secret store, rotated independently of any human's credentials.
- Commits and PRs are attributed to the bot, which is the correct signal when automation produced them.
A fine-grained PAT owned by a personal account cannot grant write access on org-owned upstream repos that the personal account does not control. A bot-owned PAT avoids that limitation by being the resource owner itself.
- Open Settings → Secrets and variables → Actions in the
organization that hosts this
workflowsrepo. - Under the Variables tab, click New organization variable and add
MARKETPLACE_REPO,MARKETPLACE_FORK,BOT_USERNAME,BOT_EMAIL. - Under the Secrets tab, click New organization secret and add
MARKETPLACE_PAT. - For each, restrict access to the repositories that need it.
Same flow but in the workflows repository's own Settings → Secrets and variables → Actions. A repo-level value takes precedence over an org-level value with the same name.
Create the PAT while signed in as the bot account.
Classic — simplest:
- Scope:
repo(full). - Expiration: long enough for comfortable rotation, short enough to be hygienic.
Fine-grained — possible because the bot owns the fork:
- Resource owner: the bot account.
- Repository access: the bot-owned fork.
- Repository permissions:
Contents: Read and writePull requests: Read and write
For the PR-create call against the upstream repo, the bot account needs to be either a collaborator on the upstream or a member of the upstream's organization with at least Triage role on the marketplace repo. No additional PAT permissions on the upstream are required for opening a PR from the bot's own fork.
The workflow's first step verifies that the four variables are set and fails with a clear error if any is missing. The script does the equivalent check on the env var names.
The script reads MARKETPLACE_REPO and MARKETPLACE_FORK from the shell
environment. MARKETPLACE_REPO is required. MARKETPLACE_FORK defaults to
the authenticated gh user's namespace with the same repo name as
MARKETPLACE_REPO; set it explicitly if you maintain a fork under a different
name.
The script does not override the operator's git config. Commits and the
opened PR are attributed to whoever runs the script. Bot-attributed PRs come
from the workflow.
When the workflow starts failing with Bad credentials, regenerate the bot's
PAT and update MARKETPLACE_PAT in whichever scope (org or repo) it lives.
The script uses the operator's own gh token and has no separate rotation
schedule.