こんにちは！

Federico Calò

Sviluppatore Software | Divulgatore Tecnico

Creo applicazioni web moderne e strumenti digitali personalizzati per aiutare le attività a crescere attraverso l'innovazione tecnologica. La mia passione è unire informatica ed economia per generare valore reale.

お問い合わせ

自己紹介

La mia passione per l'informatica è nata tra i banchi dell'Istituto Tecnico Commerciale di Maglie, dove ho scoperto il potere della programmazione e il fascino di creare soluzioni digitali. Fin da subito, ho capito che l'informatica non era solo codice, ma uno strumento straordinario per trasformare idee in realtà.

Durante gli studi superiori in Sistemi Informativi Aziendali, ho iniziato a intrecciare informatica ed economia, comprendendo come la tecnologia possa essere il motore della crescita per qualsiasi attività. Questa visione mi ha accompagnato all'Università degli Studi di Bari, dove ho conseguito la Laurea in Informatica, approfondendo le mie competenze tecniche e la mia passione per lo sviluppo software.

Oggi metto questa esperienza al servizio di imprese, professionisti e startup, creando soluzioni digitali su misura che automatizzano processi, ottimizzano risorse e aprono nuove opportunità di business. Perché la vera innovazione inizia quando la tecnologia incontra le esigenze reali delle persone.

スキル

Analisi Dati & Modelli Previsionali

Trasformo i dati in insights strategici con analisi approfondite e modelli predittivi per decisioni informate

プロセス自動化

Creo strumenti personalizzati che automatizzano operazioni ripetitive e liberano tempo per attività a valore aggiunto

カスタムシステム

Sviluppo sistemi software su misura, dalle integrazioni tra piattaforme alle dashboard personalizzate

const federico = {
  nome: "Federico Calò",
  ruolo: "Sviluppatore Software",
  città: "Bari, Italia",
  missione: "Aiutare attraverso l'informatica",
  passioni: [
    "Codice Pulito",
    "Innovazione",
    "Crescita Continua"
  ]
};

ミッション

Credo fermamente che l'informatica sia lo strumento più potente per trasformare le idee in realtà e migliorare la vita delle persone.

🚀

テクノロジーの民主化

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.

💡

ITとビジネスの融合

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à.

🎯

カスタムソリューション

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.

テクノロジーでビジネスを変革

Dicembre 2024

Visualizza

Master SQL

RoadMap.sh

Novembre 2024

Visualizza

Oracle Certified Foundations Associate

Oracle

Ottobre 2024

Visualizza

People Leadership Credential

Connect

Settembre 2024

💻 Linguaggi & Tecnologie

☕Java

🐍Python

📜JavaScript

🅰️Angular

⚛️React

🔷TypeScript

🗄️SQL

🐘PHP

🎨CSS/SCSS

🔧Node.js

🐳Docker

🌿Git

💼

12/2024 - Presente

Custom Software Engineering Analyst

Accenture

Bari, Puglia, Italia · Ibrida Analisi e sviluppo di sistemi informatici attraverso l'utilizzo di Java e Quarkus in Health and Public Sector. Formazione continua su tecnologie moderne per la creazione di soluzioni software personalizzate ed efficienti e sugli agenti.

💼

06/2022 - 12/2024

Analista software e Back End Developer Associate Consultant

Links Management and Technology SpA

Esperienza nell'analisi di sistemi software as-is e flussi ETL utilizzando PowerCenter. Formazione completata su Spring Boot per lo sviluppo di applicazioni backend moderne e scalabili. Sviluppatore Backend specializzato in Spring Boot, con esperienza in progettazione di database, analisi, sviluppo e testing dei task assegnati.

💼

02/2021 - 10/2021

Programmatore software

Adesso.it (prima era WebScience srl)

Esperienza nell'analisi AS-IS e TO-BE, evoluzioni SEO ed evoluzioni website per migliorare le performance e l'engagement degli utenti.

🎓

2018 - 2025

Laurea in Informatica

Università degli Studi di Bari Aldo Moro

Bachelor's degree in Computer Science, focusing on software engineering, algorithms, and modern development practices.

📚

2013 - 2018

Diploma - Sistemi Informativi Aziendali

Istituto Tecnico Commerciale di Maglie

Technical diploma specializing in Business Information Systems, combining IT knowledge with business management.

お問い合わせ

プロジェクトをお考えですか？お気軽にお問い合わせください。

* Campi obbligatori. I tuoi dati saranno utilizzati solo per rispondere alla tua richiesta.

コパイロットスペース、エージェントメモリ、およびリポジトリのインデックス作成

AI アシスタントの応答の品質を決定する最も重要な要素の 1 つそれは コンテクスト。言語モデルがプロジェクトを理解すればするほど、あなたの慣習と目標が一致すればするほど、より良い提案が生成されます。最近まで、Copilot にコンテキストを提供するには、ファイルを開くという手動の作業が必要でした。関連性のあるもの、詳細なプロンプトを作成する、セッションですでに提供された情報を繰り返す前例。

の導入により、 副操縦士スペース, エージェント記憶 e の改善点 リポジトリのインデックス作成、GitHub がこれに対処しました構造的な問題。これら 3 つのツールは相乗効果を発揮して、 Copilot は常に適切なタイミングで適切なコンテキストを取得できるため、コストが大幅に削減されます。情報を繰り返す必要性と、時間の経過とともに応答の一貫性を向上させる必要性。

シリーズの 14 番目の記事では、それぞれについて詳しく説明します。これらのツール: ツールの仕組み、構成方法、および最適な使用方法日々の業務の生産性を最大化します。

シリーズ全体の概要

