Using GitHub Copilot with Repository Custom Properties

Managing a large number of repositories becomes difficult once an organization grows.

A team may have hundreds or even thousands of repositories, and each repository can have different requirements.

For example:

Is the application production-facing?
Which team owns it?
Which environment does it belong to?
Does it contain sensitive data?
What compliance level applies to it?
Is it an internal or external service?

GitHub repository custom properties provide a structured way to store this kind of metadata. Organizations can use those properties to organize repositories, search and filter them, and target repositories with rulesets.

GitHub has also added a Copilot feature that can suggest allowed values when administrators create repository custom property definitions. The feature is currently available in public preview for GitHub Copilot Business and Enterprise plans.

This makes it easier to build a consistent repository metadata model without manually thinking through every possible value.

What Are Repository Custom Properties?

A custom property is structured metadata attached to a repository.

Imagine an organization has the following repositories:

orders-api
customer-portal
payment-service
internal-tools
reporting-service

You could define properties such as:

environment
team
application-type
internet-facing
compliance

A repository might then have values such as:

Repository: payment-service

environment: production
team: payments
application-type: api
internet-facing: yes
compliance: regulated

The important difference from putting this information in a README is that custom properties are structured.

That means GitHub can use them for repository searches, filtering, and governance scenarios.

Why Custom Properties Matter

Without structured metadata, organizations often maintain spreadsheets or naming conventions.

For example:

payment-service-prod
customer-api-internal
orders-api-prod
orders-api-dev

The problem is that names are not a reliable governance system.

A repository can be renamed.

Different teams can use different naming conventions.

And after several years, nobody may remember what a particular suffix means.

Custom properties separate repository identity from repository metadata.

Instead of:

payment-service-prod

you can have:

payment-service

environment = production

That is easier to search and automate.

Where GitHub Copilot Fits In

Creating the property itself is not particularly difficult.

The harder part is deciding what values should be allowed.

Suppose you create this property:

internet-facing

You could define:

yes
no

For another property:

compliance

you might need:

none
internal
regulated
restricted

The challenge becomes more obvious when an organization has many teams.

Different administrators may choose slightly different values:

Production
production
prod
PROD

These values may mean the same thing to people, but they are different values from a governance and automation perspective.

GitHub Copilot can now suggest allowed values while you create a custom property definition.

How Copilot Suggestions Work

The new feature is designed around the property definition process.

For example, imagine creating a multi-select property:

Property name:
FedRAMP

Copilot can suggest relevant allowed values such as:

Low
Moderate

Similarly, if you create a single-select property:

internet-facing

Copilot can suggest:

yes
no

You can then accept a suggestion or refresh the suggestions instead of manually creating every value.

The important point is that Copilot is helping with the definition of the metadata schema.

It is not automatically deciding the final governance policy for your organization.

Administrators still need to review the suggestions.

Creating a Useful Property Model

Before asking Copilot for suggestions, think about what information your organization actually needs.

A simple model could look like this:

Property	Type	Example Values
environment	Single select	development, staging, production
team	Single select	payments, platform, data
application-type	Single select	API, web, worker
internet-facing	Single select	yes, no
compliance	Multi-select	internal, regulated
criticality	Single select	low, medium, high

This gives your repositories a consistent vocabulary.

Do not create dozens of properties simply because you can.

Each property should have a clear purpose.

Use Properties for Governance Metadata

A good property describes something about the repository that is useful outside the source code itself.

For example:

team = payments

can help identify ownership.

environment = production

can help identify operational importance.

internet-facing = yes

can help identify repositories that may require additional security controls.

compliance = regulated

can help identify repositories that require additional governance.

These values can then be used with GitHub's repository management and ruleset capabilities.

Custom Properties and Rulesets

One of the useful reasons to keep metadata structured is that custom properties can be used to target repositories with rulesets.

Consider:

internet-facing = yes

An organization may want additional repository rules for this group.

The relationship can be thought of as:

Repository
    |
    v
Custom Property
    |
    v
Repository Selection
    |
    v
Ruleset

