One blocked skill stalls every skill's update: the agent-skills updater shares a single branch

[devantler]

🤖 Generated by the Agent Improver

Evidence

update-agent-skills.yaml collects updates from every skill upstream into one branch
(deps/agent-skills-update) and therefore one pull request. #162 is direct evidence: a single PR
carrying both the suite-owned agentic-engineering/portfolio-maintenance update and third-party
gitops-kubernetes updates from fluxcd/agent-skills.

That makes the branch a shared conduit, so any one skill's blocker stops all of them:

• chore(deps): update agent skills #162 has been open since 2026-08-26 with one deliberately unresolved review thread — the
  gitops-repo-audit dotenv-sourcing finding tracked in gitops-repo-audit sources a caller-supplied dotenv, executing arbitrary commands with the auditor's credentials #164, which is correctly parked pending a
  third-party upstream decision.
• The last updater PR to merge was chore(deps): update agent skills #157 on 2026-08-24T07:59Z, so the pipeline has been stalled
  ~6.6 days.
• The updater rebuilds the same branch on each run (chore(deps): update agent skills #162's commits are dated 2026-08-30T06:17Z), so
  the stall is self-renewing rather than a one-off.
• Measured consequence at the pinned revision be60c800: the bundled
  plugins/agentic-engineering/skills/agent-improvement/SKILL.md is 32,197 bytes against
  34,070 bytes on devantler-tech/agent-skills@main. Suite-owned changes are merged upstream and
  absent here.

This is distinct from #164. #164 asks whether the third-party security defect gets fixed; this issue
is that an unrelated skill's blocker strands every other skill's update, which would remain true
for any future blocked skill regardless of how #164 is decided.

Affected audience and impact

Every consumer of the marketplace, and most sharply the agent roles whose definitions are delivered
this way. An improvement can be merged upstream, pass CI, and look shipped while never reaching the
runtime that loads it — for days, with no signal. The contract already warns that this "reads as a
completed rollout while nothing has actually shipped to this deployment".

It also corrupts measurement: an Improver hypothesis scored against a stranded intervention reads as
NOT-WORKING, which invites reverting a correct change and aiming the next cycle at a phantom
(devantler-tech/agent-skills#100 hardens the scoring side against that, but does not unstick delivery).

Expected behaviour

A blocked skill should strand only itself. Options, roughly in increasing effort:

• Emit one branch/PR per upstream, so a third-party block cannot hold suite-owned updates.
• Or keep one PR but allow a named skill to be pinned/excluded from the batch while it is blocked,
  so the remainder still flows.

Either way the shared-conduit coupling goes away and a parked security finding stops being a
portfolio-wide delivery outage.

Acceptance criteria

• A blocker on one skill's update no longer prevents other skills' updates from merging.
• The currently stranded suite-owned updates reach the marketplace without requiring gitops-repo-audit sources a caller-supplied dotenv, executing arbitrary commands with the auditor's credentials #164 to be
  resolved first.
• The mechanism is documented where the three-hop rollout is described, so a future stall is
  recognised rather than re-diagnosed.

Rough size: small-to-medium (one workflow, plus a docs line).