I create modern web applications and custom digital tools to help businesses grow through technological innovation. My passion is combining computer science and economics to generate real value.
My passion for computer science was born at the Technical Commercial Institute of Maglie, where I discovered the power of programming and the fascination of creating digital solutions. From the start, I understood that computer science was not just code, but an extraordinary tool for turning ideas into reality.
During my studies in Business Information Systems, I began to interweave computer science and economics, understanding how technology can be the engine of growth for any business. This vision accompanied me to the University of Bari, where I obtained my degree in Computer Science, deepening my technical skills and passion for software development.
Today I put this experience at the service of businesses, professionals and startups, creating tailor-made digital solutions that automate processes, optimize resources and open new business opportunities. Because true innovation begins when technology meets the real needs of people.
My Skills
Data Analysis & Predictive Models
I transform data into strategic insights with in-depth analysis and predictive models for informed decisions
Process Automation
I create custom tools that automate repetitive operations and free up time for value-added activities
Custom Systems
I develop tailor-made software systems, from platform integrations to customized dashboards
Credo fermamente che l'informatica sia lo strumento più potente per trasformare le idee in realtà e migliorare la vita delle persone.
Democratizzare la Tecnologia
La mia missione è rendere l'informatica accessibile a tutti: dalle piccole imprese locali alle startup innovative, fino ai professionisti che vogliono digitalizzare la propria attività. Ogni realtà merita di sfruttare le potenzialità del digitale.
Unire Informatica ed Economia
Non è solo questione di scrivere codice: è capire come la tecnologia possa generare valore reale. Intrecciando competenze informatiche e visione economica, aiuto le attività a crescere, ottimizzare processi e raggiungere nuovi traguardi di efficienza e redditività.
Creare Soluzioni su Misura
Ogni attività è unica, e così devono esserlo le soluzioni. Sviluppo strumenti personalizzati che rispondono alle esigenze specifiche di ciascun cliente, automatizzando processi ripetitivi e liberando tempo per ciò che conta davvero: far crescere il business.
Trasforma la Tua Attività con la Tecnologia
Che tu gestisca un negozio, uno studio professionale o un'azienda, posso aiutarti a sfruttare le potenzialità dell'informatica per lavorare meglio, più velocemente e in modo più intelligente.
Bari, Puglia, Italy · Hybrid
Analysis and development of computer systems through the use of Java and Quarkus in Health and Public Sector. Continuous training on modern technologies for creating customized and efficient software solutions and on agents.
💼
06/2022 - 12/2024
Software analyst and Back End Developer Associate Consultant
Links Management and Technology SpA
Experience analyzing as-is software systems and ETL flows using PowerCenter. Completed Spring Boot training for developing modern and scalable backend applications. Backend developer specialized in Spring Boot, with experience in database design, analysis, development and testing of assigned tasks.
💼
02/2021 - 10/2021
Software programmer
Adesso.it (prima era WebScience srl)
Experience in AS-IS and TO-BE analysis, SEO evolutions and website evolutions to improve user performance and engagement.
🎓
2018 - 2025
Degree in Computer Science
University of Bari Aldo Moro
Bachelor's degree in Computer Science, focusing on software engineering, algorithms, and modern development practices.
📚
2013 - 2018
Diploma - Corporate Information Systems
Technical Commercial Institute of Maglie
Technical diploma specializing in Business Information Systems, combining IT knowledge with business management.
Contattami
Hai un progetto in mente? Parliamone! Compila il form qui sotto e ti risponderò al più presto.
* Campi obbligatori. I tuoi dati saranno utilizzati solo per rispondere alla tua richiesta.
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
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 = `
#123;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: #123;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:
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
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
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.
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
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
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)
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
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.