#	アイテム	集中
1	基礎と考え方	セットアップとメンタリティ
2	コンセプトと要件	アイデアから MVP まで
3	バックエンドのアーキテクチャ	APIとデータベース
4	フロントエンドの構造	UIとコンポーネント
5	迅速なエンジニアリング	MCP プロンプトとエージェント
6	テストと品質」	ユニット、統合、E2E
7	ドキュメント	README、API ドキュメント、ADR
8	デプロイとDevOps	ドッカー、CI/CD
9	進化	スケーラビリティとメンテナンス
10	コーディングエージェント	自律型開発エージェント
11	コードレビュー	AI自動レビュー
12	副操縦士の編集	複数ファイルの編集
13	GitHub スパーク	自然言語アプリ
14	現在位置 → 空間と記憶	整理されたコンテキストと記憶
15	AIモデル	モデル選びのガイド
16	カスタマイズ	カスタムの指示と知識
17	企業	組織向けの副操縦士
18	拡張機能	ツールを使用して Copilot を拡張する
19	安全性	AIのセキュリティとコンプライアンス

コパイロットスペース: 目的のある会話のためのコンテキストの整理

副操縦士スペース を作成できる機能です。 コンテキストの整理されたコレクション 副操縦士との会話用。スペースは基本的に、さまざまなタイプを含めることができるコンテナです。特定のタスク、プロジェクト、または作業領域に関連する情報。代わりにスペースを作成するときに、作業内容を毎回 Copilot に説明する必要があること一度使用すれば、そのコンテキストに関連するすべての会話で再利用できます。

スペースに含めることができるもの

Spaces の強みは、サポートされるコンテンツの種類の柔軟性にあります。コードだけに限定されるわけではありません。役立つあらゆる情報を含めることができます。副操縦士に必要なコンテキストを与えます。

サポートされているコンテンツ タイプ

タイプ説明使用例
リポジトリGitHub リポジトリ全体または特定のフォルダープロジェクトのメイン リポジトリを含める
コードファイル単一のファイルまたはコードの選択データモデル、メインAPI、構成ファイル
プルリクエストPR は差分とコメントでオープンまたはクローズされます最新の変化を理解するための最近の PR
問題GitHub でのディスカッションの問題未解決のバグ、機能リクエスト、アーキテクチャ上の決定
フリーテキストテキスト形式のメモ、指示、コンテキストチームの約束事、ビジネスルール、要件
画像スクリーンショット、図、ワイヤーフレームリファレンスデザイン、アーキテクチャ図
アップロードされたファイルドキュメント、PDF、設定ファイル技術仕様、要件文書

スマートローディング: インテリジェントなコンテキスト

Spaces の基本的な側面はメカニズムです。 スマートローディング。スペースにリポジトリを含める場合、Copilot コンテンツ全体がロードされるわけではありませんリポジトリの 会話の文脈では。これは不可能でしょうリポジトリが大きく、小さいリポジトリであっても非効率的です。

代わりに、スマートローディングはセマンティック検索エンジンと同様に機能します。質問するときは、副操縦士 動的に検索して取得する 一人で特定のリクエストに関連するファイルとコードセクション。このアプローチ両方の長所を提供します。ソースとしてリポジトリ全体にアクセスできます。ただし、関連する部分のみがモデルのコンテキストウィンドウを占めます。

スマートローディングの仕組み

インデックス作成: リポジトリをスペースに追加すると、セマンティック検索用にインデックスが作成されます
クエリ: 質問すると、Copilot はその意図を分析し、関連するトピックを特定します。
検索： 関連するファイルとセクションがインデックスから取得されます。
ランキング： 結果は関連性によって並べ替えられます
コンテキストアセンブリ: 最も関連性の高いフラグメントのみがモデルプロンプトに含まれます
答え： モデルは正確で関連性のあるコンテキストを含む応答を生成します

スペースの作成と管理

スペースの作成は、GitHub Web インターフェイス経由または直接行われます。 IDEから。プロセスはシンプルで直感的です。

プロジェクト用のスペースを作成する

例 - 電子商取引プロジェクトのスペース構成

SPACE: "E-commerce Backend"

REPOSITORY INCLUSI:
- org/ecommerce-api (repository principale)
- org/shared-libs (librerie condivise)
- org/ecommerce-docs (documentazione)

