---
title: 'In the News: November 8, 2026 (Midday)'
description: 'Dependabot can now open pull requests to update the agent skills, prompts and instructions a repository declares in apm.yml.'
canonical_url: 'https://darkfactory.dev/news/2026-11-08-midday'
markdown_url: 'https://darkfactory.dev/news/2026-11-08-midday.md'
collection: news
date_published: '2026-11-08T13:10:00-05:00'
date_modified: '2026-11-08T13:10:00-05:00'
---

# In the News: November 8, 2026 (Midday)


Agent skills and instructions can now be tracked as versioned dependencies and updated by pull request. Two other GitHub changes touch automation on pull requests: Agentic Workflows is generally available, and a default block on `pull_request_target` has its first brownout tomorrow.

## 1. Dependabot now opens pull requests for agent skills and prompts

**[Dependabot version updates support Agent Package Manager](https://github.blog/changelog/2026-11-03-dependabot-version-updates-support-agent-package-manager/)** · GitHub changelog · GitHub, November 3, 2026

GitHub says you can now keep "AI agent skills, prompts, and instructions" up to date with Dependabot version updates for Agent Package Manager (APM). Dependabot opens pull requests to update supported git dependencies declared in `apm.yml` and regenerates `apm.lock.yaml` when that file is present. To enable it, add an `apm` entry to `.github/dependabot.yml`, point it at the directory holding `apm.yml`, and pick a schedule.

The support covers version updates, not security updates. GitHub says it is generally available on github.com for all plans and will arrive in GitHub Enterprise Server 3.24.

**Why it matters:** If your harness pulls skills or instructions from other repositories, an update now arrives as a reviewable pull request instead of a silent change. That puts a changed skill through the same review and tests as a code change. The changelog does not say what those pull requests contain beyond version bumps, so check what one looks like before relying on it.

## 2. GitHub Agentic Workflows is generally available

**[GitHub Agentic Workflows generally available](https://github.blog/changelog/2026-10-28-github-agentic-workflows-generally-available/)** · GitHub changelog · GitHub, October 28, 2026

GitHub Next's open source project lets you write automation in Markdown for tasks such as issue triage, CI failure analysis, documentation updates and test writing, using Copilot or another coding agent inside GitHub Actions. The Markdown compiles to standard Actions YAML, so workflows reuse existing runner groups and policy constraints. By GitHub's account, agents run with read-only permissions by default in a sandboxed container behind a firewall, outputs go through a validation step, and a separate threat detection job scans proposed changes before they are applied.

The general availability release adds support for self-hosted ARC runners with Docker-in-Docker, a `gh aw forecast` command for AI credit spend, per-workflow model provider choice, model routing, and micro-VM isolation for agents.

GitHub's announcement includes figures from Ben Alton of Accenture's Strategy, Architecture & Innovation team: AI authors 91% of his team's commits, and production errors fell from about 11,000 a day to under 1,000. These are a customer's statements published by GitHub, with no method given.

**Why it matters:** The safeguards GitHub lists are the ones a team would otherwise build for itself: read-only defaults, a sandbox, validated outputs and a scan before changes land. The page describes them without testing them, so treat them as claims until you have run a workflow against your own repository.

## 3. GitHub will block `pull_request_target` by default in public repositories

**[pull_request_target blocked by default December 2](https://github.blog/changelog/2026-11-02-pull_request_target-blocked-by-default-december-2/)** · GitHub changelog · GitHub, November 2, 2026

Starting December 2, 2026, GitHub Actions will block `pull_request_target` events by default in all public repositories unless an Actions event policy explicitly allows them. Enforcement was previously scheduled for November 2. Private and internal repositories are not affected. The trigger runs in the base repository's context with access to its secrets, which is why a workflow that runs untrusted fork code under it can leak them.

Two brownouts come first, on November 9 and November 16, each from 16:00 to 18:00 UTC. During those windows, blocked workflows fail with an error annotation and do not run. Insights shows which runs the rule would block.

**Why it matters:** If a public repository's automation reacts to fork pull requests through this trigger, the first failures arrive tomorrow. The changelog does not mention agents, so whether your agent-driven workflows use it is something to check in your own workflow files.