This is much easier to maintain than manually selecting hundreds of repositories.

For example, if a new repository receives:

internet-facing = yes

it can fall into the same governance scope as other repositories with that property.

Choosing Property Types Carefully

The property type matters.

Suppose you need to store whether a service is internet-facing.

A single-select property makes sense:

internet-facing

yes
no

For technology ownership, you might use:

team

platform
payments
data
frontend

For a repository that can belong to multiple compliance categories, a multi-select property may be more appropriate:

compliance

internal
PCI
SOC2
FedRAMP

The property design should reflect how the information will actually be used.

Single Select vs Multi Select

Single Select

Use a single-select property when only one value should apply.

Example:

environment

development
staging
production

A repository should normally have one primary environment classification.

Multi Select

Use multi-select when multiple values can apply simultaneously.

Example:

compliance

internal
regulated
FedRAMP

A repository might need more than one classification.

Copilot's new suggestions can be particularly useful when administrators are creating allowed values for these property types.

A Practical Example

Imagine an organization manages several .NET applications.

You decide to create these properties:

runtime
owner-team
environment
internet-facing
criticality

For runtime, the values could be:

.NET
Java
Node.js
Python
Go

For environment:

development
staging
production

For criticality:

low
medium
high

You can then assign values to individual repositories.

For example:

Repository: orders-api

runtime: .NET
owner-team: commerce
environment: production
internet-facing: yes
criticality: high

Now the repository carries useful metadata that can be searched and used by governance processes.

Using the GitHub API

Custom properties can also be managed programmatically.

GitHub provides REST API endpoints for reading and updating repository custom property values. The current API documentation includes an endpoint for creating or updating property values on a repository.

A request can conceptually look like this:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  https://api.github.com/repos/OWNER/REPO/properties/values

A response can contain values such as:

[
  {
    "property_name": "environment",
    "value": "production"
  },
  {
    "property_name": "service",
    "value": "web"
  },
  {
    "property_name": "team",
    "value": "commerce"
  }
]

The exact permissions and authentication method should follow your organization's GitHub security policy. The API supports fine-grained permissions for managing repository custom property values.

Automating Property Updates

Once your organization has defined a stable metadata model, automation becomes useful.

For example, a provisioning process could create a repository and then assign its initial properties.

Conceptually:

Create Repository
       |
       v
Set Owner
       |
       v
Set Environment
       |
       v
Set Application Type
       |
       v
Apply Governance Rules

This reduces the amount of manual configuration required when new repositories are created.

However, automation should not blindly assign values.

The source of each value should be clear.

Keep Property Values Consistent

One of the biggest benefits of custom properties disappears if teams use inconsistent values.

Avoid:

prod
production
Production
PROD

Pick one convention.

For example:

production

Then use it everywhere.

The same applies to team names.

Avoid:

Platform
platform-team
platform
Platform Engineering

if all of them refer to the same ownership group.

Define a controlled vocabulary.

Let Copilot Suggest, But Review the Result

Copilot suggestions can save time, but suggestions should not become an automatic governance policy.

For example, if you create:

data-classification

Copilot might suggest values that appear reasonable.

Before accepting them, ask:

Do these categories match our internal policy?
Are any categories missing?
Are two values effectively duplicates?
Will teams understand them?
Can automation use them consistently?
Are the names stable enough for long-term use?

Copilot can help generate ideas, but the organization should own the final taxonomy.

Avoid Overusing Custom Properties

It is easy to create too much metadata.

For example:

team
department
business-unit
owner
technical-owner
application-owner
service-owner

If all of these represent nearly the same thing, the metadata model becomes harder to maintain.

A better model might be:

owner-team

with a clear definition.

Every property should answer a useful question.

For example:

Who owns this repository?
What environment is it for?
Is it externally exposed?
What compliance category applies?
How critical is it?

If nobody uses the answer, the property may not be necessary.

Custom Properties vs README Metadata

A README is still useful.

But the two serve different purposes.

