How GitHub Copilot Helps Set Repository Custom Properties

Managing repository information becomes harder as a GitHub organization grows.

A small team may have ten repositories and know exactly what each one does. A larger organization can have hundreds of repositories owned by different teams, running different technologies, and serving different environments.

At that point, simple repository names are not enough.

You may want to know:

Which team owns a repository?
Is it used in production?
Is it customer-facing?
What type of application is it?
What compliance requirements apply?
How critical is the application?

GitHub repository custom properties are designed to store this kind of structured information. Organizations can define custom properties and assign values to repositories, making the information easier to search, filter, and use for repository management.

GitHub has also introduced Copilot-assisted suggestions for custom property definitions. Instead of starting with an empty list of allowed values, administrators can ask Copilot for suggestions and then review those values before using them.

The useful part is not simply generating values faster. It is using Copilot to get a starting point while keeping the final repository metadata under human control.

What Are Repository Custom Properties?

A repository custom property is structured metadata associated with a repository.

For example, an organization could define:

owner-team
environment
application-type
criticality
internet-facing

A repository could then have values such as:

Repository: orders-api

owner-team: commerce
environment: production
application-type: API
criticality: high
internet-facing: yes

This information is different from source code.

It describes the repository and the application it represents.

GitHub allows organizations to define custom properties with different types, including single-select, multi-select, and other supported property types.

Why Repository Metadata Becomes Important

Repository metadata is easy to ignore when an organization is small.

Suppose your organization has five repositories:

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

Everyone probably knows what they are.

Now imagine 500 repositories.

The repository list might contain:

orders-api
orders-worker
orders-events
customer-api
customer-worker
customer-ui
...

Names alone do not tell you:

Who owns each application
Which environment it supports
Whether it is externally accessible
Whether it is business-critical
Whether additional security controls apply

Structured properties solve this problem.

Where GitHub Copilot Helps

Creating a property is straightforward.

The difficult part is often deciding which values belong to it.

For example, suppose you create:

Property:
application-type

You might initially think of:

API
Web
Worker
Library

But another administrator may think of:

Backend
Frontend
Service
CLI
Function

Both lists can be reasonable.

Copilot can help generate suggestions for allowed values while you define the property. GitHub's September 2026 announcement describes this feature as a way for Copilot to suggest values for custom property definitions.

You can then review the suggestions and decide which values actually make sense for your organization.

Copilot Is Helping With the Schema

This distinction is important.

Copilot is not simply filling random repository fields.

The feature helps administrators while defining the allowed values for a custom property.

Think of the process like this:

Administrator
      |
      v
Create Property
      |
      v
Describe Property
      |
      v
Copilot Suggestions
      |
      v
Review Values
      |
      v
Save Property Definition

The administrator remains responsible for the final definition.

That makes the feature more useful than simply generating arbitrary metadata.

A Simple Example

Imagine you want to classify repositories by application type.

You create:

application-type

The property could use a single-select field.

You need to decide which values should be allowed.

Instead of manually creating the list from scratch, Copilot can provide suggestions.

You might end up with a list such as:

API
Web Application
Worker
Library
CLI

You should then review the list.

If your organization does not build CLI applications, there is no reason to keep that value.

Likewise, if your organization distinguishes between frontend and backend applications, you may want a different taxonomy.

Build a Property Model Before Using Copilot

Copilot is more useful when you already understand the information you want to manage.

Start by asking:

What do we need to know about our repositories?

A reasonable initial model might be:

Property	Purpose
owner-team	Identifies the responsible team
environment	Identifies the primary environment
application-type	Describes the application
criticality	Indicates business importance
internet-facing	Identifies externally accessible applications
compliance	Identifies applicable requirements

This gives Copilot a useful context for suggesting values.

Example: Environment

Consider this property:

environment

A simple value set might be:

development
staging
production

This is a good example of a property that should remain simple.

Do not create:

dev
development
DEV
test
testing
qa
stage
staging
prod
production

unless these genuinely represent different states in your organization.

The goal is consistent metadata.

Example: Application Type

For:

application-type

you might define:

