Salta al contenuto principale

16 - Personalizzazione Avanzata di Copilot

Tre livelli di personalizzazione: istruzioni personali, repository (.github/copilot-instructions.md) e organizzazione. Integrazione MCP e content exclusion.

Cosa ne pensi di questo articolo?

16 - Personalizzazione Avanzata di Copilot
GitHub CopilotFoto:Christina MorilloPexels

In Breve

Tre livelli di personalizzazione: istruzioni personali, repository (.github/copilot-instructions.md) e organizzazione. Integrazione MCP e content exclusion.

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

#ArticoloFocus
1Foundation e MindsetSetup e mentalita'
2Ideazione e RequisitiDa idea a MVP
3Architettura Backend/FrontendAPI e database
4Struttura del CodiceOrganizzazione e naming
5Prompt EngineeringPrompt e Agenti MCP
6Testing e qualità'Unit, integration, E2E
7DocumentazioneREADME, API docs, ADR
8Deploy e DevOpsDocker, CI/CD
9EvoluzioneScalabilità' e manutenzione
10Coding AgentAgente autonomo GitHub
11Code ReviewReview automatizzata
12Copilot EditsEditing multi-file
13GitHub SparkMicro-app senza codice
14Copilot SpacesContesto condiviso
15Modelli AIMulti-model e selezione
16Sei qui → PersonalizzazioneIstruzioni e configurazione
17Enterprise e BusinessPiani, analytics, policy
18Extensions e MarketplaceEstensioni e integrazioni
19Sicurezza e Uso ResponsabileSecurity 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

LivelloAmbitoPriorità'Gestito daDisponibilità'
Personal InstructionsTutte le conversazioni personaliAlta (override)Singolo utenteTutti i piani
Repository InstructionsSingolo repositoryMediaTeam di progettoTutti i piani
Organization InstructionsIntera organizzazioneBassa (base)Org ownersEnterprise

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

CategoriaEsempioEffetto
LinguaRispondi sempre in italianoTutte le risposte saranno in italiano
Stile di rispostaSii conciso, max 200 paroleRisposte brevi e dirette
FormatoUsa sempre code blocks con linguaggioCodice formattato correttamente
CompetenzeSono uno sviluppatore senior JavaRisposte a livello avanzato
Preferenze tecnichePreferisco functional programmingSuggerimenti in stile funzionale
Contesto lavorativoLavoro su microservizi Spring BootSuggerimenti contestualizzati

Come Configurare le Istruzioni Personali

Per configurare le istruzioni personali su GitHub:

  1. Vai su github.com e fai login
  2. Clicca sulla tua foto profilo in alto a destra
  3. Seleziona Settings
  4. Nella barra laterale, clicca su Copilot
  5. Nella sezione "Personal instructions", clicca Edit
  6. Scrivi le tue istruzioni nella text area
  7. Clicca Save

Esempio di Istruzioni Personali Efficaci

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

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

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

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

  1. Naviga alla pagina dell'organizzazione su GitHub
  2. Vai su Settings → Copilot → Custom instructions
  3. Abilita la funzionalità' tramite il toggle
  4. Scrivi le istruzioni nella text area dedicata
  5. Salva le modifiche

Caratteristiche delle Organization Instructions

CaratteristicaDettaglio
Limite caratteri4.000 caratteri massimo
VersionamentoNON version-controlled (no Git)
Visibilità'Solo org owners possono vedere/modificare
ApplicazioneAutomatica su tutti i membri dell'org
OverridePossono essere sovrascritte da repo e personal instructions
Disponibilità'Solo Enterprise e Business
Esempio - Organization Instructions
# 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

TipoTrasportoDove GiraCaso d'UsoConfigurazione
Remote (HTTP/SSE)HTTP con Server-Sent EventsServer remotoAPI cloud, SaaS, servizi condivisiURL + autenticazione
Local (stdio)Standard I/O (stdin/stdout)Macchina localeDatabase locali, file system, tool CLIComando + 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.

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

