Personalizzazione Avanzata di GitHub Copilot
GitHub Copilot non e' un sistema monolitico a taglia unica. Al contrario, offre tre livelli di personalizzazione che permettono di adattare il comportamento dell'assistente AI alle esigenze individuali, del progetto e dell'organizzazione. Comprendere e configurare correttamente questi livelli e' la chiave per ottenere suggerimenti più' precisi, ridurre il rumore e massimizzare la produttività' del team.
In questo articolo approfondiremo ogni livello di personalizzazione, dalla configurazione personale alle istruzioni di repository, fino alle policy organizzative. Esploreremo inoltre l'integrazione con il Model Context Protocol (MCP) e le strategie di content exclusion per proteggere il codice sensibile.
Panoramica della Serie Completa
| # | Articolo | Focus |
|---|---|---|
| 1 | Foundation e Mindset | Setup e mentalita' |
| 2 | Ideazione e Requisiti | Da idea a MVP |
| 3 | Architettura Backend/Frontend | API e database |
| 4 | Struttura del Codice | Organizzazione e naming |
| 5 | Prompt Engineering | Prompt e Agenti MCP |
| 6 | Testing e qualità' | Unit, integration, E2E |
| 7 | Documentazione | README, API docs, ADR |
| 8 | Deploy e DevOps | Docker, CI/CD |
| 9 | Evoluzione | Scalabilità' e manutenzione |
| 10 | Coding Agent | Agente autonomo GitHub |
| 11 | Code Review | Review automatizzata |
| 12 | Copilot Edits | Editing multi-file |
| 13 | GitHub Spark | Micro-app senza codice |
| 14 | Copilot Spaces | Contesto condiviso |
| 15 | Modelli AI | Multi-model e selezione |
| 16 | Sei qui → Personalizzazione | Istruzioni e configurazione |
| 17 | Enterprise e Business | Piani, analytics, policy |
| 18 | Extensions e Marketplace | Estensioni e integrazioni |
| 19 | Sicurezza e Uso Responsabile | Security e compliance |
I Tre Livelli di Personalizzazione
GitHub Copilot supporta istruzioni personalizzate a tre livelli, ciascuno con un ambito e una priorità' diversi. Quando più' livelli sono attivi contemporaneamente, le istruzioni vengono combinate seguendo un ordine di priorità' preciso.
Gerarchia delle Istruzioni
| Livello | Ambito | Priorità' | Gestito da | Disponibilità' |
|---|---|---|---|---|
| Personal Instructions | Tutte le conversazioni personali | Alta (override) | Singolo utente | Tutti i piani |
| Repository Instructions | Singolo repository | Media | Team di progetto | Tutti i piani |
| Organization Instructions | Intera organizzazione | Bassa (base) | Org owners | Enterprise |
Come Funziona la Combinazione
Quando Copilot riceve una richiesta, raccoglie le istruzioni da tutti i livelli disponibili e le combina in un unico contesto. Se ci sono conflitti, le istruzioni con priorità' più' alta prevalgono. Ad esempio, se le istruzioni dell'organizzazione richiedono risposte in inglese ma le istruzioni personali specificano l'italiano, Copilot risponde in italiano.
Le istruzioni personalizzate vengono aggiunte automaticamente come contesto alle conversazioni con Copilot Chat. Non vengono applicate ai suggerimenti inline di completamento codice, ma influenzano le risposte in chat, nell'agent mode e nelle review.
Personal Instructions
Le istruzioni personali si applicano a tutte le conversazioni che hai con Copilot Chat sul sito web di GitHub (github.com). Sono il modo più' diretto per personalizzare il comportamento di Copilot secondo le tue preferenze individuali.
Cosa Puoi Configurare
Le istruzioni personali sono ideali per definire preferenze che si applicano a qualsiasi progetto su cui lavori. Ecco le categorie principali di personalizzazione:
Categorie di Personalizzazione Personale
| Categoria | Esempio | Effetto |
|---|---|---|
| Lingua | Rispondi sempre in italiano | Tutte le risposte saranno in italiano |
| Stile di risposta | Sii conciso, max 200 parole | Risposte brevi e dirette |
| Formato | Usa sempre code blocks con linguaggio | Codice formattato correttamente |
| Competenze | Sono uno sviluppatore senior Java | Risposte a livello avanzato |
| Preferenze tecniche | Preferisco functional programming | Suggerimenti in stile funzionale |
| Contesto lavorativo | Lavoro su microservizi Spring Boot | Suggerimenti contestualizzati |
Come Configurare le Istruzioni Personali
Per configurare le istruzioni personali su GitHub:
- Vai su github.com e fai login
- Clicca sulla tua foto profilo in alto a destra
- Seleziona Settings
- Nella barra laterale, clicca su Copilot
- Nella sezione "Personal instructions", clicca Edit
- Scrivi le tue istruzioni nella text area
- Clicca Save
Esempio di Istruzioni Personali Efficaci
# Profilo Sviluppatore
Sono un senior full-stack developer con 8 anni di esperienza.
Stack principale: Java (Spring Boot), TypeScript (Angular), PostgreSQL.
Lavoro su architetture a microservizi in ambiente cloud (AWS).
# Preferenze Lingua
Rispondi sempre in italiano.
Usa terminologia tecnica in inglese quando appropriato
(es. "dependency injection", "middleware", "endpoint").
# Stile di Risposta
- Sii conciso e vai dritto al punto
- Fornisci sempre esempi di codice quando possibile
- Includi commenti nel codice solo per logica complessa
- Specifica le versioni quando suggerisci dipendenze
- Segnala potenziali problemi di performance o sicurezza
# Convenzioni di Codice
- Java: Google Java Style Guide
- TypeScript: ESLint con configurazione strict
- SQL: uppercase per keywords, lowercase per nomi tabelle
- Naming: camelCase per variabili, PascalCase per classi
- Test: pattern Given-When-Then per test names
# Anti-Pattern da Evitare
- Non suggerire mai codice senza gestione errori
- Non usare "any" in TypeScript
- Non suggerire query SQL con SELECT *
- Non ignorare la validazione degli input
Limitazioni delle Personal Instructions
Le istruzioni personali si applicano solo alle conversazioni su github.com (Copilot Chat nel browser). Non influenzano direttamente i suggerimenti nell'IDE (VS Code, JetBrains). Per personalizzare il comportamento nell'IDE, usa le repository instructions o le impostazioni specifiche dell'editor.
Inoltre, le istruzioni personali non hanno un limite di caratteri esplicito come quelle dell'organizzazione, ma e' buona pratica mantenerle concise per non sovraccaricare il contesto del modello.
Repository Instructions
Le istruzioni di repository sono il livello di personalizzazione più' potente per i team di sviluppo. Vengono definite tramite file all'interno del repository e si applicano automaticamente a tutti i membri del team che lavorano su quel progetto.
File Principale: .github/copilot-instructions.md
Il file principale per le istruzioni di repository e' .github/copilot-instructions.md.
Questo file viene letto automaticamente da Copilot ogni volta che un utente interagisce con
il repository. Il contenuto viene aggiunto come contesto a tutte le conversazioni di Copilot
Chat relative al progetto.
# Copilot Instructions per TaskFlow Frontend
## Stack Tecnologico
- Framework: Angular 21 con standalone components
- Linguaggio: TypeScript 5.9 strict mode
- Styling: SCSS con BEM methodology
- State Management: Angular Signals
- HTTP: Angular HttpClient con interceptors
- Routing: Angular Router con lazy loading
- Testing: Jasmine + Karma per unit, Cypress per E2E
## Convenzioni di Codice
### Componenti
- Usa SEMPRE standalone components (no NgModules)
- Change detection: OnPush per tutti i componenti
- Usa signals() per stato reattivo, non BehaviorSubject
- Template: file separato (.html) per componenti > 20 righe
- Stili: file separato (.scss) sempre
### Naming Conventions
- Componenti: PascalCase con suffisso Component (es. UserProfileComponent)
- Servizi: PascalCase con suffisso Service (es. AuthService)
- Interfacce: PascalCase con prefisso I (es. IUserProfile)
- File: kebab-case (es. user-profile.component.ts)
- Costanti: UPPER_SNAKE_CASE (es. MAX_RETRY_COUNT)
### Pattern Obbligatori
- Ogni servizio HTTP deve avere error handling centralizzato
- Usare pipe async o toSignal() nel template, mai subscribe manuale
- Route guards come functional guards (non class-based)
- Form: reactive forms con FormBuilder, mai template-driven
- Validazione: custom validators in file separato
### Struttura Directory
```
src/app/
features/ # Feature modules (lazy loaded)
shared/ # Componenti, pipe, direttive condivise
core/ # Servizi singleton, interceptors, guards
models/ # Interfacce e tipi
environments/ # Configurazioni ambiente
```
### Testing
- Ogni componente DEVE avere unit test
- Coverage minima: 80% per servizi, 70% per componenti
- Mock pattern: usa jasmine.createSpyObj per dipendenze
- Naming test: "should [expected behavior] when [condition]"
### Performance
- Lazy load tutte le feature routes
- Usa trackBy per *ngFor (o @for con track)
- Immagini: usa NgOptimizedImage
- Bundle size alert: > 500KB per chunk e' un warning
### Accessibilita'
- Ogni elemento interattivo deve avere aria-label
- Contrasto colori: WCAG AA (4.5:1 minimo)
- Tab navigation deve funzionare per tutti i form
- Screen reader: testare con NVDA o VoiceOver
Path-Specific Instructions
Oltre al file generale, Copilot supporta istruzioni specifiche per determinati percorsi del repository. Queste istruzioni vengono caricate solo quando si lavora su file che corrispondono ai pattern specificati.
I file path-specific devono essere posizionati nella directory
.github/instructions/ con estensione .instructions.md.
Ogni file include un header YAML che specifica a quali percorsi si applicano.
---
applyTo: "**/*.spec.ts"
---
# Istruzioni per File di Test
## Struttura Test
- Usa describe() per raggruppare test per metodo/funzionalità'
- Usa beforeEach() per setup comune
- Pattern AAA: Arrange, Act, Assert in ogni test
## Naming Convention
- describe: nome della classe/funzione sotto test
- it/test: "should [cosa fa] when [condizione]"
## Mock Pattern
```typescript
const mockService = jasmine.createSpyObj('ServiceName', ['method1', 'method2']);
mockService.method1.and.returnValue(of(expectedResult));
```
## Coverage Requirements
- Branch coverage: >= 80%
- Line coverage: >= 85%
- Ogni path condizionale deve avere almeno un test
## Anti-Pattern da Evitare
- Non testare dettagli implementativi
- Non fare mock di tutto (testa integrazione dove possibile)
- Non usare setTimeout() nei test (usa fakeAsync/tick)
- Non ignorare test flaky: fixali o rimuovili
---
applyTo: "src/app/core/services/**/*.ts"
---
# Istruzioni per Servizi API
## Pattern Obbligatorio
Ogni servizio API deve seguire questo 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> {
// Centralizzato nell'interceptor, qui solo log specifico
console.error(`EntityService error: ${error.message}`);
return throwError(() => error);
}
}
```
## Regole
- Tutti i metodi HTTP devono restituire Observable<T>
- Error handling tramite interceptor globale + log locale
- URL base da environment, mai hardcoded
- Metodi CRUD standard: getAll, getById, create, update, delete
- Usare HttpParams per query parameters
- Cache con shareReplay(1) dove appropriato
---
applyTo: "src/app/features/**/*.component.ts"
---
# Istruzioni per Componenti Feature
## Template Componente Standard
```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 per stato locale
readonly items = signal<Item[]>([]);
readonly loading = signal(false);
readonly error = signal<string | null>(null);
// Computed per derivazioni
readonly itemCount = computed(() => this.items().length);
// Inject dependencies
private readonly service = inject(FeatureService);
private readonly destroyRef = inject(DestroyRef);
}
```
## Regole
- OnPush change detection OBBLIGATORIO
- Signals per tutto lo stato locale
- inject() function, non constructor injection
- DestroyRef per cleanup sottoscrizioni
- Template max 50 righe, altrimenti splitta in sub-componenti
Esempio Completo di Repository Instructions per Spring Boot
# Copilot Instructions per TaskFlow Backend
## Stack
- Java 21 con Spring Boot 3.3
- Build: Gradle Kotlin DSL
- Database: PostgreSQL 16 con Flyway migrations
- Cache: Redis 7
- Auth: Spring Security + JWT
- API: REST con OpenAPI 3.1 documentation
- Testing: JUnit 5 + Mockito + Testcontainers
## Architettura
Hexagonal Architecture (Ports and Adapters):
```
src/main/java/com/taskflow/
domain/ # Entità', value objects, eccezioni di dominio
application/ # Use cases, DTO, port interfaces
infrastructure/ # Adapter: DB, HTTP, messaging
config/ # Spring configuration
```
## Convenzioni Java
- Record per DTO immutabili
- Sealed interface per gerarchia tipi controllata
- Optional solo come return type, mai come parametro
- Stream API per operazioni su collection
- Naming: verbo + sostantivo per metodi (es. createOrder, findUserById)
## API Design
- Endpoint: /api/v1/{resource} (plurale)
- Response: wrapper con 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 con naming V{version}__{description}.sql
- Naming tabelle: snake_case, plurale (es. user_profiles)
- Ogni tabella: id (UUID), created_at, updated_at
- Indici: su tutte le foreign key e campi di ricerca frequente
- NO cascade delete: gestire esplicitamente
## Security
- Input validation su TUTTI gli endpoint
- SQL injection: solo PreparedStatement/JPA
- Rate limiting: 100 req/min per user
- CORS: whitelist esplicita
- Secrets: mai in codice, sempre da environment
Best Practices per Repository Instructions
- Versionamento: Le repository instructions sono file nel repo, quindi vengono versionati con Git. Ogni modifica e' tracciabile.
- Review: Tratta le modifiche alle istruzioni come cambiamenti al codice: fai PR e code review.
- Concisione: Istruzioni troppo lunghe possono diluire il contesto. Concentrati su regole chiare e specifiche.
- Specificità': Evita istruzioni generiche. Sii specifico su framework, versioni, pattern e convenzioni.
- Aggiornamento: Aggiorna le istruzioni quando cambiano le convenzioni del team o le dipendenze del progetto.
Organization Instructions
Le istruzioni organizzative sono disponibili esclusivamente per gli abbonamenti GitHub Copilot Enterprise e Business. Permettono agli owner dell'organizzazione di definire preferenze che si applicano a tutti i membri e a tutti i repository dell'organizzazione.
Configurazione
Per configurare le istruzioni organizzative:
- Naviga alla pagina dell'organizzazione su GitHub
- Vai su Settings → Copilot → Custom instructions
- Abilita la funzionalità' tramite il toggle
- Scrivi le istruzioni nella text area dedicata
- Salva le modifiche
Caratteristiche delle Organization Instructions
| Caratteristica | Dettaglio |
|---|---|
| Limite caratteri | 4.000 caratteri massimo |
| Versionamento | NON version-controlled (no Git) |
| Visibilità' | Solo org owners possono vedere/modificare |
| Applicazione | Automatica su tutti i membri dell'org |
| Override | Possono essere sovrascritte da repo e personal instructions |
| Disponibilità' | Solo Enterprise e Business |
# Acme Corp - GitHub Copilot Instructions
## Lingua
Rispondi sempre in italiano per il team italiano,
in inglese per tutti gli altri.
## Standard di Sicurezza
- Non suggerire mai codice che espone secrets o credenziali
- Includi sempre input validation negli endpoint
- Usa prepared statements per tutte le query database
- Implementa rate limiting su ogni API pubblica
- Log sensibili: mai loggare PII, token o password
## Convenzioni Codice Aziendali
- Tutti i servizi devono avere interfaccia + implementazione
- Naming: prefisso "Acme" per package base (com.acme.*)
- Documentazione JavaDoc obbligatoria per metodi pubblici
- Commit message: Conventional Commits format
- Branch naming: feature/, bugfix/, hotfix/ + JIRA ticket
## Compliance
- Codice deve essere compatibile GDPR
- Dati utente: sempre criptati a riposo
- Log retention: max 90 giorni
- Audit trail obbligatorio per operazioni CRUD su dati sensibili
## Librerie Approvate
- HTTP Client: OkHttp o Spring WebClient (no Apache HC legacy)
- JSON: Jackson (no Gson)
- Logging: SLF4J + Logback
- Testing: JUnit 5 + AssertJ + Mockito
Limitazione Importante: 4.000 Caratteri
Il limite di 4.000 caratteri per le organization instructions può' sembrare restrittivo, soprattutto per organizzazioni grandi con molte convenzioni. La strategia consigliata e' di inserire nelle org instructions solo le regole universali e critiche (sicurezza, compliance, naming base), delegando le regole specifiche per progetto alle repository instructions.
Model Context Protocol (MCP) Integration
Il Model Context Protocol (MCP) e' uno standard aperto che permette di connettere Copilot a strumenti e fonti di dati esterne. Attraverso MCP, Copilot può' accedere a database, API, sistemi di documentazione e molto altro, ampliando significativamente le sue capacità'.
GitHub MCP Registry
GitHub offre un MCP Registry curato, che funge da catalogo di server MCP verificati e sicuri. Questo registro permette di scoprire e integrare rapidamente server MCP senza dover configurare manualmente ogni connessione.
Tipi di Server MCP
| Tipo | Trasporto | Dove Gira | Caso d'Uso | Configurazione |
|---|---|---|---|---|
| Remote (HTTP/SSE) | HTTP con Server-Sent Events | Server remoto | API cloud, SaaS, servizi condivisi | URL + autenticazione |
| Local (stdio) | Standard I/O (stdin/stdout) | Macchina locale | Database locali, file system, tool CLI | Comando + argomenti |
Configurazione MCP nell'IDE
Per configurare server MCP in VS Code, crea o modifica il file .vscode/mcp.json
nella root del progetto. Questo file definisce quali server MCP sono disponibili per
Copilot durante lo sviluppo.
{
"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 e Coding Agent
L'integrazione MCP e' particolarmente potente quando combinata con il Coding Agent di Copilot. L'agente può' utilizzare i tool MCP per raccogliere informazioni, eseguire query e interagire con sistemi esterni durante il processo di sviluppo automatizzato.
Casi d'Uso MCP con Coding Agent
| Scenario | Server MCP | Azione dell'Agente |
|---|---|---|
| Bug fix da issue | GitHub + Sentry | Legge l'issue, recupera stack trace da Sentry, analizza il codice e propone fix |
| Nuova feature | GitHub + Database | Legge i requisiti dall'issue, analizza lo schema DB, genera codice e test |
| Documentazione | Filesystem + API docs | Analizza il codice sorgente, aggiorna documentazione API automaticamente |
| Migrazione dati | PostgreSQL + Redis | Analizza struttura attuale, genera script di migrazione, verifica integrita' |
| Performance tuning | Prometheus + Database | Raccoglie metriche, identifica query lente, suggerisce ottimizzazioni |
Policy Enterprise per MCP
Per le organizzazioni Enterprise e Business, la policy "MCP servers in Copilot" deve essere esplicitamente abilitata dagli amministratori dell'organizzazione. Per default, questa policy e' disabilitata.
Quando abilitata, i proprietari possono controllare quali server MCP sono accessibili ai membri dell'organizzazione, garantendo che solo fonti dati approvate vengano utilizzate.
Content Exclusion
La content exclusion permette di escludere file e directory specifici dall'elaborazione di Copilot. Questo e' fondamentale per proteggere codice sensibile, proprietary code o file che contengono segreti o configurazioni riservate.
Livelli di Content Exclusion
Confronto Livelli di Exclusion
| Livello | Configurato da | Ambito | Disponibilità' |
|---|---|---|---|
| Repository | Repository admin | File nel repository specifico | Enterprise e Business |
| Organization | Org owner | File in qualsiasi repo dell'org | Enterprise e Business |
| Enterprise | Enterprise admin | File in tutte le org dell'enterprise | Enterprise |
Cosa Viene Escluso
Quando un file viene contrassegnato per l'esclusione, Copilot lo ignora in diversi contesti:
Impatto della Content Exclusion
| Funzionalità' | Effetto dell'Esclusione |
|---|---|
| Completamento inline | Nessun suggerimento generato per file esclusi |
| Copilot Chat | File esclusi non usati come contesto nelle risposte |
| Code Review | Nessun commento di review su file esclusi |
| Copilot Edits | File esclusi non modificabili dall'agent |
| Coding Agent | L'agente non può' leggere o modificare file esclusi |
Configurazione Content Exclusion
# Formato: un pattern per riga
# Supporta glob patterns
# Escludere file di configurazione sensibili
*.env
*.env.*
config/secrets/**
# Escludere codice legacy non modificabile
legacy/**
vendor/**
# Escludere file generati automaticamente
generated/**
dist/**
node_modules/**
# Escludere file con dati sensibili
**/credentials*
**/private-keys/**
**/*.pem
**/*.key
# Escludere directory specifiche
src/app/proprietary/**
src/internal/billing/**
# Escludere file di test con dati sensibili
test/fixtures/sensitive-data/**
Limitazioni della Content Exclusion
- Symlink: I file raggiungibili tramite symlink non vengono esclusi automaticamente. L'esclusione si basa sul percorso reale del file.
- Remote filesystem: L'esclusione non funziona per file su filesystem remoti (es. SSH, SFTP).
- Propagazione: Le modifiche alle regole di esclusione possono richiedere fino a 30 minuti per propagarsi a tutti gli utenti.
- Submodule: I file in Git submodule richiedono regole di esclusione separate per il repository del submodule.
Strategie di Personalizzazione per Team
Combinare efficacemente i tre livelli di personalizzazione richiede una strategia chiara. Ecco un approccio raccomandato per team di diverse dimensioni.
Piccoli Team (2-5 sviluppatori)
Cosa Fare
- Focus sulle repository instructions
- Un file copilot-instructions.md per repo
- Istruzioni path-specific per aree critiche
- Personal instructions per preferenze individuali
- Review periodica delle istruzioni (mensile)
Cosa Evitare
- Organization instructions (overkill per piccoli team)
- Istruzioni troppo dettagliate (diminishing returns)
- Duplicazione tra personal e repo instructions
- Regole che non vengono applicate nella pratica
- Aggiornamenti troppo frequenti
Team Medi (5-20 sviluppatori)
Cosa Fare
- Repository instructions dettagliate per ogni progetto
- Path-specific instructions per test, API, modelli
- Organization instructions per standard trasversali
- Content exclusion per codice sensibile
- Review trimestrale con il team
- Template di istruzioni per nuovi repository
Cosa Evitare
- Istruzioni conflittuali tra livelli
- Lasciare istruzioni obsolete
- Ignorare il feedback degli sviluppatori
- Regole troppo rigide che frustrano il team
- Mancanza di ownership sulle istruzioni
Grandi Organizzazioni (20+ sviluppatori)
Cosa Fare
- Organization instructions per policy aziendali
- Template repository instructions per ogni tipo di progetto
- Content exclusion enterprise-wide
- MCP servers centralizzati e approvati
- Processo formale per modifiche alle istruzioni
- Metriche sull'efficacia delle istruzioni
- Onboarding guide per nuovi sviluppatori
Cosa Evitare
- Istruzioni organizzative troppo restrittive
- Bypassare il sistema con personal instructions
- Mancanza di governance sugli MCP servers
- Non monitorare l'adozione delle istruzioni
- Ignorare le esigenze di team specializzati
- Trattenere il valore delle istruzioni: condividile
Esempio Pratico: Setup Completo per un Progetto
Vediamo come configurare la personalizzazione completa per un progetto reale, combinando tutti i livelli.
my-project/
.github/
copilot-instructions.md # Istruzioni generali del progetto
instructions/
testing.instructions.md # Regole per file di test
api-controllers.instructions.md # Regole per controller API
database.instructions.md # Regole per query e migrations
components.instructions.md # Regole per componenti UI
.vscode/
mcp.json # Server MCP del progetto
settings.json # Impostazioni VS Code
# A livello organizzazione (UI GitHub):
# - Organization Instructions (4000 char max)
# - Content Exclusion patterns
# - MCP server policy
# A livello personale (Settings GitHub):
# - Personal Instructions
# - Preferenze lingua e stile
Workflow di Manutenzione delle Istruzioni
Processo di Aggiornamento
| Frequenza | Azione | Responsabile | Trigger |
|---|---|---|---|
| Ad hoc | Aggiornare personal instructions | Singolo sviluppatore | Cambio preferenze |
| Per sprint | Review repo instructions | Tech lead | Nuove convenzioni adottate |
| Mensile | Aggiornare path-specific instructions | Team | Feedback sviluppatori |
| Trimestrale | Review org instructions | Org owner + leads | Cambio policy aziendali |
| Trimestrale | Audit content exclusion | Security team | Review sicurezza |
| Semestrale | Review completa MCP servers | Platform team | Nuovi tool disponibili |
Risoluzione dei Problemi Comuni
Troubleshooting Personalizzazione
| Problema | Causa Probabile | Soluzione |
|---|---|---|
| Istruzioni repo non applicate | File non nel percorso corretto | Verificare che il file sia in .github/copilot-instructions.md |
| Path-specific instructions ignorate | Pattern YAML errato | Verificare formato applyTo nel frontmatter YAML |
| Org instructions non visibili | Feature non abilitata | Abilitare toggle in Settings → Copilot → Custom instructions |
| MCP server non connesso | Policy disabilitata | Chiedere all'org admin di abilitare "MCP servers in Copilot" |
| Content exclusion non funziona | Propagazione in corso | Attendere fino a 30 minuti per la propagazione completa |
| Conflitto tra istruzioni | Istruzioni contraddittorie | Verificare la gerarchia: personal > repo > org |
| Istruzioni troppo verbose | Contesto saturo | Ridurre a regole essenziali, usare path-specific per dettagli |
Checklist di Personalizzazione
Checklist Setup Personalizzazione Copilot
| Area | Azione | Completato |
|---|---|---|
| Personal | Definire lingua preferita per le risposte | ☐ |
| Specificare livello di esperienza e stack | ☐ | |
| Configurare stile di risposta preferito | ☐ | |
| Repository | Creare .github/copilot-instructions.md | ☐ |
| Definire stack, convenzioni e pattern | ☐ | |
| Aggiungere path-specific instructions per test | ☐ | |
| Aggiungere path-specific instructions per API | ☐ | |
| Organizzazione | Definire standard di sicurezza nelle org instructions | ☐ |
| Configurare content exclusion per dati sensibili | ☐ | |
| Abilitare e configurare policy MCP servers | ☐ | |
| MCP | Configurare .vscode/mcp.json nel progetto | ☐ |
| Testare connessione ai server MCP | ☐ | |
| Documentare i server MCP disponibili per il team | ☐ | |
| Manutenzione | Stabilire processo di review periodica | ☐ |
| Creare template per nuovi repository | ☐ |
Conclusione
La personalizzazione di GitHub Copilot e' un investimento che ripaga rapidamente in termini di produttività' e qualità' del codice. Istruzioni ben configurate trasformano Copilot da un suggeritore generico a un assistente che conosce il tuo stack, le tue convenzioni e le regole del tuo team.
La chiave del successo e' un approccio incrementale: inizia con le repository instructions di base, aggiungi path-specific instructions man mano che identifichi aree che beneficiano di guida specifica, e scala alle organization instructions quando il team cresce. L'integrazione MCP e la content exclusion completano il quadro, garantendo che Copilot sia sia potente che sicuro.
Nel prossimo articolo esploreremo le opzioni Enterprise e Business di Copilot, con approfondimenti su pricing, analytics, policy management e ROI per le organizzazioni.
Progresso della Serie
| # | Articolo | Stato |
|---|---|---|
| 1 | Foundation e Mindset | ✅ |
| 2 | Ideazione e Requisiti | ✅ |
| 3 | Architettura Backend/Frontend | ✅ |
| 4 | Struttura del Codice | ✅ |
| 5 | Prompt Engineering | ✅ |
| 6 | Testing e qualità' | ✅ |
| 7 | Documentazione | ✅ |
| 8 | Deploy e DevOps | ✅ |
| 9 | Evoluzione | ✅ |
| 10 | Coding Agent | ✅ |
| 11 | Code Review | ✅ |
| 12 | Copilot Edits | ✅ |
| 13 | GitHub Spark | ✅ |
| 14 | Copilot Spaces | ✅ |
| 15 | Modelli AI | ✅ |
| 16 | Personalizzazione Avanzata | 📍 |
| 17 | Enterprise e Business | ◻ |
| 18 | Extensions e Marketplace | ◻ |
| 19 | Sicurezza e Uso Responsabile | ◻ |

Commenti
Caricamento commenti...
Accedi per commentare