FILE SPECIFICI:
- ecommerce-api/src/models/*.ts (tutti i modelli dati)
- ecommerce-api/prisma/schema.prisma (schema database)
- ecommerce-api/.copilot-instructions.md (convenzioni del progetto)
- ecommerce-api/docs/architecture.md (decisioni architetturali)

ISSUE INCLUSE:
- #234: "Migrare a Event-Driven Architecture" (in discussione)
- #267: "Performance degradation on product search" (bug critico)

TESTO LIBERO:
"Questo progetto usa NestJS con Prisma ORM. Il database e' PostgreSQL.
L'autenticazione e' basata su JWT con refresh token.
Le API seguono il pattern CQRS con event sourcing per gli ordini.
Usiamo il pattern Repository per l'accesso ai dati.
I test seguono la piramide: 70% unit, 20% integration, 10% E2E.
Il deploy avviene tramite GitHub Actions su AWS ECS."

スペースの使用例

スペースは、コンテキストが複雑で分散しているシナリオで特に役立ちます。複数のリポジトリにわたる場合、またはチーム内のさまざまなメンバーがさまざまな側面に取り組む場合同じプロジェクトの。

一般的な使用シナリオ

シナリオ推奨スペース含める内容
マルチリポジトリプロジェクトプロジェクトごとに 1 つのスペースすべてのリポジトリ、共有スキーマ、アーキテクチャ ドキュメント
新しいメンバーのオンボーディング「オンボーディング [プロジェクト]」README、セットアップガイド、ADR、規約、FAQ
バグ調査「デバッグ[機能]」関連するファイル、問題、ログ、スタック トレース
機能開発「機能[名前]」仕様、ワイヤーフレーム、編集するファイル、既存のテスト
チーム間のコラボレーション「インテグレーション【チームA+B】」API コントラクト、共有スキーマ、契約文書
移行プロジェクト「移行[レガシー→新規]」レガシーコード、新しいターゲット、マッピング、移行計画
コードレビューの準備「[PR #xxx] をレビューしてください」PR、テスト、関連文書、チーム標準

スペースのベストプラクティス

やるべきこと

コンテキスト固有のスペースを作成します (すべてに対応する 1 つの汎用スペースではありません)。
プロジェクト規約 (.copilot-instructions.md ファイル) を常に含めます。
プロジェクトの進行に合わせてスペースを更新する
コードに存在しない情報についてはフリーテキストを追加してください
チームメンバーとスペースを共有する
コードと関連ドキュメントの両方を含める
異なるフェーズ (開発、デバッグ、レビュー) に異なるスペースを使用する

避けるべきもの

無関係なリポジトリをあまり含めないでください (コンテキスト内のノイズ)
すべての作業に対して 1 つのスペースを作成しないでください
大幅な変更を行った後は、忘れずにスペースを更新してください
大きなバイナリやアセットは含めないでください
フリーテキストを無視しないでください。多くの場合、フリーテキストは最も価値のあるコンテキストです。
権限を確認せずに機密コンテンツを含むスペースを共有しないでください
無関係な問題が大量にスペースに詰め込まれないようにします。

エージェントティックメモリ: 副操縦士用の永続メモリ

La エージェント記憶 最も革新的な機能の 1 つです Copilot で導入され、現在は 早期アクセス のためにプランのユーザープロ e プロ+。これは Copilot が可能にする永続メモリシステム 情報を思い出す以前のやり取りで学んだことの必要性を排除します。新しいチャットセッションごとに同じ説明を繰り返します。

メモリの仕組み

エージェントティックメモリは次のプロセスを通じて機能します。 自動控除。 Copilot との会話中に、システムは、次のような情報を特定します。将来役に立つ、「思い出」として残しておきます。これらの回想録は正確なコピーではありません会話ですが、 構造化された要約 重要な情報のやりとりから導き出されたもの。

記憶のライフサイクル

控除： 会話中に、Copilot は役立つ可能性のある情報を特定します
作成: 情報は合成され、構造化されたメモリとして保存されます
協会： メモリは、メモリが作成された特定のリポジトリに関連付けられます。
使用法： 同じリポジトリ内での後続の会話では、メモリがコンテキストとして使用されます。
検証: メモリが正常に使用されるたびに、メモリの寿命は延びます
有効期限: 未使用のメモリは 28 日後に自動的に期限切れになります

思い出の種類

システムはすべてを無差別に保存するわけではありません。思い出は分類される関連性によってフィルタリングし、価値の高い情報に焦点を当てます。再利用のこと。

回想録のカテゴリー

カテゴリEsempi価値
プロジェクトの構造フォルダー構成、アーキテクチャ、メインモジュールコードがどのように構成されているかを再度説明する必要がなくなる
コーディング規約命名スタイル、使用されるパターン、lint ルールチームの標準に準拠したコードを生成する
繰り返されるパターン新しいエンドポイントの作成方法、テストの作成方法、エラーの処理方法指示を必要とせずに承認されたパターンを再生します
技術的な決定特定のライブラリが使用されるため、アーキテクチャ上のトレードオフチームの選択に沿ったソリューションを提案します
ドメイン情報ビジネスルール、特定の用語、規制上の制約繰り返し説明しなくてもドメインを理解できる
個人的な好みコメントのスタイル、詳細レベル、応答形式好みに基づいて応答をパーソナライズする

永続性と有効期限

思い出には明確に定義されたライフサイクルがあり、実用性のバランスが取れるように設計されています。そして時間の経過に伴う関連性。

永続化ルール

ルール	詳細
初期期間	作成から28日
リニューアル	使用するたびに28日間のタイマーがリセットされます
有効期限	28 日間非アクティブな状態が続くと自動削除
ほうき	リポジトリ固有の (グローバルではない) メモリ
圧縮	トークン制限の 95% で、最も関連性の低いメモリが圧縮されます。
プライバシー	メモリはユーザーまたはリポジトリ間で共有されません
キャンセル	ユーザーは手動でメモリを削除できます
可視性」	ユーザーはすべてのアクティブなメモリを表示できます

スコープリポジトリ固有

エージェントティックメモリの基本的な側面は、記憶は リポジトリ固有の。作業中に学んだ情報は、リポジトリ B で作業する場合、リポジトリ A は使用されません。この設計はコンテキストが常に適切であることを保証し、コンテキスト間の汚染を防ぎます。さまざまなプロジェクト。

この設計の選択には重要な意味があります: プロジェクト A の規則同じアカウントを使用している場合でも、プロジェクト B の提案には影響しません。副操縦士。各リポジトリには独立した「頭脳」があり、それ自体が成長して充実します。そのリポジトリに固有のインタラクションのみ。

リポジトリのスコープの影響

モノレポ: モノリポジトリでは、すべてのメモリがモジュール間で共有されます (モジュール間の異なる規則に注意してください)
フォーク： フォークは別のリポジトリであるため、メモリは転送されません
名前の変更: リポジトリの名前を変更するとメモリが保持されます (内部 ID は変わりません)。
マルチリポジトリ: 同じプロジェクトの一部であっても、リポジトリごとに個別のメモリを構築する必要があります。
転送: リポジトリを別の組織に移管すると思い出が保存されます

自己圧縮

メモリ容量が限界に達したとき 最大トークン制限の 95% 割り当てられると、システムはプロセスをアクティブ化します 自己圧縮。思い出これらは、使用頻度、最新性、関連性に基づいて評価されます。思い出はそれほどでもない新しい情報のためのスペースを確保するために、使用されているものは圧縮または削除されます。

このメカニズムにより、各リポジトリの Copilot の「頭脳」が維持されることが保証されます。情報の破片を蓄積することなく、最も有益な情報に焦点を当てます。応答の品質が低下する可能性があります。それは自動プロセスではありません手動でメモリを管理することは可能ですが、ユーザーの介入が必要です必要に応じて。

エージェントティックメモリーの実際的な利点

エージェント記憶の前後

シナリオメモリなしメモリ付き
新しいチャットセッションプロジェクトの構造と規約を再説明する必要があるCopilot はプロジェクトがどのように構成されているかをすでに知っています
新しいエンドポイントの作成パターン、ミドルウェア、検証を指定する必要がありますCopilot は既存のエンドポイントのパターンを再現します
バグ修正関連するシステムがどのように機能するかを説明する必要がありますCopilot はアーキテクチャを理解しており、どこを見るべきかを提案します
コードレビューチームのルールを説明しなければならないCopilot はチームの規則を自動的に適用します
リファクタリングターゲット アーキテクチャを定義する必要がありますCopilot はユーザーのアーキテクチャ上の好みを把握しています
テストフレームワーク、スタイル、対象範囲を指定する必要がありますCopilot は既存のテストと一致するテストを生成します
ドキュメント形式、スタイル、規則を指定する必要がありますCopilot はプロジェクトの残りの部分に合わせたドキュメントを生成します

手動メモリ管理

システムは自動化されるように設計されていますが、ユーザーは完全に保存された記憶を制御します。あなたはできる：

ビュー： 各リポジトリのメモリの完全なリストにアクセスします
修正する： 不正確な記憶を修正するか、詳細を追加します
なくす： 古くなった、または間違った記憶を削除する
強制的に作成: Copilot に何かを記憶するように明示的に要求できます

例 - 明示的なメモリ命令

// Nella chat di Copilot, puoi dire:

"Ricorda che in questo progetto usiamo sempre
il pattern Result<T, E> per la gestione degli errori
invece di lanciare eccezioni. Ogni servizio deve
restituire Result<SuccessType, ErrorType>."

"Ricorda che le migrazioni del database vanno sempre
create con il comando: npx prisma migrate dev --name <nome-descrittivo>"

"Ricorda che il nostro naming convention per i branch e':
feature/JIRA-XXX-breve-descrizione
fix/JIRA-XXX-breve-descrizione
chore/JIRA-XXX-breve-descrizione"

"Ricorda che i test di integrazione devono usare
il database di test (TEST_DATABASE_URL) e non il
database di sviluppo."

リポジトリのインデックス作成: 即時セマンティック検索

Il リポジトリのインデックス作成 それは理解を促進するエンジンです Copilot による深いコード。リポジトリにインデックスが作成されると、 Copilot は、コードのセマンティック表現を作成して、ファイルの構造だけでなく、 論理的な関係 コンポーネント間では、 依存症 モジュールと データフロー システムを通じて。

自動インデックス作成

インデックス作成が行われる 自動的に 初めてのユーザーリポジトリで Copilot Chat 会話を開始します。何も必要ありません構成または手動アクション。インデックス作成が完了すると、すべてのそのリポジトリにアクセスする Copilot ユーザーは、共有インデックスの恩恵を受けます。

インデックス作成の詳細

待ってます	詳細
トリガー	リポジトリ内の最初の Copilot 会話で自動
スピード'	ほとんどのリポジトリで 60 秒未満
アップデート	プッシュごとに増分 (変更されたファイルのみ)
共有	インデックスはリポジトリのすべての Copilot ユーザー間で共有されます。
プライバシー	インデックスは AI モデルのトレーニングには使用されません
サイズ	最大数百万行のコードのリポジトリをサポート
言語	GitHub でサポートされているすべての言語
支店	インデックス作成はデフォルトのブランチ (メイン/マスター) をカバーします

インデックスとは

インデックス作成は、単純なテキスト検索インデックスをはるかに超えています。システム理解を生み出す セマンティクス 以下を含むコード:

インデックス作成レベル

レベル何を分析するか利点
ファイル構造フォルダー構成、命名規則、プロジェクトパターンCopilot は、各タイプの資産をどこで探すべきかを理解します
定義クラス、インターフェイス、関数、型、定数メソッドのタイプとシグネチャに関する正確な提案
関係インポート/エクスポート、継承、合成、依存関係変更が他のファイルに与える影響を理解する
パターン繰り返し発生するアーキテクチャ パターン、コーディング規約既存のパターンと一致するコードを生成する
論理データフロー、エラー処理、変換既存のロジックと統合する実装を提案します
ドキュメントコメント、JSDoc、README、マークダウンドキュメントを使用してコードの意図を理解する
テストテストケース、アサーション、モック、フィクスチャプロジェクトのテスト戦略に沿ったテストを生成する
構成構成ファイル、環境、ビルド設定プロジェクトの環境と依存関係を理解する

インデックス作成速度

最も重要なイノベーションの 1 つは、 時間の短縮 60 秒未満のインデックス作成。以前のバージョンでは、インデックス作成リポジトリが大きい場合は、数分から数時間かかる場合もあります。今日は、ありがとう埋め込みアルゴリズムとインデックスインフラストラクチャの最適化、セマンティック検索はほぼ即座に利用できます。

最初のインデックス作成の後、更新は次のように行われます。増分: 新しいコミットをプッシュすると、変更されたファイルのみが再インデックスされ、インデックスは完全に再作成する必要がなく、常に更新されます。

回答の品質への影響

リポジトリのインデックス作成は、リポジトリの品質に直接的かつ測定可能な影響を与えます。副操縦士が答える。インデックスを作成しない場合、Copilot はファイルのみを参照できます。現在エディタで開いています。インデックスを作成すると、すべてのデータにアクセスできるようになります。コードベース。

影響の例

リクエスト	インデックス作成なし	インデックス付き
「プロジェクトは認証をどのように処理しますか?」	ベストプラクティスに基づく一般的な対応	JWT ミドルウェア、認証サービス、ガードを説明する具体的な回答
「新しい支払いエンドポイントを作成する」	コンテキストのない汎用エンドポイント	一貫したミドルウェア、検証、エラーを備えたプロジェクトパターンに従うエンドポイント
「なぜテスト X は失敗するのでしょうか?」	テストファイルに限定した解析	テスト対象のサービス、依存関係、必要なモックを含む分析
「ユーザーモデルにフィールドを追加するにはどのファイルを編集する必要がありますか?」	テンプレートファイルのみ	モデル、移行、DTO、検証、シリアライザー、テスト、ドキュメント

エンタープライズ管理

組織向けに、リポジトリインデックス作成により、次のような詳細な制御が提供されます。どのコンテンツがインデックス付けされ、どのコンテンツが除外されるかを管理します。これは特に機密コードや専有情報を含むリポジトリにとって重要です。

例 - コンテンツ除外の .copilotignore

# File e cartelle da escludere dall'indicizzazione Copilot
# Simile a .gitignore ma specifico per Copilot

# Secrets e credenziali
.env
.env.*
**/secrets/
**/credentials/
**/*.pem
**/*.key