ScenarioServer MCPAzione dell'Agente
Bug fix da issueGitHub + SentryLegge l'issue, recupera stack trace da Sentry, analizza il codice e propone fix
Nuova featureGitHub + DatabaseLegge i requisiti dall'issue, analizza lo schema DB, genera codice e test
DocumentazioneFilesystem + API docsAnalizza il codice sorgente, aggiorna documentazione API automaticamente
Migrazione datiPostgreSQL + RedisAnalizza struttura attuale, genera script di migrazione, verifica integrita'
Performance tuningPrometheus + DatabaseRaccoglie 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

LivelloConfigurato daAmbitoDisponibilità'
RepositoryRepository adminFile nel repository specificoEnterprise e Business
OrganizationOrg ownerFile in qualsiasi repo dell'orgEnterprise e Business
EnterpriseEnterprise adminFile in tutte le org dell'enterpriseEnterprise

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 inlineNessun suggerimento generato per file esclusi
Copilot ChatFile esclusi non usati come contesto nelle risposte
Code ReviewNessun commento di review su file esclusi
Copilot EditsFile esclusi non modificabili dall'agent
Coding AgentL'agente non può' leggere o modificare file esclusi

Configurazione Content Exclusion

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

Struttura File di Personalizzazione
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

FrequenzaAzioneResponsabileTrigger
Ad hocAggiornare personal instructionsSingolo sviluppatoreCambio preferenze
Per sprintReview repo instructionsTech leadNuove convenzioni adottate
MensileAggiornare path-specific instructionsTeamFeedback sviluppatori
TrimestraleReview org instructionsOrg owner + leadsCambio policy aziendali
TrimestraleAudit content exclusionSecurity teamReview sicurezza
SemestraleReview completa MCP serversPlatform teamNuovi tool disponibili

Risoluzione dei Problemi Comuni

Troubleshooting Personalizzazione

ProblemaCausa ProbabileSoluzione
Istruzioni repo non applicateFile non nel percorso correttoVerificare che il file sia in .github/copilot-instructions.md
Path-specific instructions ignoratePattern YAML erratoVerificare formato applyTo nel frontmatter YAML
Org instructions non visibiliFeature non abilitataAbilitare toggle in Settings → Copilot → Custom instructions
MCP server non connessoPolicy disabilitataChiedere all'org admin di abilitare "MCP servers in Copilot"
Content exclusion non funzionaPropagazione in corsoAttendere fino a 30 minuti per la propagazione completa
Conflitto tra istruzioniIstruzioni contraddittorieVerificare la gerarchia: personal > repo > org
Istruzioni troppo verboseContesto saturoRidurre a regole essenziali, usare path-specific per dettagli

Checklist di Personalizzazione

Checklist Setup Personalizzazione Copilot

AreaAzioneCompletato
PersonalDefinire lingua preferita per le risposte☐
Specificare livello di esperienza e stack☐
Configurare stile di risposta preferito☐
RepositoryCreare .github/copilot-instructions.md☐
Definire stack, convenzioni e pattern☐
Aggiungere path-specific instructions per test☐
Aggiungere path-specific instructions per API☐
OrganizzazioneDefinire standard di sicurezza nelle org instructions☐
Configurare content exclusion per dati sensibili☐
Abilitare e configurare policy MCP servers☐
MCPConfigurare .vscode/mcp.json nel progetto☐
Testare connessione ai server MCP☐
Documentare i server MCP disponibili per il team☐
ManutenzioneStabilire 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

#ArticoloStato
1Foundation e Mindset✅
2Ideazione e Requisiti✅
3Architettura Backend/Frontend✅
4Struttura del Codice✅
5Prompt Engineering✅
6Testing e qualità'✅
7Documentazione✅
8Deploy e DevOps✅
9Evoluzione✅
10Coding Agent✅
11Code Review✅
12Copilot Edits✅
13GitHub Spark✅
14Copilot Spaces✅
15Modelli AI✅
16Personalizzazione Avanzata📍
17Enterprise e Business◻
18Extensions e Marketplace◻
19Sicurezza e Uso Responsabile◻

Prova Questi Strumenti

Strumenti gratuiti correlati a questo argomento.

Commenti

Caricamento commenti...

Accedi per commentare

Discuti questo articolo nella community

Unisciti al gruppo Telegram per discutere con altri sviluppatori, fare domande e condividere le tue esperienze.

Ti è piaciuto questo articolo?

Esplora altri contenuti sul blog o scopri i miei progetti