Advanced Customization of GitHub Copilot
GitHub Copilot is not a monolithic one-size-fits-all system. On the contrary, it offers three levels of customization that allow you to adapt the AI assistant's behavior to individual, project, and organizational needs. Understanding and properly configuring these levels is the key to obtaining more precise suggestions, reducing noise, and maximizing team productivity.
In this article, we will explore each customization level in depth, from personal configuration to repository instructions, up to organizational policies. We will also explore integration with the Model Context Protocol (MCP) and content exclusion strategies to protect sensitive code.
Complete Series Overview
| # | Article | Focus |
|---|---|---|
| 1 | Foundation and Mindset | Setup and mindset |
| 2 | Ideation and Requirements | From idea to MVP |
| 3 | Backend Architecture | API and database |
| 4 | Frontend Structure | Organization and naming |
| 5 | Prompt Engineering | Prompts and MCP Agents |
| 6 | Testing and Quality | Unit, integration, E2E |
| 7 | Documentation | README, API docs, ADR |
| 8 | Deploy and DevOps | Docker, CI/CD |
| 9 | Evolution | Scalability and maintenance |
| 10 | Coding Agent | GitHub autonomous agent |
| 11 | Code Review | Automated review |
| 12 | Copilot Edits and Agent Mode | Multi-file editing |
| 13 | GitHub Spark | No-code micro-apps |
| 14 | Copilot Spaces and Memory | Shared context |
| 15 | AI Models | Multi-model and selection |
| 16 | You are here → Customization | Instructions and configuration |
| 17 | Enterprise and Business | Plans, analytics, policy |
| 18 | Extensions and Marketplace | Extensions and integrations |
| 19 | Security | Security and compliance |
The Three Levels of Customization
GitHub Copilot supports custom instructions at three levels, each with a different scope and priority. When multiple levels are active simultaneously, instructions are combined following a precise priority order.
Instruction Hierarchy
| Level | Scope | Priority | Managed by | Availability |
|---|---|---|---|---|
| Personal Instructions | All personal conversations | High (override) | Individual user | All plans |
| Repository Instructions | Single repository | Medium | Project team | All plans |
| Organization Instructions | Entire organization | Low (base) | Org owners | Enterprise |
How Combination Works
When Copilot receives a request, it collects instructions from all available levels and combines them into a single context. If there are conflicts, higher-priority instructions prevail. For example, if organization instructions require responses in English but personal instructions specify Italian, Copilot will respond in Italian.
Custom instructions are automatically added as context to Copilot Chat conversations. They are not applied to inline code completion suggestions, but they influence responses in chat, agent mode, and reviews.
Personal Instructions
Personal instructions apply to all conversations you have with Copilot Chat on the GitHub website (github.com). They are the most direct way to customize Copilot's behavior according to your individual preferences.
What You Can Configure
Personal instructions are ideal for defining preferences that apply to any project you work on. Here are the main categories of customization:
Personal Customization Categories
| Category | Example | Effect |
|---|---|---|
| Language | Always respond in English | All responses will be in English |
| Response style | Be concise, max 200 words | Short and direct responses |
| Format | Always use code blocks with language | Properly formatted code |
| Expertise | I am a senior Java developer | Advanced-level responses |
| Technical preferences | I prefer functional programming | Functional-style suggestions |
| Work context | I work on Spring Boot microservices | Contextualized suggestions |
How to Configure Personal Instructions
To configure personal instructions on GitHub:
- Go to github.com and log in
- Click on your profile picture in the top right
- Select Settings
- In the sidebar, click on Copilot
- In the "Personal instructions" section, click Edit
- Write your instructions in the text area
- Click Save
Example of Effective Personal Instructions
# Developer Profile
I am a senior full-stack developer with 8 years of experience.
Main stack: Java (Spring Boot), TypeScript (Angular), PostgreSQL.
I work on microservice architectures in a cloud environment (AWS).
# Language Preferences
Always respond in English.
Use technical terminology appropriately
(e.g., "dependency injection", "middleware", "endpoint").
# Response Style
- Be concise and get straight to the point
- Always provide code examples when possible
- Include comments in code only for complex logic
- Specify versions when suggesting dependencies
- Flag potential performance or security issues
# Code Conventions
- Java: Google Java Style Guide
- TypeScript: ESLint with strict configuration
- SQL: uppercase for keywords, lowercase for table names
- Naming: camelCase for variables, PascalCase for classes
- Tests: Given-When-Then pattern for test names
# Anti-Patterns to Avoid
- Never suggest code without error handling
- Don't use "any" in TypeScript
- Don't suggest SQL queries with SELECT *
- Don't ignore input validation
Personal Instructions Limitations
Personal instructions apply only to conversations on github.com (Copilot Chat in the browser). They do not directly influence suggestions in the IDE (VS Code, JetBrains). To customize behavior in the IDE, use repository instructions or editor-specific settings.
Additionally, personal instructions don't have an explicit character limit like organization instructions, but it's good practice to keep them concise to avoid overloading the model's context.
Repository Instructions
Repository instructions are the most powerful customization level for development teams. They are defined through files within the repository and automatically apply to all team members working on that project.
Main File: .github/copilot-instructions.md
The main file for repository instructions is .github/copilot-instructions.md.
This file is automatically read by Copilot every time a user interacts with
the repository. The content is added as context to all Copilot Chat conversations
related to the project.
# Copilot Instructions for TaskFlow Frontend
## Technology Stack
- Framework: Angular 21 with standalone components
- Language: TypeScript 5.9 strict mode
- Styling: SCSS with BEM methodology
- State Management: Angular Signals
- HTTP: Angular HttpClient with interceptors
- Routing: Angular Router with lazy loading
- Testing: Jasmine + Karma for unit, Cypress for E2E
## Code Conventions
### Components
- ALWAYS use standalone components (no NgModules)
- Change detection: OnPush for all components
- Use signals() for reactive state, not BehaviorSubject
- Template: separate file (.html) for components > 20 lines
- Styles: separate file (.scss) always
### Naming Conventions
- Components: PascalCase with Component suffix (e.g., UserProfileComponent)
- Services: PascalCase with Service suffix (e.g., AuthService)
- Interfaces: PascalCase with I prefix (e.g., IUserProfile)
- Files: kebab-case (e.g., user-profile.component.ts)
- Constants: UPPER_SNAKE_CASE (e.g., MAX_RETRY_COUNT)
### Mandatory Patterns
- Every HTTP service must have centralized error handling
- Use async pipe or toSignal() in templates, never manual subscribe
- Route guards as functional guards (not class-based)
- Forms: reactive forms with FormBuilder, never template-driven
- Validation: custom validators in separate file
### Directory Structure
```
src/app/
features/ # Feature modules (lazy loaded)
shared/ # Shared components, pipes, directives
core/ # Singleton services, interceptors, guards
models/ # Interfaces and types
environments/ # Environment configurations
```
### Testing
- Every component MUST have unit tests
- Minimum coverage: 80% for services, 70% for components
- Mock pattern: use jasmine.createSpyObj for dependencies
- Test naming: "should [expected behavior] when [condition]"
### Performance
- Lazy load all feature routes
- Use trackBy for *ngFor (or @for with track)
- Images: use NgOptimizedImage
- Bundle size alert: > 500KB per chunk is a warning
### Accessibility
- Every interactive element must have aria-label
- Color contrast: WCAG AA (4.5:1 minimum)
- Tab navigation must work for all forms
- Screen reader: test with NVDA or VoiceOver
Path-Specific Instructions
In addition to the general file, Copilot supports instructions specific to certain paths in the repository. These instructions are loaded only when working on files that match the specified patterns.
Path-specific files must be placed in the
.github/instructions/ directory with the .instructions.md extension.
Each file includes a YAML header that specifies which paths they apply to.
---
applyTo: "**/*.spec.ts"
---
# Instructions for Test Files
## Test Structure
- Use describe() to group tests by method/functionality
- Use beforeEach() for common setup
- AAA Pattern: Arrange, Act, Assert in every test
## Naming Convention
- describe: name of the class/function under test
- it/test: "should [what it does] when [condition]"
## Mock Pattern
```typescript
const mockService = jasmine.createSpyObj('ServiceName', ['method1', 'method2']);
mockService.method1.and.returnValue(of(expectedResult));
```
## Coverage Requirements
- Branch coverage: >= 80%
- Line coverage: >= 85%
- Every conditional path must have at least one test
## Anti-Patterns to Avoid
- Don't test implementation details
- Don't mock everything (test integration where possible)
- Don't use setTimeout() in tests (use fakeAsync/tick)
- Don't ignore flaky tests: fix them or remove them
---
applyTo: "src/app/core/services/**/*.ts"
---
# Instructions for API Services
## Mandatory Pattern
Every API service must follow this pattern:
```typescript
@Injectable({ providedIn: 'root' })
export class EntityService {
private readonly apiUrl = `${environment.apiUrl}/entities`;
constructor(private http: HttpClient) {}
getAll(): Observable<Entity[]> {
return this.http.get<Entity[]>(this.apiUrl).pipe(
catchError(this.handleError)
);
}
private handleError(error: HttpErrorResponse): Observable<never> {
// Centralized in the interceptor, here only specific logging
console.error(`EntityService error: ${error.message}`);
return throwError(() => error);
}
}
```
## Rules
- All HTTP methods must return Observable<T>
- Error handling via global interceptor + local logging
- Base URL from environment, never hardcoded
- Standard CRUD methods: getAll, getById, create, update, delete
- Use HttpParams for query parameters
- Cache with shareReplay(1) where appropriate
---
applyTo: "src/app/features/**/*.component.ts"
---
# Instructions for Feature Components
## Standard Component Template
```typescript
@Component({
standalone: true,
selector: 'app-feature-name',
templateUrl: './feature-name.component.html',
styleUrls: ['./feature-name.component.scss'],
changeDetection: ChangeDetectionStrategy.OnPush,
imports: [CommonModule, ReactiveFormsModule]
})
export class FeatureNameComponent {
// Signals for local state
readonly items = signal<Item[]>([]);
readonly loading = signal(false);
readonly error = signal<string | null>(null);
// Computed for derivations
readonly itemCount = computed(() => this.items().length);
// Inject dependencies
private readonly service = inject(FeatureService);
private readonly destroyRef = inject(DestroyRef);
}
```
## Rules
- OnPush change detection MANDATORY
- Signals for all local state
- inject() function, not constructor injection
- DestroyRef for subscription cleanup
- Template max 50 lines, otherwise split into sub-components
Complete Repository Instructions Example for Spring Boot
# Copilot Instructions for TaskFlow Backend
## Stack
- Java 21 with Spring Boot 3.3
- Build: Gradle Kotlin DSL
- Database: PostgreSQL 16 with Flyway migrations
- Cache: Redis 7
- Auth: Spring Security + JWT
- API: REST with OpenAPI 3.1 documentation
- Testing: JUnit 5 + Mockito + Testcontainers
## Architecture
Hexagonal Architecture (Ports and Adapters):
```
src/main/java/com/taskflow/
domain/ # Entities, value objects, domain exceptions
application/ # Use cases, DTOs, port interfaces
infrastructure/ # Adapters: DB, HTTP, messaging
config/ # Spring configuration
```
## Java Conventions
- Records for immutable DTOs
- Sealed interfaces for controlled type hierarchies
- Optional only as return type, never as parameter
- Stream API for collection operations
- Naming: verb + noun for methods (e.g., createOrder, findUserById)
## API Design
- Endpoint: /api/v1/{resource} (plural)
- Response: wrapper with data, metadata, errors
- Pagination: page, size, sort query params
- Error format: RFC 7807 Problem Details
- Versioning: URL-based (/api/v1/, /api/v2/)
## Database
- Migrations: Flyway with naming V{version}__{description}.sql
- Table naming: snake_case, plural (e.g., user_profiles)
- Every table: id (UUID), created_at, updated_at
- Indexes: on all foreign keys and frequently searched fields
- NO cascade delete: handle explicitly
## Security
- Input validation on ALL endpoints
- SQL injection: only PreparedStatement/JPA
- Rate limiting: 100 req/min per user
- CORS: explicit whitelist
- Secrets: never in code, always from environment
Best Practices for Repository Instructions
- Versioning: Repository instructions are files in the repo, so they are versioned with Git. Every change is traceable.
- Review: Treat changes to instructions like code changes: create PRs and do code reviews.
- Conciseness: Instructions that are too long can dilute the context. Focus on clear and specific rules.
- Specificity: Avoid generic instructions. Be specific about frameworks, versions, patterns, and conventions.
- Updates: Update instructions when team conventions or project dependencies change.
Organization Instructions
Organization instructions are available exclusively for GitHub Copilot Enterprise and Business subscriptions. They allow organization owners to define preferences that apply to all members and all repositories in the organization.
Configuration
To configure organization instructions:
- Navigate to the organization page on GitHub
- Go to Settings → Copilot → Custom instructions
- Enable the feature via the toggle
- Write the instructions in the dedicated text area
- Save the changes
Organization Instructions Characteristics
| Characteristic | Detail |
|---|---|
| Character limit | 4,000 characters maximum |
| Versioning | NOT version-controlled (no Git) |
| Visibility | Only org owners can view/edit |
| Application | Automatic for all org members |
| Override | Can be overridden by repo and personal instructions |
| Availability | Enterprise and Business only |
# Acme Corp - GitHub Copilot Instructions
## Language
Always respond in Italian for the Italian team,
in English for everyone else.
## Security Standards
- Never suggest code that exposes secrets or credentials
- Always include input validation in endpoints
- Use prepared statements for all database queries
- Implement rate limiting on every public API
- Sensitive logs: never log PII, tokens, or passwords
## Company Code Conventions
- All services must have interface + implementation
- Naming: "Acme" prefix for base package (com.acme.*)
- JavaDoc documentation mandatory for public methods
- Commit message: Conventional Commits format
- Branch naming: feature/, bugfix/, hotfix/ + JIRA ticket
## Compliance
- Code must be GDPR compliant
- User data: always encrypted at rest
- Log retention: max 90 days
- Audit trail mandatory for CRUD operations on sensitive data
## Approved Libraries
- HTTP Client: OkHttp or Spring WebClient (no Apache HC legacy)
- JSON: Jackson (no Gson)
- Logging: SLF4J + Logback
- Testing: JUnit 5 + AssertJ + Mockito
Important Limitation: 4,000 Characters
The 4,000 character limit for organization instructions may seem restrictive, especially for large organizations with many conventions. The recommended strategy is to include in org instructions only universal and critical rules (security, compliance, base naming), delegating project-specific rules to repository instructions.
Model Context Protocol (MCP) Integration
The Model Context Protocol (MCP) is an open standard that allows connecting Copilot to external tools and data sources. Through MCP, Copilot can access databases, APIs, documentation systems, and much more, significantly expanding its capabilities.
GitHub MCP Registry
GitHub offers a curated MCP Registry that serves as a catalog of verified and secure MCP servers. This registry allows you to quickly discover and integrate MCP servers without having to manually configure each connection.
MCP Server Types
| Type | Transport | Where It Runs | Use Case | Configuration |
|---|---|---|---|---|
| Remote (HTTP/SSE) | HTTP with Server-Sent Events | Remote server | Cloud APIs, SaaS, shared services | URL + authentication |
| Local (stdio) | Standard I/O (stdin/stdout) | Local machine | Local databases, file system, CLI tools | Command + arguments |
MCP Configuration in the IDE
To configure MCP servers in VS Code, create or edit the .vscode/mcp.json file
in the project root. This file defines which MCP servers are available for
Copilot during development.
{
"servers": {
"github": {
"type": "remote",
"url": "https://api.githubcopilot.com/mcp/github",
"description": "GitHub API access for issues, PRs, repos"
},
"postgres-local": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"postgresql://localhost:5432/taskflow"
],
"description": "Local PostgreSQL database access"
},
"filesystem": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"--root",
"${workspaceFolder}"
],
"description": "File system access for project files"
},
"documentation": {
"type": "remote",
"url": "https://docs-mcp.example.com/v1",
"headers": {
"Authorization": "Bearer ${env:DOCS_API_KEY}"
},
"description": "Internal documentation search"
},
"sentry": {
"type": "remote",
"url": "https://mcp.sentry.io/sse",
"headers": {
"Authorization": "Bearer ${env:SENTRY_AUTH_TOKEN}"
},
"description": "Sentry error tracking integration"
}
}
}
MCP and Coding Agent
MCP integration is particularly powerful when combined with Copilot's Coding Agent. The agent can use MCP tools to gather information, execute queries, and interact with external systems during the automated development process.
MCP Use Cases with Coding Agent
| Scenario | MCP Server | Agent Action |
|---|---|---|
| Bug fix from issue | GitHub + Sentry | Reads the issue, retrieves stack trace from Sentry, analyzes the code, and proposes a fix |
| New feature | GitHub + Database | Reads requirements from the issue, analyzes the DB schema, generates code and tests |
| Documentation | Filesystem + API docs | Analyzes source code, automatically updates API documentation |
| Data migration | PostgreSQL + Redis | Analyzes current structure, generates migration scripts, verifies integrity |
| Performance tuning | Prometheus + Database | Collects metrics, identifies slow queries, suggests optimizations |
Enterprise Policy for MCP
For Enterprise and Business organizations, the "MCP servers in Copilot" policy must be explicitly enabled by organization administrators. By default, this policy is disabled.
When enabled, owners can control which MCP servers are accessible to organization members, ensuring that only approved data sources are used.
Content Exclusion
Content exclusion allows you to exclude specific files and directories from Copilot's processing. This is essential for protecting sensitive code, proprietary code, or files containing secrets or confidential configurations.
Content Exclusion Levels
Exclusion Levels Comparison
| Level | Configured by | Scope | Availability |
|---|---|---|---|
| Repository | Repository admin | Files in the specific repository | Enterprise and Business |
| Organization | Org owner | Files in any repo in the org | Enterprise and Business |
| Enterprise | Enterprise admin | Files in all orgs in the enterprise | Enterprise |
What Gets Excluded
When a file is marked for exclusion, Copilot ignores it in various contexts:
Content Exclusion Impact
| Feature | Exclusion Effect |
|---|---|
| Inline completion | No suggestions generated for excluded files |
| Copilot Chat | Excluded files not used as context in responses |
| Code Review | No review comments on excluded files |
| Copilot Edits | Excluded files cannot be modified by the agent |
| Coding Agent | The agent cannot read or modify excluded files |
Content Exclusion Configuration
# Format: one pattern per line
# Supports glob patterns
# Exclude sensitive configuration files
*.env
*.env.*
config/secrets/**
# Exclude non-modifiable legacy code
legacy/**
vendor/**
# Exclude automatically generated files
generated/**
dist/**
node_modules/**
# Exclude files with sensitive data
**/credentials*
**/private-keys/**
**/*.pem
**/*.key
# Exclude specific directories
src/app/proprietary/**
src/internal/billing/**
# Exclude test files with sensitive data
test/fixtures/sensitive-data/**
Content Exclusion Limitations
- Symlinks: Files reachable via symlinks are not automatically excluded. Exclusion is based on the real file path.
- Remote filesystem: Exclusion does not work for files on remote filesystems (e.g., SSH, SFTP).
- Propagation: Changes to exclusion rules may take up to 30 minutes to propagate to all users.
- Submodules: Files in Git submodules require separate exclusion rules for the submodule repository.
Team Customization Strategies
Effectively combining the three customization levels requires a clear strategy. Here is a recommended approach for teams of different sizes.
Small Teams (2-5 developers)
What to Do
- Focus on repository instructions
- One copilot-instructions.md file per repo
- Path-specific instructions for critical areas
- Personal instructions for individual preferences
- Periodic review of instructions (monthly)
What to Avoid
- Organization instructions (overkill for small teams)
- Overly detailed instructions (diminishing returns)
- Duplication between personal and repo instructions
- Rules that are not applied in practice
- Too frequent updates
Medium Teams (5-20 developers)
What to Do
- Detailed repository instructions for every project
- Path-specific instructions for tests, APIs, models
- Organization instructions for cross-cutting standards
- Content exclusion for sensitive code
- Quarterly review with the team
- Instruction templates for new repositories
What to Avoid
- Conflicting instructions between levels
- Leaving obsolete instructions
- Ignoring developer feedback
- Rules too rigid that frustrate the team
- Lack of ownership over instructions
Large Organizations (20+ developers)
What to Do
- Organization instructions for company policies
- Repository instruction templates for every project type
- Enterprise-wide content exclusion
- Centralized and approved MCP servers
- Formal process for instruction changes
- Metrics on instruction effectiveness
- Onboarding guide for new developers
What to Avoid
- Overly restrictive organizational instructions
- Bypassing the system with personal instructions
- Lack of governance over MCP servers
- Not monitoring instruction adoption
- Ignoring the needs of specialized teams
- Withholding the value of instructions: share them
Practical Example: Complete Setup for a Project
Let's see how to configure complete customization for a real project, combining all levels.
my-project/
.github/
copilot-instructions.md # General project instructions
instructions/
testing.instructions.md # Rules for test files
api-controllers.instructions.md # Rules for API controllers
database.instructions.md # Rules for queries and migrations
components.instructions.md # Rules for UI components
.vscode/
mcp.json # Project MCP servers
settings.json # VS Code settings
# At the organization level (GitHub UI):
# - Organization Instructions (4000 char max)
# - Content Exclusion patterns
# - MCP server policy
# At the personal level (GitHub Settings):
# - Personal Instructions
# - Language and style preferences
Instruction Maintenance Workflow
Update Process
| Frequency | Action | Responsible | Trigger |
|---|---|---|---|
| Ad hoc | Update personal instructions | Individual developer | Preference change |
| Per sprint | Review repo instructions | Tech lead | New conventions adopted |
| Monthly | Update path-specific instructions | Team | Developer feedback |
| Quarterly | Review org instructions | Org owner + leads | Company policy changes |
| Quarterly | Audit content exclusion | Security team | Security review |
| Semi-annually | Complete MCP server review | Platform team | New tools available |
Troubleshooting Common Issues
Customization Troubleshooting
| Problem | Probable Cause | Solution |
|---|---|---|
| Repo instructions not applied | File not in the correct path | Verify the file is at .github/copilot-instructions.md |
| Path-specific instructions ignored | Incorrect YAML pattern | Verify the applyTo format in the YAML frontmatter |
| Org instructions not visible | Feature not enabled | Enable the toggle in Settings → Copilot → Custom instructions |
| MCP server not connected | Policy disabled | Ask the org admin to enable "MCP servers in Copilot" |
| Content exclusion not working | Propagation in progress | Wait up to 30 minutes for full propagation |
| Instruction conflict | Contradictory instructions | Verify the hierarchy: personal > repo > org |
| Instructions too verbose | Context overload | Reduce to essential rules, use path-specific for details |
Customization Checklist
Copilot Customization Setup Checklist
| Area | Action | Completed |
|---|---|---|
| Personal | Define preferred language for responses | ☐ |
| Specify experience level and stack | ☐ | |
| Configure preferred response style | ☐ | |
| Repository | Create .github/copilot-instructions.md | ☐ |
| Define stack, conventions, and patterns | ☐ | |
| Add path-specific instructions for tests | ☐ | |
| Add path-specific instructions for APIs | ☐ | |
| Organization | Define security standards in org instructions | ☐ |
| Configure content exclusion for sensitive data | ☐ | |
| Enable and configure MCP server policies | ☐ | |
| MCP | Configure .vscode/mcp.json in the project | ☐ |
| Test MCP server connections | ☐ | |
| Document available MCP servers for the team | ☐ | |
| Maintenance | Establish periodic review process | ☐ |
| Create templates for new repositories | ☐ |
Conclusion
Customizing GitHub Copilot is an investment that quickly pays off in terms of productivity and code quality. Well-configured instructions transform Copilot from a generic suggester into an assistant that knows your stack, your conventions, and your team's rules.
The key to success is an incremental approach: start with basic repository instructions, add path-specific instructions as you identify areas that benefit from specific guidance, and scale to organization instructions as the team grows. MCP integration and content exclusion complete the picture, ensuring that Copilot is both powerful and secure.
In the next article, we will explore Copilot's Enterprise and Business options, with deep dives into pricing, analytics, policy management, and ROI for organizations.
Series Progress
| # | Article | Status |
|---|---|---|
| 1 | Foundation and Mindset | ✅ |
| 2 | Ideation and Requirements | ✅ |
| 3 | Backend Architecture | ✅ |
| 4 | Frontend Structure | ✅ |
| 5 | Prompt Engineering | ✅ |
| 6 | Testing and Quality | ✅ |
| 7 | Documentation | ✅ |
| 8 | Deploy and DevOps | ✅ |
| 9 | Evolution | ✅ |
| 10 | Coding Agent | ✅ |
| 11 | Code Review | ✅ |
| 12 | Copilot Edits and Agent Mode | ✅ |
| 13 | GitHub Spark | ✅ |
| 14 | Copilot Spaces and Memory | ✅ |
| 15 | AI Models | ✅ |
| 16 | Advanced Customization | 📍 |
| 17 | Enterprise and Business | ◻ |
| 18 | Extensions and Marketplace | ◻ |
| 19 | Security | ◻ |
Commenti
Caricamento commenti...
Sign in to comment