Requirement	README	Custom Property
Human documentation	Good	Limited
Structured filtering	Poor	Good
Repository governance	Limited	Good
Ruleset targeting	Not designed for it	Supported
Long-form explanation	Good	Poor
Automation	More difficult	Better suited

Use a README for information developers need to read.

Use custom properties for structured metadata that GitHub and automation need to understand.

Custom Properties vs Repository Topics

Repository topics are also useful for classification.

For example:

dotnet
api
microservices
kubernetes

Topics are useful for discoverability and general categorization.

Custom properties are better suited to organization-specific structured metadata.

For example:

environment = production
criticality = high
owner-team = payments

These are governance fields rather than general repository topics.

Copilot Custom Instructions Are Different

There is another GitHub Copilot feature that can easily be confused with repository custom properties.

Copilot custom instructions provide context about how Copilot should work with a project.

For example, a repository can contain:

.github/copilot-instructions.md

The file can explain coding conventions, project structure, testing practices, and other instructions that Copilot should consider.

For example:

# Project Guidelines

- Use C# nullable reference types.
- Use xUnit for tests.
- Prefer async APIs for I/O operations.
- Follow the repository naming conventions.
- Run unit tests before submitting changes.

This tells Copilot how to work with the codebase.

Custom properties answer a different question:

What metadata describes this repository?

So:

Custom Instructions
        |
        v
How should Copilot work?


Custom Properties
        |
        v
What metadata describes this repository?

They can complement each other, but they are not interchangeable.

A Good Repository Metadata Strategy

For a growing organization, a simple strategy works well.

Step 1: Identify Important Metadata

Start with information that is genuinely useful.

Step 2: Define a Small Vocabulary

Avoid creating unnecessary values.

Step 3: Use Copilot for Suggestions

When defining new properties, review Copilot's suggested values.

Step 4: Standardize the Values

Remove duplicates and ambiguous names.

Step 5: Assign Properties

Apply values to existing repositories.

Step 6: Connect Governance

Use properties where appropriate for repository selection and rulesets.

Step 7: Review Periodically

Repositories change.

Teams change.

Applications move between environments.

Your metadata model should be reviewed as the organization evolves.

Common Mistakes

Treating Suggestions as Policy

Copilot suggestions are not a replacement for organizational governance.

Creating Too Many Properties

Start small and add properties only when there is a clear use case.

Allowing Duplicate Values

prod, production, and Production should not become three different values for the same concept.

Using Free-Form Text Everywhere

Free-form values make automation and filtering harder.

Where possible, use controlled values.

Mixing Documentation With Metadata

Do not try to put complete architectural documentation into a custom property.

Keep detailed explanations in documentation.

Ignoring Ownership

Someone should be responsible for maintaining the property definitions and allowed values.

Without ownership, metadata becomes stale.

Best Practices

Keep Names Clear

Prefer:

internet-facing

over:

if

A property name should be understandable without additional explanation.

Use Stable Values

Prefer:

production

over values tied to temporary team terminology.

Document the Meaning

For each property, define what it means.

For example:

criticality

low    = limited business impact
medium = moderate business impact
high   = significant business impact

This prevents different teams from interpreting the same value differently.

Review Copilot Suggestions

Use suggestions as a starting point.

Validate them against your organization's actual requirements before accepting them.

Automate Carefully

Once the taxonomy is stable, use APIs or repository-management automation to keep values consistent. GitHub provides REST APIs for reading and updating repository custom property values.

Summary

Repository custom properties provide a structured way to describe GitHub repositories.

They can capture information such as:

owner-team
environment
application-type
internet-facing
criticality
compliance

That metadata can then be used for repository organization, filtering, automation, and ruleset targeting.

The newer GitHub Copilot capability can suggest allowed values when administrators create custom property definitions. This can make the initial design of a repository metadata model easier, especially when the right vocabulary is not obvious.

The important part is still human review.

Copilot can suggest values, but your organization should decide what those values mean and which ones should become part of the official repository taxonomy.

For teams managing a large GitHub environment, the combination of structured repository metadata, consistent property values, automation, and governance rules can make repository management much easier to scale.