API
Web
Worker
Library
CLI

The exact values should depend on your organization's architecture.

For example, a company with serverless workloads might need:

Function

while another organization may not need it.

This is where Copilot suggestions can save time, but human review is still necessary.

Example: Criticality

Consider:

criticality

You could use:

low
medium
high

But before adopting these values, define what they mean.

For example:

low
    Limited business impact

medium
    Noticeable business impact

high
    Significant business impact

The labels themselves are not enough.

Different teams may interpret "high" differently unless the organization defines the classification.

Single-Select Properties

Single-select properties are useful when a repository should have one value from a controlled list.

For example:

environment

development
staging
production

Another example:

criticality

low
medium
high

The advantage is consistency.

Automation can safely look for:

environment = production

without worrying about variations such as prod or Production.

Multi-Select Properties

Some information cannot be represented by a single value.

Compliance is a common example.

A repository could potentially belong to multiple categories:

compliance

SOC 2
PCI
FedRAMP
Internal

A multi-select property allows more than one value to be assigned.

The important thing is to define the categories carefully.

If two values overlap heavily, users may not know which one to select.

Do Not Let Copilot Design Your Governance Policy

This is probably the most important practical point.

Copilot can suggest values.

It should not be treated as the authority for your organization's governance model.

For example, suppose Copilot suggests:

criticality

Low
Medium
High
Critical

That does not mean your organization should automatically adopt all four.

Ask:

Does our organization actually use these classifications?
What does each classification mean?
Can teams consistently assign them?
Will automation depend on them?
Are these terms already used elsewhere?
Do security or compliance teams have existing definitions?

The final taxonomy should come from your organization's requirements.

Using Properties With Repository Governance

Custom properties become more valuable when they are connected to governance workflows.

For example:

internet-facing = yes

could identify repositories that require additional controls.

Conceptually:

Repository
    |
    v
Custom Property
    |
    v
Repository Selection
    |
    v
Governance Rule

GitHub supports using custom properties to target repositories with rulesets, which can help organizations apply repository governance consistently.

This is one reason to avoid arbitrary property values.

If automation depends on them, consistency becomes important.

Custom Properties and Copilot Instructions Are Different

GitHub Copilot also supports repository-level instructions.

For example:

.github/copilot-instructions.md

can contain project-specific guidance for Copilot.

It might say:

# Development Guidelines

- Use nullable reference types.
- Prefer async APIs for I/O.
- Write unit tests for business logic.
- Follow the existing naming conventions.

This tells Copilot how it should work with the repository.

Custom properties answer a different question:

What describes this repository?

Copilot instructions answer:

How should Copilot work with this repository?

They solve different problems.

Automating Property Assignment

Once property definitions are established, organizations can also manage property values programmatically.

GitHub provides REST API support for repository custom properties, including reading and updating property values.

For example, a provisioning system could conceptually perform:

Create Repository
       |
       v
Assign Owner
       |
       v
Assign Application Type
       |
       v
Assign Environment
       |
       v
Apply Repository Rules

This can be useful when new repositories are created regularly.

Instead of asking every developer to manually configure metadata, the repository provisioning process can assign standard values.

Example API Request

A repository custom property update can be performed through GitHub's REST API.

A simplified request looks 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/REPOSITORY/properties/values

The actual request body and permissions depend on the properties you are updating and the authentication model used by your organization.

Do not put access tokens directly into source code or commit them to a repository.

Keep Property Names Stable

Once automation starts depending on a property, changing its name can have consequences.

For example:

owner-team

might be referenced by scripts and governance rules.

Renaming it to:

team-owner

could require changes in several places.

Treat important property definitions as part of your organization's configuration model.

Before creating a property, decide:

What does it mean?
Who owns it?
What values are allowed?
Who updates it?
Which automation depends on it?

Avoid Free-Form Metadata When Possible

Suppose you create:

owner-team

as a free-text field.

One repository might contain:

Payments

another:

payments

and another:

Payment Team

A human can understand that these may refer to the same group.

An automation script cannot safely assume that.

Controlled values are easier to search and automate.

For example:

payments
platform
data
commerce

is much cleaner.

Create a Small Taxonomy

Do not start with 30 properties.

A practical first version could contain only:

owner-team
environment
application-type
criticality

After using them for a while, identify gaps.

Maybe your security team needs:

internet-facing

Add it later.

Maybe compliance needs:

compliance

Add that when there is a real requirement.

This keeps the metadata model manageable.

Review Existing Repositories

Creating the definition is only half the job.

You also need to apply the properties to existing repositories.

Suppose your organization has:

500 repositories

and only:

50 repositories

have property values.

The metadata model will not provide much value until the remaining repositories are classified.

A migration can be handled gradually:

500 repositories
       |
       v
Classify critical repositories
       |
       v
Classify production repositories
       |
       v
Classify remaining repositories

Automation can help once the rules for assigning values are well defined.

Common Mistakes

Creating Properties Without a Use Case

Do not create a property simply because it sounds useful.

Ask how the organization will use it.

Accepting Every Copilot Suggestion

Suggestions are a starting point, not an organizational standard.

Review them.

Using Similar Values

Avoid:

prod
production
Production

when all three mean the same thing.

Mixing Different Concepts

Do not make one property responsible for several unrelated concepts.

For example:

team-and-environment

is harder to manage than:

owner-team
environment

Making Everything Free-Form

Free-text metadata is harder to filter and automate consistently.

Forgetting Property Ownership

Someone should be responsible for maintaining the definition.

Otherwise, old values remain long after the organization has changed.

A Practical Workflow

A simple workflow for introducing Copilot-assisted custom properties can look like this.

Step 1: Identify the Information

List the repository information your organization actually needs.

Step 2: Create the Property

Give it a clear name and description.

Step 3: Choose the Property Type

Decide whether the property needs a single value, multiple values, or another supported type.

Step 4: Use Copilot Suggestions

Use Copilot to generate a starting point for allowed values where appropriate.

Step 5: Review the Suggestions

Remove values that do not apply.

Combine duplicates.

Add organization-specific values when necessary.

Step 6: Define the Meaning

Document what each value represents.

Step 7: Apply the Properties

Assign values to repositories.

Step 8: Connect Automation

Use APIs, repository management workflows, or governance rules where appropriate.

Step 9: Review Periodically

Remove obsolete values and update definitions when organizational requirements change.

A Practical Example for a .NET Team

Imagine a company with several .NET services.

The team creates these properties:

runtime
application-type
environment
owner-team
criticality

A repository might look like:

Repository:
customer-api

runtime:
.NET

application-type:
API

environment:
production

owner-team:
customer-platform

criticality:
high

Another repository could be:

Repository:
invoice-worker

runtime:
.NET

application-type:
Worker

environment:
production

owner-team:
billing

criticality:
medium

Now the organization can distinguish the repositories without relying on repository names or README files.

When Copilot Provides the Most Value

Copilot-assisted suggestions are particularly useful when:

You are creating a new property.
The allowed values are not obvious.
Multiple administrators manage repositories.
You want to explore possible classifications.
You are building an initial metadata model.

It is less useful when the organization already has a formally defined taxonomy.

If your security team has already defined exactly which compliance classifications are allowed, use that approved list rather than replacing it with generated suggestions.

Best Practices

Keep Definitions Simple

A property should represent one clear concept.

Use Consistent Naming

Use predictable property names such as:

owner-team
environment
application-type

Keep Values Controlled

Avoid unnecessary variations.

Document Meaning

A value without a clear definition can be interpreted differently by different teams.

Review Before Automation

Do not build automation around a property until its definition is stable.

Keep Human Review

Copilot can speed up the design process, but the organization should remain responsible for the final metadata model.

Summary

GitHub repository custom properties give organizations a structured way to describe and classify repositories.

Instead of relying only on repository names, README files, or manually maintained spreadsheets, teams can store information such as:

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

GitHub Copilot can help administrators create custom property definitions by suggesting allowed values.

The real value comes from combining those properties with consistent repository management and automation.

A good approach is simple:

Define the information
        |
        v
