Roll out add-issues-to-project and check-pr-issue-link to internal repos #12

Problem

add-issues-to-project.yml (#10) and check-pr-issue-link.yml exist as reusable workflows in stacklok/.github, but only a handful of repos actually call them. Most repos tracked by the /eng-report skill's team-config.yaml (in StacklokLabs/stackforce-skills) have neither workflow wired up, so issues opened in those repos aren't landing on project 73 (Stacklok Engineering) and PRs there aren't checked for a linked issue.

Both workflows mutate internal state (an internal Projects v2 board, and depend on internal App credentials) and are documented as internal-use-only, even though stacklok/.github itself is public. They should only be added to internal (private) repos, not public ones.

Scope

Repos are taken from the repos: list in team-config.yaml. Of the 41 repos listed, 7 are internal (private) — the rest are public and are explicitly out of scope for this change.

Internal repos to update

Repos dropped from scope

stacklok/vantage-etl, stacklok/PoC-Demo-Deploy, and stacklok/stacklok-epics are internal but excluded from this rollout: they're not under active development, or are internal management tooling rather than product repos where untracked issues/unlinked PRs are a meaningful problem.

Repos explicitly out of scope (public)

All other repos in team-config.yaml's repos: list are public and must not get either workflow: stacklok/brood-box, stacklok/dockyard, stacklok/docs-website, stacklok/frizbee, stacklok/frizbee-action, stacklok/go-microvm, stacklok/homebrew-tap, stacklok/releaseo, stacklok/toolhive, stacklok/toolhive-catalog, stacklok/toolhive-cloud-ui, stacklok/toolhive-core, stacklok/toolhive-registry-server, stacklok/toolhive-rfcs, stacklok/toolhive-studio, stacklok/waggle, stacklok/mcp-template-py, and all 15 StacklokLabs/* repos.

GitHub App credentials — blocker for add-issues-to-project.yml

add-issues-to-project.yml requires an app-id/app-private-key secret pair for a GitHub App installed on the stacklok org with Organization Projects: Write permission (the default GITHUB_TOKEN cannot write to an org Projects v2 board). Audited repo secrets (gh secret list) across the repos that need this workflow:

stacklok/claude-plugins is fully covered — the FLOW_METRICS_APP_ID App now has Organization Projects: Write, and its secrets are already in place. stacklok/atrium and stacklok/infra still need a usable App+secret pair — blocked pending the org admin provisioning the App(s) for these two repos (either reusing the FLOW_METRICS_APP_ID App or creating new ones with Organization Projects: Write). Secret names for app-id/app-private-key in each repo will be decided once the App(s) exist, to match whatever naming the admin settles on.

Adding a GitHub App's credentials as a repo secret is something an org admin does directly in the GitHub UI (Settings → Secrets and variables → Actions, per repo) — not something scriptable via the API with a personal token.

Implementation notes

• Prerequisite (blocked): org admin to provision/confirm the App(s) with Organization Projects: Write for atrium and infra, then add its credentials as repo secrets. Exact secret names TBD once the App(s) are settled. claude-plugins needs no changes — already has the App's credentials and the permission bump.
• For add-issues-to-project.yml callers: pass project-number: 73 and the App credentials (app-id/app-private-key) as secrets; status-option-name defaults to Icebox and owner defaults to stacklok, so neither needs to be set explicitly for the common case. Trigger on issues: types: [opened].
• For check-pr-issue-link.yml callers: trigger on pull_request: types: [opened, edited, reopened, synchronize], and declare permissions: pull-requests: write / issues: write in the caller workflow (the reusable workflow does not grant these itself — see its workflow_call: comment). No App credentials needed for this workflow.
• Reference implementation for both callers: stacklok/stacklok-enterprise-platform/.github/workflows/triage.yml, which already calls a stacklok/.github reusable workflow (needs-triage.yml) and can be used as a template for the uses: + with:/secrets: shape.

Acceptance criteria

• The FLOW_METRICS_APP_ID App has Organization Projects: Write permission on its stacklok org installation. (done)
• App(s) with Organization Projects: Write are provisioned for atrium and infra, and their app-id/app-private-key secrets are added under names TBD once the App(s) are settled. (claude-plugins already has these — no action needed.)
• stacklok/atrium and stacklok/infra call both add-issues-to-project.yml and check-pr-issue-link.yml from stacklok/.github.
• stacklok/stacklok-enterprise-platform calls only check-pr-issue-link.yml (not add-issues-to-project.yml).
• stacklok/claude-plugins's repo-local add-issues-to-project.yml is removed and replaced by a caller of the reusable workflow; its check-pr-issue-link.yml caller is repointed from StacklokLabs/workflow-templates to stacklok/.github.
• No public repo (from team-config.yaml or otherwise) has either workflow added.
• A new issue opened in each updated repo appears on project 73 (except stacklok-enterprise-platform, which is already covered) and a PR without a linked issue is flagged by check-pr-issue-link.yml.

Related

• Reusable workflow: feat: add add-issues-to-project reusable workflow #10
• Tracking issue for the reusable workflow itself: Auto-add new issues to the Stacklok Engineering board to reduce untracked/unlinked work #11