Build Copilot Extensions faster with skillsets

Skillset header image

Today we’re introducing skillsets, a new lightweight way to build GitHub App-based Copilot Extensions alongside our existing agents approach. While agents offer full control over the user interaction, skillsets make it easy to integrate external tools and services into Copilot Chat by defining simple API endpoints – no AI expertise needed!

What’s new ✨

  • Let Copilot handle all AI interactions and response formatting
  • Define up to 5 skill endpoints that Copilot can call
  • Simple JSON schema configuration
  • Quick setup with minimal code

Benefits for builders ⚡️

  • Faster Development: Focus on your core functionality instead of AI interactions
  • Simple Implementation: Just define API endpoints, without managing LLM logic
  • Minimal Setup: No complex server infrastructure required, with the option to use existing APIs
  • Consistent Experience: Copilot maintains natural chat interactions automatically

Choosing your integration path 🛠

  1. Skillsets: Perfect for straightforward integrations like data retrieval and basic actions. You provide the API endpoints, and Copilot handles workloads like prompt crafting and response generation.
  2. Agents: Ideal for complex workflows needing custom logic, flexible prompt crafting, or specific LLM models. You control the entire interaction.

How it works 🏗️

End users interact with skillset-based extensions just like any other Copilot Extension. Just type @ followed by the extension name and ask in natural language. Behind the scenes, Copilot:

  • Analyzes the query to determine which skill to call
  • Structures the API request based on your JSON schema
  • Calls your endpoint to get the data
  • Formats and generates the response in chat

Architecture

architecture diagram

Requirements for extension builders

  • Access to GitHub Copilot
  • For organizational builds: Free, Team, or supported Enterprise Cloud organization types
  • Skillsets only apply to extensions built as GitHub Apps, and not VS Code chat participants

Getting started 🚀

Check out our documentation to learn how to build your first skillset.

Already built a Copilot Extension as an agent? Existing agent extensions can be converted into skillsets, but one extension cannot be both a skillset and an agent.

We want to hear your feedback!

We’re excited to introduce persistent commit signature verification, a powerful new feature designed to elevate the security and reliability of your repository’s commit history.

Starting today, GitHub verifies commit signatures when they are first pushed, and once a commit’s signature is verified, it remains verified within its repository’s network. This supports organizations in maintaining a secure and accurate record of contributions without constantly rechecking the validity of every signature. You can view these persistent verifications directly on GitHub, where a quick hover over the Verified badge displays the timestamp of the original verification.

Efficient, Secure, and Transparent Verification

Previously, commit signatures were verified on demand, via a process that was not performant and had risks of previously verified signatures becoming “unverified” due to various reasons like service outages or key rotations.

Persistent commit signature verification solves these issues by validating signatures at the time of the commit and storing the verification details permanently. This also brings consistency to the commit history as git commits are immutable and they do not natively support key rotation.

Managing commit signatures can be a challenge, but persistent records ensures that verified commits remain verified over time, even if signing keys are rotated, revoked, or contributors leave the organization.

How to tell if the verification has a persistent record?

When a commit’s signature is verified upon being pushed to GitHub, the verification record is stored alongside the commit. This record is immutable, ensuring that the verified status is maintained permanently.

You can view the verification timestamp by hovering over the Verified badge on GitHub or via the GitHub REST API which now includes a verified_at field.

Learn more about commit signature verification on GitHub.

Designed for Real-World Key Rotation and Contributor Management

For organizations managing signature verification – whether GPG, SSH, or X.509 keys using S/MIME – persistent commit signature verification provides a robust way to ensure signature integrity across the board. Now, any commit with a verified status can retain that status, even when the signing key is rotated or removed.

Persistent commit signature verification is applied to new commits only. For commits pushed prior to this update, persistent records will be created upon the next verification, which happens when viewing a signed commit on GitHub anywhere the verified badge is displayed, or retrieving a signed commit via the REST API. This ensures that your repository remains secure while providing flexibility in managing your verification practices.

This approach lays the groundwork for future improvements aimed at enhancing repository integrity and authenticity of contributions within GitHub.

Key Management Caveat: Revocation and Expiration

Persistent commit signature verification ensures that verified commits retain their status indefinitely, it’s important to note this records the state of the signature at the time of the commit. If a signing key is later revoked, expired, or otherwise changed, GitHub will not re-verify previously signed commits or retroactively modify the verification status.

For organizations using S/MIME keys, this does introduce a minor change: revoked S/MIME keys will not verify new commits or those without an existing persistent record. Since git commits are immutable, persistent commit signature verification aligns with this concept by maintaining the original verification status without change. Organizations may need to manage key states directly to align with their security policies, especially in cases involving frequent key rotation or revocation.

This approach ensures that once a commit is verified, it remains trusted based on the record at the time, bringing consistency and long-term reliability to your commit history.

Moving Towards a Future with Secure and Authentic Contributions

With this launch, we’re addressing a key issue: commit verification that isn’t fragile or temporary. Teams can now implement signing key policies, without worrying about losing the verified status of past work.

Stay tuned for more updates as we continue to enhance commit verification. If you have feedback or suggestions, please let us know through our GitHub Discussions forum.

See more

The GitHub Enterprise Server 3.15 release candidate is here

You can now download the GitHub Enterprise Server 3.15 release candidate to try out the new features in this latest version. Version 3.15 gives customers enhanced deployment requirements and security controls. Here are a few more highlights in the 3.15 release:

  • We have updated root disk size requirements. New installations of GitHub Enterprise Server version 3.15 and upgrades to 3.15 now require a root disk size of at least 400GB. System will not boot otherwise. For more information on how to increase the root disk size in the appliance, see increasing storage capacity.
  • We have also updated minimum server specs recommended to run GHES. For more information, see minimum recommended requirements.

  • You can now interact with project status updates using GraphQL and webhooks. This unlocks new ways to automate how you provide and gather project status update information. For more information, see GitHub Projects.

  • Custom properties now support new property types: multi select and true/false. Organization repositories can now be queried and filtered via properties. Both the UI and API are supported. Read about filtering repositories.

  • Code security configurations are now available in GHES. These configurations simplify the rollout of GitHub security products at scale. They help you define collections of security settings and apply them across groups of repositories. We have retired the old organization-level code security settings UI experience along with the API parameters that complemented it. For more information, see code security configurations.

  • Secret scanning push protection is now supported for content upload REST API endpoints – create a blob and create or update file contents. Push protection blocks you from pushing secrets to a repository and generates a secret scanning alert whenever you bypass the block.

  • CodeQL‘s support for Swift and Kotlin is now generally available. CodeQL is the static analysis engine that powers GitHub code scanning.

  • Organization owners can now grant a user or team access to all of the repositories in their org with a single click. New pre-defined roles have been added to the organization settings, under Organization Roles > Role Management, where all organization owners can view and assign them. These can be further customized as well to grant specific repository permissions across your organization. For more information, see organization roles.

Release Candidates are a way for you to try the latest features early, and they help us gather feedback to ensure the release works in your environment. They should be tested on non-production environments. Read more about the release candidate process.

To learn more about GHES 3.15, check out release notes, or download the 3.15 release candidate now.

If you have any feedback or questions about the release candidate, please contact our Support Team.

See more