Create the property
        |
        v
Use Copilot for suggestions
        |
        v
Review and standardize values
        |
        v
Assign repositories
        |
        v
Automate where useful

Copilot can reduce the effort involved in creating the initial property model, but it should not replace organizational decisions about classification and governance.

For a growing GitHub organization, a small, well-defined set of repository properties is usually more useful than a large collection of loosely defined fields. Once those properties become consistent, they can support better repository discovery, automation, and governance across the organization.

Managing repository information becomes harder as a GitHub organization grows.

At that point, simple repository names are not enough.

You may want to know:

Which team owns a repository?
Is it used in production?
Is it customer-facing?
What type of application is it?
What compliance requirements apply?
How critical is the application?

The useful part is not simply generating values faster. It is using Copilot to get a starting point while keeping the final repository metadata under human control.

What Are Repository Custom Properties?

A repository custom property is structured metadata associated with a repository.

For example, an organization could define:

owner-team
environment
application-type
criticality
internet-facing

A repository could then have values such as:

Repository: orders-api

owner-team: commerce
environment: production
application-type: API
criticality: high
internet-facing: yes

This information is different from source code.

It describes the repository and the application it represents.

GitHub allows organizations to define custom properties with different types, including single-select, multi-select, and other supported property types.

Why Repository Metadata Becomes Important

Repository metadata is easy to ignore when an organization is small.

Suppose your organization has five repositories:

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

Everyone probably knows what they are.

Now imagine 500 repositories.

The repository list might contain:

orders-api
orders-worker
orders-events
customer-api
customer-worker
customer-ui
...

Names alone do not tell you:

Who owns each application
Which environment it supports
Whether it is externally accessible
Whether it is business-critical
Whether additional security controls apply

Structured properties solve this problem.

Where GitHub Copilot Helps

Creating a property is straightforward.

The difficult part is often deciding which values belong to it.

For example, suppose you create:

Property:
application-type

You might initially think of:

API
Web
Worker
Library

But another administrator may think of:

Backend
Frontend
Service
CLI
Function

Both lists can be reasonable.

You can then review the suggestions and decide which values actually make sense for your organization.

Copilot Is Helping With the Schema

This distinction is important.

Copilot is not simply filling random repository fields.

The feature helps administrators while defining the allowed values for a custom property.

Think of the process like this:

Administrator
      |
      v
Create Property
      |
      v
Describe Property
      |
      v
Copilot Suggestions
      |
      v
Review Values
      |
      v
Save Property Definition

The administrator remains responsible for the final definition.

That makes the feature more useful than simply generating arbitrary metadata.

A Simple Example

Imagine you want to classify repositories by application type.

You create:

application-type

The property could use a single-select field.

You need to decide which values should be allowed.

Instead of manually creating the list from scratch, Copilot can provide suggestions.

You might end up with a list such as:

API
Web Application
Worker
Library
CLI

You should then review the list.

If your organization does not build CLI applications, there is no reason to keep that value.

Likewise, if your organization distinguishes between frontend and backend applications, you may want a different taxonomy.

Build a Property Model Before Using Copilot

Copilot is more useful when you already understand the information you want to manage.

Start by asking:

What do we need to know about our repositories?

A reasonable initial model might be:

Property	Purpose
owner-team	Identifies the responsible team
environment	Identifies the primary environment
application-type	Describes the application
criticality	Indicates business importance
internet-facing	Identifies externally accessible applications
compliance	Identifies applicable requirements

This gives Copilot a useful context for suggesting values.

Example: Environment

Consider this property:

environment

A simple value set might be:

development
staging
production

This is a good example of a property that should remain simple.

Do not create:

dev
development
DEV
test
testing
qa
stage
staging
prod
production

unless these genuinely represent different states in your organization.

The goal is consistent metadata.

Example: Application Type

For:

application-type

you might define:

API
Web
Worker
Library
CLI

The exact values should depend on your organization's architecture.

For example, a company with serverless workloads might need:

Function

while another organization may not need it.

This is where Copilot suggestions can save time, but human review is still necessary.

Example: Criticality

Consider:

criticality

You could use:

low
medium
high

But before adopting these values, define what they mean.

For example:

low
    Limited business impact

medium
    Noticeable business impact

high
    Significant business impact

The labels themselves are not enough.

Different teams may interpret "high" differently unless the organization defines the classification.

Single-Select Properties

Single-select properties are useful when a repository should have one value from a controlled list.

For example:

environment

development
staging
production

Another example:

criticality

low
medium
high

The advantage is consistency.

Automation can safely look for:

environment = production

without worrying about variations such as prod or Production.

Multi-Select Properties

Some information cannot be represented by a single value.

Compliance is a common example.

A repository could potentially belong to multiple categories:

compliance

SOC 2
PCI
FedRAMP
Internal

A multi-select property allows more than one value to be assigned.

The important thing is to define the categories carefully.

If two values overlap heavily, users may not know which one to select.

Do Not Let Copilot Design Your Governance Policy

This is probably the most important practical point.

Copilot can suggest values.

It should not be treated as the authority for your organization's governance model.

For example, suppose Copilot suggests:

criticality

Low
Medium
High
Critical

That does not mean your organization should automatically adopt all four.

Ask:

Does our organization actually use these classifications?
What does each classification mean?
Can teams consistently assign them?
Will automation depend on them?
Are these terms already used elsewhere?
Do security or compliance teams have existing definitions?

The final taxonomy should come from your organization's requirements.

Using Properties With Repository Governance

Custom properties become more valuable when they are connected to governance workflows.

For example:

internet-facing = yes

could identify repositories that require additional controls.

Conceptually:

Repository
    |
    v
Custom Property
    |
    v
Repository Selection
    |
    v
Governance Rule

GitHub supports using custom properties to target repositories with rulesets, which can help organizations apply repository governance consistently.

This is one reason to avoid arbitrary property values.

If automation depends on them, consistency becomes important.

Custom Properties and Copilot Instructions Are Different

GitHub Copilot also supports repository-level instructions.

For example:

.github/copilot-instructions.md

can contain project-specific guidance for Copilot.

It might say:

# Development Guidelines

- Use nullable reference types.
- Prefer async APIs for I/O.
- Write unit tests for business logic.
- Follow the existing naming conventions.

This tells Copilot how it should work with the repository.

Custom properties answer a different question:

What describes this repository?

Copilot instructions answer:

How should Copilot work with this repository?

They solve different problems.

Automating Property Assignment

Once property definitions are established, organizations can also manage property values programmatically.

GitHub provides REST API support for repository custom properties, including reading and updating property values.

For example, a provisioning system could conceptually perform:

Create Repository
       |
       v
Assign Owner
       |
       v
Assign Application Type
       |
       v
Assign Environment
       |
       v
Apply Repository Rules

This can be useful when new repositories are created regularly.

Instead of asking every developer to manually configure metadata, the repository provisioning process can assign standard values.

Example API Request

A repository custom property update can be performed through GitHub's REST API.

A simplified request looks 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/REPOSITORY/properties/values

The actual request body and permissions depend on the properties you are updating and the authentication model used by your organization.

Do not put access tokens directly into source code or commit them to a repository.

Keep Property Names Stable

Once automation starts depending on a property, changing its name can have consequences.

For example:

owner-team

might be referenced by scripts and governance rules.

Renaming it to:

team-owner

could require changes in several places.

Treat important property definitions as part of your organization's configuration model.

Before creating a property, decide:

What does it mean?
Who owns it?
What values are allowed?
Who updates it?
Which automation depends on it?

Avoid Free-Form Metadata When Possible

Suppose you create:

owner-team

as a free-text field.

One repository might contain:

Payments

another:

payments

and another:

Payment Team

A human can understand that these may refer to the same group.

An automation script cannot safely assume that.

Controlled values are easier to search and automate.

For example:

payments
platform
data
commerce

is much cleaner.

Create a Small Taxonomy

Do not start with 30 properties.

A practical first version could contain only:

owner-team
environment
application-type
criticality

After using them for a while, identify gaps.

Maybe your security team needs:

internet-facing