# Dati sensibili
**/fixtures/customers.json
**/seed/production-data.sql

# Codice proprietario
src/core/proprietary-algorithm/
src/core/patent-pending/

# File generati (rumore nell'indicizzazione)
dist/
build/
node_modules/
coverage/
*.min.js
*.bundle.js

# Vendor code
vendor/
third-party/

# File di grandi dimensioni (non utili per il contesto)
**/*.csv
**/*.sql.gz
**/*.dump

スペース、メモリ、インデックス間の相乗効果

これら 3 つのツールの真の力は、連携して機能するときに現れます。それぞれコンテキスト問題のさまざまな側面をカバーしており、これらを組み合わせて Copilot が提供されます。プロジェクトを完全かつ永続的に理解すること。

3 つのシステムがどのように連携するか

楽器コンテキストの種類持続性ほうき
リポジトリのインデックス作成コードの構造と関係永続的 (増分更新)リポジトリ全体
副操縦士スペースユーザーが厳選したマルチソースコンテキスト永続的 (ユーザー管理)マルチリポジトリ
エージェント記憶インタラクションから推測される知識28 日間 (更新可能)特定のリポジトリ

基本的に、Copilot に質問するときは次のようになります。

リポジトリのインデックス作成 関連するファイルとコード構造を回復します
スペース 追加のコンテキスト (問題、PR、ドキュメント、メモ) を追加します
エージェント記憶 以前のセッションで学んだ規則と設定を適用します
これらすべてのコンテキストが結合されてモデルに送信され、応答が生成されます。

実践例

これらのツールが日常の作業シナリオにどのように適用されるかを見てみましょう。

例 1: マルチリポジトリプロジェクト用のスペースのセットアップ

シナリオ - 電子商取引マイクロサービス

PROGETTO: E-commerce platform con 5 microservizi

REPOSITORY:
1. ecommerce-gateway (API Gateway - Node.js)
2. ecommerce-products (Catalogo prodotti - Python/FastAPI)
3. ecommerce-orders (Gestione ordini - Java/Spring Boot)
4. ecommerce-payments (Pagamenti - Go)
5. ecommerce-notifications (Notifiche - Node.js)

SPACE CONSIGLIATO: "E-commerce Platform"

CONTENUTI:
- Tutti i 5 repository
- File proto/ con le definizioni gRPC condivise
- File di OpenAPI di ogni servizio
- Documento di architettura (C4 model)
- ADR (Architecture Decision Records)
- Note sul team: "Il team payments e' esterno,
  comunicazione via Slack #payments-integration"

RISULTATO:
Quando chiedi "Come funziona il flusso di checkout?",
Copilot può' tracciare il flusso attraverso tutti i servizi:
Gateway -> Products (verifica disponibilità')
        -> Orders (crea ordine)
        -> Payments (processa pagamento)
        -> Notifications (invia conferma)

例 2: メモリを規約に使用する

シナリオ - コーディング規約の維持

SESSIONE 1 (Giorno 1):
Developer: "Crea un nuovo servizio per la gestione delle fatture"
Copilot genera il servizio seguendo pattern generici.
Developer: "No, nel nostro progetto i servizi seguono sempre
questo pattern: InvoiceService extends BaseService<Invoice>
con i metodi findById, findAll, create, update, delete.
Usiamo anche il decorator @Injectable() e il pattern
Result<T, E> per gli errori."
Copilot genera la versione corretta.
>> MEMORIA CREATA: "I servizi seguono il pattern
BaseService<T> con decorator @Injectable() e Result<T,E>"

SESSIONE 2 (Giorno 5):
Developer: "Crea un servizio per gestire i clienti"
Copilot genera automaticamente:
- CustomerService extends BaseService<Customer>
- @Injectable() decorator
- Tutti i metodi CRUD con Result<T, E>
- Error handling coerente con InvoiceService
>> NESSUNA ISTRUZIONE AGGIUNTIVA NECESSARIA

例 3: コード探索のためのリポジトリのインデックス作成

シナリオ - 既存プロジェクトのオンボーディング

CONTESTO: Nuovo sviluppatore sul progetto (50K righe di codice)

DOMANDE E RISPOSTE (con Repository Indexing):

D: "Come e' strutturato il progetto?"
R: Il progetto segue una Clean Architecture con 4 layer:
   - src/domain/ (entità' e business rules)
   - src/application/ (use cases)
   - src/infrastructure/ (database, API esterne)
   - src/presentation/ (controller, DTO, middleware)
   [cita file e cartelle specifiche]

D: "Come funziona l'autenticazione?"
R: L'autenticazione usa JWT con refresh token:
   - src/infrastructure/auth/jwt.strategy.ts (validazione)
   - src/infrastructure/auth/auth.guard.ts (protezione route)
   - src/application/auth/auth.service.ts (logica di login)
   [mostra il flusso con riferimenti al codice reale]

D: "Dove devo mettere un nuovo endpoint per i report?"
R: Basandomi sulla struttura del progetto:
   - Controller: src/presentation/controllers/report.controller.ts
   - Service: src/application/services/report.service.ts
   - Repository: src/infrastructure/repositories/report.repository.ts
   - DTO: src/presentation/dto/report.dto.ts
   - Test: test/unit/report.service.spec.ts
   [segue esattamente il pattern degli altri endpoint]

高度な構成

これらのツールを最大限に活用するには、正しく構成することが重要ですプロジェクトとチームのニーズに基づいて。

.copilot-instructions.md ファイル

ファイル .copilot-instructions.md リポジトリのルートにありますすべての副操縦士の会話のコンテキストに自動的に組み込まれます。それが最良の方法です特定のリポジトリに対して永続的な指示を Copilot に提供するように指示されています。

.copilot-instructions.md - 完全な例

# Istruzioni per Copilot

## Stack Tecnologico
- Backend: NestJS 10 con TypeScript 5.3
- Database: PostgreSQL 16 con Prisma 5
- Cache: Redis 7
- Queue: BullMQ
- Testing: Jest + Supertest
- Linting: ESLint + Prettier

## Convenzioni di Coding

### Naming
- File: kebab-case (user.service.ts)
- Classi: PascalCase (UserService)
- Metodi: camelCase (findById)
- Costanti: UPPER_SNAKE_CASE (MAX_RETRY_COUNT)
- Interfacce: PascalCase con prefisso I (IUserRepository) -- NO, senza prefisso

### Pattern
- Servizi: estendono BaseService<T>
- Repository: implementano IRepository<T>
- Controller: usano @Controller() decorator con path plurale (/users, /orders)
- DTO: usano class-validator per validazione
- Errori: Result<T, AppError> pattern (mai throw eccezioni)

### Testing
- Unit test: file.spec.ts nella stessa cartella del sorgente
- Integration test: test/integration/ con database di test
- E2E test: test/e2e/ con supertest
- Coverage target: 80% per servizi, 60% per controller

### Git
- Branch: feature/PROJ-XXX-descrizione, fix/PROJ-XXX-descrizione
- Commit: conventional commits (feat:, fix:, chore:, docs:)
- PR: template in .github/PULL_REQUEST_TEMPLATE.md

## Regole di Business
- I prezzi sono sempre in centesimi (integer, mai float)
- Le date sono sempre in UTC
- Gli ID sono UUID v4
- Soft delete per tutte le entità' (campo deletedAt)
- Audit trail per ogni operazione CRUD (campo createdBy, updatedBy)

インデックス作成の最適化

インデックス作成の品質と検索パフォーマンスを向上させるためセマンティクスについては、次のガイドラインに従ってください。

品質を向上させる

明確で一貫したフォルダー構造を維持する
JSDoc/TSDoc を使用して関数とクラスを文書化する
複雑なロジックに対して意味のあるコメントを書く
各モジュールの README を最新の状態に保つ
ファイル、クラス、関数にはわかりやすい名前を使用する
README ファイル内のモジュール間の関係を文書化する

騒音を減らす

.copilotignore で生成されたファイルを除外する
不要なベンダー依存関係を除外する
大きなデータファイル (CSV、ダンプ) を除外する
使用されなくなったレガシーコードを除外する
ロックファイルを除外する (package-lock.json は便利ですが、yarn.lock はそれほど便利ではありません)
バイナリアセット (画像、フォント、ビデオ) を除外します。

代替アプローチとの比較

スペース、メモリ、インデックス作成を文脈化するには、それらをアプローチと比較することが役立ちます AI にコンテキストを提供するための代替手段。

コンテキストへのアプローチの比較

アプローチプロに対していつ使用するか
エディタで開いたファイルシンプル、即時開いているファイルに限定されたコンテキストいくつかのファイルに対するローカルの変更
#ファイルのチャットでの言及正確な制御手動、ファイルの知識が必要特定のファイルに関する質問
リポジトリのインデックス作成自動、完全リポジトリコードのみ常に (デフォルトでオン)
副操縦士スペースマルチリポジトリ、マルチフォーマット初期設定が必要です複雑な複数リポジトリのプロジェクト
エージェント記憶自動、永続的リポジトリの場合は 28 日間に限定繰り返される慣例、パターン
.copilot-instructions.md永続的、チームと共有テキストのみ、動的ではないプロジェクトのルールと約束事
詳細な手動プロンプト最大限のコントロール持続性がなく、繰り返しが多い特定の複雑なタスク

制限事項と考慮事項

明らかな利点にもかかわらず、現在の制限を知ることが重要ですこれらのツールを現実的な期待を持って使用できるようにする必要があります。

電流制限

楽器制限インパクト緩和
スペースコンテンツの自動更新はサポートされていませんコンテキストが古くなってしまうリスクスペースの定期レビュー
スペーススペースあたりのリポジトリ数の制限非常に分散したプロジェクトは 1 つのスペースに収まらない場合がありますテーマ別の小さなスペースを作成する
メモリ未使用のメモリの有効期限は 28 日です再利用しないと知識が失われる永続的な情報には .copilot-instructions.md を使用してください
メモリ範囲は単一リポジトリに限定されます同じプロジェクトのリポジトリ間で知識を転送しません。リポジトリ間のコンテキストにスペースを使用する
メモリPro および Pro+ プランでのみ利用可能Free プランと Basic Business プランではアクセスできません代替として指示ファイルを使用する
インデックス作成インデックス付きのデフォルトブランチのみブランチ機能はインデックス作成の恩恵を受けられませんメインブランチへの頻繁なマージ
インデックス作成.gitignore から除外されたファイルにはインデックスが作成されませんコンテキスト内にないローカル構成リポジトリにサンプル ファイルを含める
みんなコードとドキュメントの品質に依存します文書化が不十分なリポジトリではメリットが少ないドキュメントと解説に投資する

プライバシーとデータセキュリティ

特にエンタープライズチームにとって考慮すべき重要な側面は、次の点です。これらのツールで使用されるデータのプライバシーとセキュリティ。

プライバシーの保証

トレーニングなし: スペース、メモリ、インデックスデータは AI モデルのトレーニングには使用されません
絶縁： メモリはユーザーごと、リポジトリごとに分離されます
暗号化: データは転送中も保存中も暗号化されます
ユーザーコントロール: ユーザーはいつでもすべてのメモリとデータを削除できます
コンテンツの除外: 組織はファイルとリポジトリをインデックス作成から除外できます
コンプライアンス： データは GitHub の利用規約に従って処理されます
データの所在地: エンタープライズプランの場合、データを特定のリージョンにローカライズできます

結論

コパイロットスペース、エージェントメモリ、リポジトリインデックス作成は質的な飛躍を示します AI ツールの開発にコンテキストを提供する方法についてです。繰り返す代わりに各セッションで同じ情報を得ることで、 生態系永続的なコンテキストの それは時間の経過とともに成長し、豊かになります。

これら 3 つのツールを組み合わせることで、コンテキストのあらゆる側面がカバーされます。 コード (リポジトリのインデックス作成)、ファイル 外部情報 (スペース) と 暗黙知 （メモリ）。一緒に変身します一般的なアシスタントからパートナーへの副操縦士 あなたのプロジェクトを知っています、あなたの慣例や好み。

実際的なアドバイスは次のとおりです。リポジトリのインデックス作成 (自動) から始めて、ファイル .copilot-instructions.md プロジェクトの規則に従って、最も複雑なコンテキスト用のスペース。記憶は時間の経過とともに自然に蓄積されます日々のやり取りを通じて。

シリーズの進行状況

#アイテムStato
1基礎と考え方完了
2コンセプトと要件完了
3バックエンドのアーキテクチャ完了
4フロントエンドの構造完了
5迅速なエンジニアリング完了
6テストと品質」完了
7ドキュメント完了
8デプロイとDevOps完了
9進化と維持完了
10コーディングエージェント完了
11コードレビュー完了
12副操縦士の編集完了
13GitHub スパーク完了
14空間と記憶あなたはここにいる
15Copilot の AI モデルProssimo
16カスタマイズProssimo
17企業Prossimo
18拡張機能Prossimo
19セキュリティとコンプライアンスProssimo

タイプ	説明	使用例
リポジトリ	GitHub リポジトリ全体または特定のフォルダー	プロジェクトのメインリポジトリを含める
コードファイル	単一のファイルまたはコードの選択	データモデル、メインAPI、構成ファイル
プルリクエスト	PR は差分とコメントでオープンまたはクローズされます	最新の変化を理解するための最近の PR
問題	GitHub でのディスカッションの問題	未解決のバグ、機能リクエスト、アーキテクチャ上の決定
フリーテキスト	テキスト形式のメモ、指示、コンテキスト	チームの約束事、ビジネスルール、要件
画像	スクリーンショット、図、ワイヤーフレーム	リファレンスデザイン、アーキテクチャ図
アップロードされたファイル	ドキュメント、PDF、設定ファイル	技術仕様、要件文書

シナリオ	推奨スペース	含める内容
マルチリポジトリプロジェクト	プロジェクトごとに 1 つのスペース	すべてのリポジトリ、共有スキーマ、アーキテクチャドキュメント
新しいメンバーのオンボーディング	「オンボーディング [プロジェクト]」	README、セットアップガイド、ADR、規約、FAQ
バグ調査	「デバッグ[機能]」	関連するファイル、問題、ログ、スタックトレース
機能開発	「機能[名前]」	仕様、ワイヤーフレーム、編集するファイル、既存のテスト
チーム間のコラボレーション	「インテグレーション【チームA+B】」	API コントラクト、共有スキーマ、契約文書
移行プロジェクト	「移行[レガシー→新規]」	レガシーコード、新しいターゲット、マッピング、移行計画
コードレビューの準備	「[PR #xxx] をレビューしてください」	PR、テスト、関連文書、チーム標準

カテゴリ	Esempi	価値
プロジェクトの構造	フォルダー構成、アーキテクチャ、メインモジュール	コードがどのように構成されているかを再度説明する必要がなくなる
コーディング規約	命名スタイル、使用されるパターン、lint ルール	チームの標準に準拠したコードを生成する
繰り返されるパターン	新しいエンドポイントの作成方法、テストの作成方法、エラーの処理方法	指示を必要とせずに承認されたパターンを再生します
技術的な決定	特定のライブラリが使用されるため、アーキテクチャ上のトレードオフ	チームの選択に沿ったソリューションを提案します
ドメイン情報	ビジネスルール、特定の用語、規制上の制約	繰り返し説明しなくてもドメインを理解できる
個人的な好み	コメントのスタイル、詳細レベル、応答形式	好みに基づいて応答をパーソナライズする

シナリオ	メモリなし	メモリ付き
新しいチャットセッション	プロジェクトの構造と規約を再説明する必要がある	Copilot はプロジェクトがどのように構成されているかをすでに知っています
新しいエンドポイントの作成	パターン、ミドルウェア、検証を指定する必要があります	Copilot は既存のエンドポイントのパターンを再現します
バグ修正	関連するシステムがどのように機能するかを説明する必要があります	Copilot はアーキテクチャを理解しており、どこを見るべきかを提案します
コードレビュー	チームのルールを説明しなければならない	Copilot はチームの規則を自動的に適用します
リファクタリング	ターゲットアーキテクチャを定義する必要があります	Copilot はユーザーのアーキテクチャ上の好みを把握しています
テスト	フレームワーク、スタイル、対象範囲を指定する必要があります	Copilot は既存のテストと一致するテストを生成します
ドキュメント	形式、スタイル、規則を指定する必要があります	Copilot はプロジェクトの残りの部分に合わせたドキュメントを生成します

レベル	何を分析するか	利点
ファイル構造	フォルダー構成、命名規則、プロジェクトパターン	Copilot は、各タイプの資産をどこで探すべきかを理解します
定義	クラス、インターフェイス、関数、型、定数	メソッドのタイプとシグネチャに関する正確な提案
関係	インポート/エクスポート、継承、合成、依存関係	変更が他のファイルに与える影響を理解する
パターン	繰り返し発生するアーキテクチャパターン、コーディング規約	既存のパターンと一致するコードを生成する
論理	データフロー、エラー処理、変換	既存のロジックと統合する実装を提案します
ドキュメント	コメント、JSDoc、README、マークダウン	ドキュメントを使用してコードの意図を理解する
テスト	テストケース、アサーション、モック、フィクスチャ	プロジェクトのテスト戦略に沿ったテストを生成する
構成	構成ファイル、環境、ビルド設定	プロジェクトの環境と依存関係を理解する

楽器	コンテキストの種類	持続性	ほうき
リポジトリのインデックス作成	コードの構造と関係	永続的 (増分更新)	リポジトリ全体
副操縦士スペース	ユーザーが厳選したマルチソースコンテキスト	永続的 (ユーザー管理)	マルチリポジトリ
エージェント記憶	インタラクションから推測される知識	28 日間 (更新可能)	特定のリポジトリ

アプローチ	プロ	に対して	いつ使用するか
エディタで開いたファイル	シンプル、即時	開いているファイルに限定されたコンテキスト	いくつかのファイルに対するローカルの変更
#ファイルのチャットでの言及	正確な制御	手動、ファイルの知識が必要	特定のファイルに関する質問
リポジトリのインデックス作成	自動、完全	リポジトリコードのみ	常に (デフォルトでオン)
副操縦士スペース	マルチリポジトリ、マルチフォーマット	初期設定が必要です	複雑な複数リポジトリのプロジェクト
エージェント記憶	自動、永続的	リポジトリの場合は 28 日間に限定	繰り返される慣例、パターン
.copilot-instructions.md	永続的、チームと共有	テキストのみ、動的ではない	プロジェクトのルールと約束事
詳細な手動プロンプト	最大限のコントロール	持続性がなく、繰り返しが多い	特定の複雑なタスク

楽器	制限	インパクト	緩和
スペース	コンテンツの自動更新はサポートされていません	コンテキストが古くなってしまうリスク	スペースの定期レビュー
スペース	スペースあたりのリポジトリ数の制限	非常に分散したプロジェクトは 1 つのスペースに収まらない場合があります	テーマ別の小さなスペースを作成する
メモリ	未使用のメモリの有効期限は 28 日です	再利用しないと知識が失われる	永続的な情報には .copilot-instructions.md を使用してください
メモリ	範囲は単一リポジトリに限定されます	同じプロジェクトのリポジトリ間で知識を転送しません。	リポジトリ間のコンテキストにスペースを使用する
メモリ	Pro および Pro+ プランでのみ利用可能	Free プランと Basic Business プランではアクセスできません	代替として指示ファイルを使用する
インデックス作成	インデックス付きのデフォルトブランチのみ	ブランチ機能はインデックス作成の恩恵を受けられません	メインブランチへの頻繁なマージ
インデックス作成	.gitignore から除外されたファイルにはインデックスが作成されません	コンテキスト内にないローカル構成	リポジトリにサンプルファイルを含める
みんな	コードとドキュメントの品質に依存します	文書化が不十分なリポジトリではメリットが少ない	ドキュメントと解説に投資する

#	アイテム	Stato
1	基礎と考え方	完了
2	コンセプトと要件	完了
3	バックエンドのアーキテクチャ	完了
4	フロントエンドの構造	完了
5	迅速なエンジニアリング	完了
6	テストと品質」	完了
7	ドキュメント	完了
8	デプロイとDevOps	完了
9	進化と維持	完了
10	コーディングエージェント	完了
11	コードレビュー	完了
12	副操縦士の編集	完了
13	GitHub スパーク	完了
14	空間と記憶	あなたはここにいる
15	Copilot の AI モデル	Prossimo
16	カスタマイズ	Prossimo
17	企業	Prossimo
18	拡張機能	Prossimo
19	セキュリティとコンプライアンス	Prossimo