Does each skill install from the same repository intentionally mint a separate token?

[seesharprun]

When a workflow imports multiple skills from the same external repository using the same github-app block, the compiled lock file generates a separate token-minting step for each skill install; even when the app credentials and target repository are identical across all of them.

For example, a workflow with four skills sharing the same github-app via a YAML anchor:

skills:
  - github-app: &shared-reader-app
      client-id: ${{ vars.MY_APP_CLIENT_ID }}
      owner: my-org
      repositories:
        - my-skills-repo
    skill: my-org/my-skills-repo/skills/skill-a@<sha>
  - github-app: *shared-reader-app
    skill: my-org/my-skills-repo/skills/skill-b@<sha>
  - github-app: *shared-reader-app
    skill: my-org/my-skills-repo/skills/skill-c@<sha>
  - github-app: *shared-reader-app
    skill: my-org/my-skills-repo/skills/skill-d@<sha>

…produces four consecutive Generate GitHub App token for frontmatter skill N steps in the activation job, all with the same client-id and repositories value. Each step makes a separate API call to mint an installation access token for an identical scope.

Impact

Each token mint is a network round-trip during the activation job. With many shared-repo skills, this adds measurable latency; visible as four back-to-back Generate GitHub App token steps in the runner timeline before any skill install begins. For workflows running frequently or on slow runners, this compounds across runs.

Question

Is this intentional? A few possible reasons come to mind:

1. Security (token minimization): each token is scoped to a single operation and immediately discarded, so a leaked token has no residual value.
2. Audit trail: separate mint events give a clearer per-operation record in the GitHub App installation log.
3. Implementation simplicity: steps are generated independently and token reuse would require deduplication logic at compile time.

If this is a deliberate security design, I'd love to understand the reasoning so I can apply the same principle in my own custom safe-output jobs. If it's an optimization opportunity, deduplicating token minting for skills that share the same github-app block and repository would reduce API calls and activation latency.