Add it later.

Maybe compliance needs:

compliance

Add that when there is a real requirement.

This keeps the metadata model manageable.

Review Existing Repositories

Creating the definition is only half the job.

You also need to apply the properties to existing repositories.

Suppose your organization has:

500 repositories

and only:

50 repositories

have property values.

The metadata model will not provide much value until the remaining repositories are classified.

A migration can be handled gradually:

500 repositories
       |
       v
Classify critical repositories
       |
       v
Classify production repositories
       |
       v
Classify remaining repositories

Automation can help once the rules for assigning values are well defined.

Common Mistakes

Creating Properties Without a Use Case

Do not create a property simply because it sounds useful.

Ask how the organization will use it.

Accepting Every Copilot Suggestion

Suggestions are a starting point, not an organizational standard.

Review them.

Using Similar Values

Avoid:

prod
production
Production

when all three mean the same thing.

Mixing Different Concepts

Do not make one property responsible for several unrelated concepts.

For example:

team-and-environment

is harder to manage than:

owner-team
environment

Making Everything Free-Form

Free-text metadata is harder to filter and automate consistently.

Forgetting Property Ownership

Someone should be responsible for maintaining the definition.

Otherwise, old values remain long after the organization has changed.

A Practical Workflow

A simple workflow for introducing Copilot-assisted custom properties can look like this.

Step 1: Identify the Information

List the repository information your organization actually needs.

Step 2: Create the Property

Give it a clear name and description.

Step 3: Choose the Property Type

Decide whether the property needs a single value, multiple values, or another supported type.

Step 4: Use Copilot Suggestions

Use Copilot to generate a starting point for allowed values where appropriate.

Step 5: Review the Suggestions

Remove values that do not apply.

Combine duplicates.

Add organization-specific values when necessary.

Step 6: Define the Meaning

Document what each value represents.

Step 7: Apply the Properties

Assign values to repositories.

Step 8: Connect Automation

Use APIs, repository management workflows, or governance rules where appropriate.

Step 9: Review Periodically

Remove obsolete values and update definitions when organizational requirements change.

A Practical Example for a .NET Team

Imagine a company with several .NET services.

The team creates these properties:

runtime
application-type
environment
owner-team
criticality

A repository might look like:

Repository:
customer-api

runtime:
.NET

application-type:
API

environment:
production

owner-team:
customer-platform

criticality:
high

Another repository could be:

Repository:
invoice-worker

runtime:
.NET

application-type:
Worker

environment:
production

owner-team:
billing

criticality:
medium

Now the organization can distinguish the repositories without relying on repository names or README files.

When Copilot Provides the Most Value

Copilot-assisted suggestions are particularly useful when:

You are creating a new property.
The allowed values are not obvious.
Multiple administrators manage repositories.
You want to explore possible classifications.
You are building an initial metadata model.

It is less useful when the organization already has a formally defined taxonomy.

If your security team has already defined exactly which compliance classifications are allowed, use that approved list rather than replacing it with generated suggestions.

Best Practices

Keep Definitions Simple

A property should represent one clear concept.

Use Consistent Naming

Use predictable property names such as:

owner-team
environment
application-type

Keep Values Controlled

Avoid unnecessary variations.

Document Meaning

A value without a clear definition can be interpreted differently by different teams.

Review Before Automation

Do not build automation around a property until its definition is stable.

Keep Human Review

Copilot can speed up the design process, but the organization should remain responsible for the final metadata model.

Summary

GitHub repository custom properties give organizations a structured way to describe and classify repositories.

Instead of relying only on repository names, README files, or manually maintained spreadsheets, teams can store information such as:

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

GitHub Copilot can help administrators create custom property definitions by suggesting allowed values.

The real value comes from combining those properties with consistent repository management and automation.

A good approach is simple:

Define the information
        |
        v
Create the property
        |
        v
Use Copilot for suggestions
        |
        v
Review and standardize values
        |
        v
Assign repositories
        |
        v
Automate where useful

Copilot can reduce the effort involved in creating the initial property model, but it should not replace organizational decisions about classification and governance.