Skip to main content

16 - Advanced Copilot Customization

Three levels of customization: personal instructions, repository (.github/copilot-instructions.md), and organization. MCP integration and content exclusion.

What do you think about this article?

At a Glance

Three levels of customization: personal instructions, repository (.github/copilot-instructions.md), and organization. MCP integration and content exclusion.

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

#ArticleFocus
1Foundation and MindsetSetup and mindset
2Ideation and RequirementsFrom idea to MVP
3Backend ArchitectureAPI and database
4Frontend StructureOrganization and naming
5Prompt EngineeringPrompts and MCP Agents
6Testing and QualityUnit, integration, E2E
7DocumentationREADME, API docs, ADR
8Deploy and DevOpsDocker, CI/CD
9EvolutionScalability and maintenance
10Coding AgentGitHub autonomous agent
11Code ReviewAutomated review
12Copilot Edits and Agent ModeMulti-file editing
13GitHub SparkNo-code micro-apps
14Copilot Spaces and MemoryShared context
15AI ModelsMulti-model and selection
16You are here → CustomizationInstructions and configuration
17Enterprise and BusinessPlans, analytics, policy
18Extensions and MarketplaceExtensions and integrations
19SecuritySecurity 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

LevelScopePriorityManaged byAvailability
Personal InstructionsAll personal conversationsHigh (override)Individual userAll plans
Repository InstructionsSingle repositoryMediumProject teamAll plans
Organization InstructionsEntire organizationLow (base)Org ownersEnterprise

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

CategoryExampleEffect
LanguageAlways respond in EnglishAll responses will be in English
Response styleBe concise, max 200 wordsShort and direct responses
FormatAlways use code blocks with languageProperly formatted code
ExpertiseI am a senior Java developerAdvanced-level responses
Technical preferencesI prefer functional programmingFunctional-style suggestions
Work contextI work on Spring Boot microservicesContextualized suggestions

How to Configure Personal Instructions

To configure personal instructions on GitHub:

  1. Go to github.com and log in
  2. Click on your profile picture in the top right
  3. Select Settings
  4. In the sidebar, click on Copilot
  5. In the "Personal instructions" section, click Edit
  6. Write your instructions in the text area
  7. Click Save

Example of Effective Personal Instructions

Personal Instructions - Full-Stack Developer
# 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.

.github/copilot-instructions.md - Angular 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.

.github/instructions/testing.instructions.md
---
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
.github/instructions/api-services.instructions.md
---
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
.github/instructions/components.instructions.md
---
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

.github/copilot-instructions.md - Spring Boot Project
# 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:

  1. Navigate to the organization page on GitHub
  2. Go to Settings → Copilot → Custom instructions
  3. Enable the feature via the toggle
  4. Write the instructions in the dedicated text area
  5. Save the changes

Organization Instructions Characteristics

CharacteristicDetail
Character limit4,000 characters maximum
VersioningNOT version-controlled (no Git)
VisibilityOnly org owners can view/edit
ApplicationAutomatic for all org members
OverrideCan be overridden by repo and personal instructions
AvailabilityEnterprise and Business only
Example - Organization Instructions
# 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

TypeTransportWhere It RunsUse CaseConfiguration
Remote (HTTP/SSE)HTTP with Server-Sent EventsRemote serverCloud APIs, SaaS, shared servicesURL + authentication
Local (stdio)Standard I/O (stdin/stdout)Local machineLocal databases, file system, CLI toolsCommand + 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.

.vscode/mcp.json - MCP Configuration
{
  "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

ScenarioMCP ServerAgent Action
Bug fix from issueGitHub + SentryReads the issue, retrieves stack trace from Sentry, analyzes the code, and proposes a fix
New featureGitHub + DatabaseReads requirements from the issue, analyzes the DB schema, generates code and tests
DocumentationFilesystem + API docsAnalyzes source code, automatically updates API documentation
Data migrationPostgreSQL + RedisAnalyzes current structure, generates migration scripts, verifies integrity
Performance tuningPrometheus + DatabaseCollects 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

LevelConfigured byScopeAvailability
RepositoryRepository adminFiles in the specific repositoryEnterprise and Business
OrganizationOrg ownerFiles in any repo in the orgEnterprise and Business
EnterpriseEnterprise adminFiles in all orgs in the enterpriseEnterprise

What Gets Excluded

When a file is marked for exclusion, Copilot ignores it in various contexts:

Content Exclusion Impact

FeatureExclusion Effect
Inline completionNo suggestions generated for excluded files
Copilot ChatExcluded files not used as context in responses
Code ReviewNo review comments on excluded files
Copilot EditsExcluded files cannot be modified by the agent
Coding AgentThe agent cannot read or modify excluded files

Content Exclusion Configuration

Settings → Copilot → Content Exclusion
# 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.

Customization File Structure
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

FrequencyActionResponsibleTrigger
Ad hocUpdate personal instructionsIndividual developerPreference change
Per sprintReview repo instructionsTech leadNew conventions adopted
MonthlyUpdate path-specific instructionsTeamDeveloper feedback
QuarterlyReview org instructionsOrg owner + leadsCompany policy changes
QuarterlyAudit content exclusionSecurity teamSecurity review
Semi-annuallyComplete MCP server reviewPlatform teamNew tools available

Troubleshooting Common Issues

Customization Troubleshooting

ProblemProbable CauseSolution
Repo instructions not appliedFile not in the correct pathVerify the file is at .github/copilot-instructions.md
Path-specific instructions ignoredIncorrect YAML patternVerify the applyTo format in the YAML frontmatter
Org instructions not visibleFeature not enabledEnable the toggle in Settings → Copilot → Custom instructions
MCP server not connectedPolicy disabledAsk the org admin to enable "MCP servers in Copilot"
Content exclusion not workingPropagation in progressWait up to 30 minutes for full propagation
Instruction conflictContradictory instructionsVerify the hierarchy: personal > repo > org
Instructions too verboseContext overloadReduce to essential rules, use path-specific for details

Customization Checklist

Copilot Customization Setup Checklist

AreaActionCompleted
PersonalDefine preferred language for responses☐
Specify experience level and stack☐
Configure preferred response style☐
RepositoryCreate .github/copilot-instructions.md☐
Define stack, conventions, and patterns☐
Add path-specific instructions for tests☐
Add path-specific instructions for APIs☐
OrganizationDefine security standards in org instructions☐
Configure content exclusion for sensitive data☐
Enable and configure MCP server policies☐
MCPConfigure .vscode/mcp.json in the project☐
Test MCP server connections☐
Document available MCP servers for the team☐
MaintenanceEstablish 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

#ArticleStatus
1Foundation and Mindset✅
2Ideation and Requirements✅
3Backend Architecture✅
4Frontend Structure✅
5Prompt Engineering✅
6Testing and Quality✅
7Documentation✅
8Deploy and DevOps✅
9Evolution✅
10Coding Agent✅
11Code Review✅
12Copilot Edits and Agent Mode✅
13GitHub Spark✅
14Copilot Spaces and Memory✅
15AI Models✅
16Advanced Customization📍
17Enterprise and Business◻
18Extensions and Marketplace◻
19Security◻

Try These Tools

Free developer tools related to this topic.

Commenti

Caricamento commenti...

Sign in to comment

Discuss this article in the community

Join the Telegram group to discuss with other developers, ask questions and share your experiences.

Did you like this article?

Explore other content on the blog or discover my projects