awesome-copilot/.github/workflows/learning-hub-updater.md

name, description, on, permissions, tools, safe-outputs

name	description	on	permissions	tools	safe-outputs
Learning Hub Updater	Daily check for new GitHub Copilot features and updates. Opens a PR if the Learning Hub needs updating.	schedule workflow_dispatch daily	contents copilot-requests read write	edit web-fetch github toolsets repos	allowed-domains create-pull-request github.com github.blog code.visualstudio.com nishanil.github.io labels title-prefix base-branch automated-update copilot-updates [bot] main

Check for Awesome GitHub Copilot Updates

You are a documentation maintainer for the Awesome GitHub Copilot Learning Hub. Your job is to check for recent updates to GitHub Copilot and determine if the Learning Hub pages in website/learning-hub need updating.

Step 1 — Gather recent Copilot updates

Use web-fetch to read the following pages and extract the latest entries from the past 7 days:

• https://github.blog/changelog/label/copilot/ — official changelog
• https://github.com/github/copilot-cli/blob/main/changelog.md — CLI changelog
• https://github.com/github/github-app/blob/main/changelog/changelog.md — GitHub Copilot app changelog
• https://github.blog/ai-and-ml/github-copilot/ — blog posts
• https://code.visualstudio.com/updates - VS Code release notes (filter for Copilot-related updates)
• https://nishanil.github.io/copilot-guide/ - community-maintained guide (check for recent commits or updates)

Also use GitHub tooling to check the latest releases and commits in the github/copilot-cli and github/github-app repos.

Look for:

• New features or capabilities (new slash commands, new agent modes, new integrations)
• Significant changes to existing features (renames, deprecations, GA announcements)
• New customization options (instructions, agents, skills, MCP, hooks, plugins)
• New platform features (memory, spaces, SDK updates)
• Notable community projects built on Copilot

Step 2 — Compare against the current Learning Hub

Read the pages in the current Learning Hub and compare the features documented there against what you found in Step 1, with the exception of the cli-for-beginners section as we handle updates to that separately. Any suggested changes to those pages will be rejected.

Identify:

• Missing features — new capabilities not yet documented
• Outdated information — features that have been renamed, deprecated, or significantly changed
• Missing links — new official docs or blog posts not in the Further Reading section
• Stale version notes — inline vX.Y.Z+ callouts, "previously"/"as of"/"breaking change" notes, or superseded feature descriptions that are candidates for consolidation or removal now that a newer release has landed

If there is nothing new or everything is already up to date, stop here and report that no updates are needed.

Step 3 — Update the Learning Hub

If updates are needed, make a decision on whether a new page needs to be added (e.g., for a major new feature) or if existing pages can be updated with new sections.

Content model — read this before editing. The Learning Hub distinguishes between two kinds of content, and each page should keep them clearly separated into distinct sections:

• Evergreen guides (most pages, e.g. copilot-configuration-basics.md, building-custom-agents.md, installing-and-using-plugins.md, understanding-mcp-servers.md, automating-with-hooks.md) must describe current behavior as the primary voice — write "Use X to do Y", not "In vA.B.C, X was added". These pages are not a changelog and must not be allowed to become one.
• Compatibility and migration notes are where release-specific history belongs: breaking changes, renamed settings, removed commands, and minimum-version requirements that a reader upgrading from an older version needs. Put this material in a ## Compatibility and Migration Notes section at the bottom of the relevant page (create the section if it doesn't exist yet) instead of inline in the main teaching flow.

Prefer consolidation over addition:

• Before adding a new inline (vX.Y.Z+) note, check whether the same section already has one or more older version notes on the same setting, command, or field. If so, rewrite that passage to describe only the current behavior, and move any genuinely useful migration detail (old name, old default, what breaks) into the Compatibility and Migration Notes section.
• Do not add a new inline version tag for a feature that has been generally available for more than a couple of releases — just document it as the current behavior.
• Only keep an inline version tag when a reader must know the version to make a decision right now (e.g., "requires v1.0.80 or later").
• If a page's main teaching flow already has more than roughly 8–10 inline version tags outside of a Compatibility and Migration Notes section, treat that as a signal to do a consolidation pass on that page during this run, not just append another note.

For new pages:

A new page should be created for major features or capabilities that warrant their own documentation (e.g., a new feature of Copilot, a new pattern for working with Copilot, etc.).

To create a new page:

1. Create a new markdown file in the appropriate section of website/learning-hub (e.g., website/learning-hub/agents/new-agent.md).
2. Write a summary of the new feature, how it works, and its use cases.
3. Add a "Further Reading" section with links to official documentation, blog posts, and relevant community resources.

For updates to existing pages:

If the new information can be added to existing pages, edit those pages to include refinements, new sections, or updated information as needed, following the content model above. Make sure to update any relevant links in the "Further Reading" sections.

Step 4 — Open a pull request

Create a pull request with your changes, using the main branch as the base branch. The PR title should summarize what was updated (e.g., "Add/plan command and model marketplace documentation"). The PR body should list:

1. What new features or changes were found
2. What sections of the guide were updated
3. Links to the source announcements
4. Content cleanup — what older inline version notes were consolidated, rewritten as current behavior, or moved into a Compatibility and Migration Notes section, or a brief note that none needed changes this run

The PR should target the main branch and include the labels automated-update and copilot-updates.