Federation bump pull requests stall because their checks need manual approval

Description

The nightly federate-skills job opens its bump pull requests with the automatic GITHUB_TOKEN, because peter-evans/create-pull-request is called with no token: input. The pull request is therefore authored by github-actions[bot], which is neither an org member nor a collaborator here.

This repository requires approval to run workflows for all external contributors:

gh api repos/amd/skills/actions/permissions/fork-pr-contributor-approval
{"approval_policy":"all_external_contributors"}

That policy has no carve-out for our own automation, so every check on a bump pull request parks at action_required until a maintainer approves it by hand. Two things make that worse than a daily click:

1. Approval is bound to a head commit, not to the pull request.
2. The nightly run rebases onto main and pushes a fresh commit.

So an approval given today is discarded by tomorrow. A bump only lands if someone both approves the runs and merges on the same day. Otherwise it stalls indefinitely, and the required check never reports at all, so the pull request shows no red X to notice.

Observed

#245 carried the Magpie eval fix from AMD-AGI/Magpie#107 and sat unmerged from 2026-09-26 to 2026-09-28. Its required check Validate plugin manifests and federation never reported, leaving mergeStateStatus: BLOCKED with total_count: 0. Nine runs accumulated at action_required across three nightly commits (be1ad340, e298ae5c, 75403296) whose vendored content was byte-identical, SKILL.md blob 8be9fab6cd at all three.

#242 stayed open that whole time and the Magpie behavioral evals were never re-run against the fix. Once the runs were approved manually on 2026-09-28, all three workflows passed first try, so the change itself was never the problem.

This is not specific to Magpie. Any bump for any federated skill hits it.

Proposed change

Mint a short-lived installation token from a GitHub App and hand it to the PR-creation step:

- name: Mint a token for the federation app
  id: app-token
  uses: actions/create-github-app-token@v3
  with:
    app-id: ${{ secrets.FEDERATION_APP_ID }}
    private-key: ${{ secrets.FEDERATION_APP_PRIVATE_KEY }}

- name: Open pull request
  uses: peter-evans/create-pull-request@v7
  with:
    token: ${{ steps.app-token.outputs.token }}

A pull request opened by an app installed on this repository is not an external contribution, so its checks start unattended, and approval_policy stays on to do the job it is there for, guarding secrets against fork pull requests from outsiders. This is also the supported way to make a bot-opened pull request trigger workflows at all, since activity attributed to GITHUB_TOKEN is deliberately prevented from starting further workflow runs.

Prerequisites, which need org admin rather than repo admin:

1. Create a GitHub App in the org with Contents read/write and Pull requests read/write, nothing else.
2. Install it on this repository only.
3. Add FEDERATION_APP_ID and FEDERATION_APP_PRIVATE_KEY as repo secrets.

Ordering matters, create-github-app-token fails the run on a missing key, so the secrets need to exist before the workflow change merges.

Worth discussing before anyone creates an app

This adds a long-lived stored secret, the app private key, which runs against the direction #209 took when it swapped ANTHROPIC_API_KEY for OIDC-minted short-lived tokens. There is no OIDC equivalent for opening a pull request under a non-bot identity, a GitHub App private key is the standard mechanism, and the token it mints is itself short-lived and narrowly scoped. But if there is an appetite for a different approach, better to hear it before an app exists.

Not in scope

• Relaxing approval_policy. That setting is the protection, not the problem.
• The review bottleneck. Branch protection requires 2 approving reviews and enforce_admins is on, so bump pull requests will still need reviewers. This removes the CI gate only.

I have the workflow change ready and can open it as a draft against whichever approach this lands on.