에이전트 기술은 특정 작업을 수행하는 방법을 GitHub Copilot 지시하는 재사용 가능한 지침 집합입니다. 각 기술은 한 번 정의하여 시간을 절약하고 워크플로 전체에서 일관된 동작을 보장하는 markdown 파일입니다. 스킬은 하나의 거대한 프롬프트가 아닌 런북으로 생각하십시오. Agent 모드(미리 보기) 사용하는 경우 Copilot 자동으로 검색하고 요청하는 내용에 따라 관련 기술을 적용합니다.
비고
SQL Server Management Studio(SSMS)의 GitHub Copilot 에이전트 모드는 현재 미리 보기로 제공됩니다.
모든 응답에 대한 일반적인 기본 설정을 지정하는 사용자 지정 지침과 달리 기술은 모든 에이전트가 검색하고 사용할 수 있는 집중적인 작업별 지침을 제공합니다. 기술을 한 번 정의하면 세션과 팀 전체에서 일관되게 적용됩니다.
사전 요구 사항
- AI 지원 워크로드를 사용하는 SSMS 22.7 이상 버전.
- Copilot 액세스 있는 GitHub 계정입니다. 또는 SQL Server Management Studio 무료로 GitHub Copilot 사용할 수 있습니다.
에이전트 기술의 작동 방식
에이전트 모드를 사용하는 경우 Copilot 리포지토리 및 사용자 프로필에 대해 알려진 기술 위치를 검색합니다. 기술 설명이 요청의 의도와 일치하는 경우 Copilot 기술을 활성화하고 해당 지침을 추가 컨텍스트로 적용합니다. 기술이 활성 상태이면 해당 이름이 채팅에 표시되므로 해당 기술이 적용되고 있음을 알 수 있습니다.
Copilot 각 기술의 프런트매터에서 description 필드를 기반으로 활성화할 기술을 결정합니다. 명확하고 키워드가 풍부한 설명은 Copilot 기술이 관련된 시기를 식별하는 데 도움이 됩니다.
기술 위치
Copilot은 다음 위치에서 스킬을 찾습니다.
| Scope | Paths | 세부 정보 |
|---|---|---|
| 작업 영역 (팀과 공유) |
.github/skills/, .claude/skills/, .agents/skills/ |
리포지토리 루트에 저장됩니다. 모든 팀 구성원이 동일한 기술을 얻을 수 있도록 소스 제어에 최선을 다하고 있습니다. |
| 개인 (프로필에만 해당) |
~/.copilot/skills/, ~/.claude/skills/, ~/.agents/skills/ |
모든 프로젝트에 적용됩니다. 리포지토리에 커밋되지 않습니다. |
작업 영역 기술은 프로젝트별 규칙에 우선합니다. 개인 기술은 여러 프로젝트에서 사용자와 함께 이동하는 워크플로 및 기본 설정에 유용합니다.
기술 만들기
SSMS의 기술 패널에서 또는 파일 시스템에서 수동으로 기술을 만들 수 있습니다.
기술 패널에서 기술 만들기
- Copilot Chat 창에서 도구 아이콘을 선택합니다.
- 기술 패널을 선택합니다.
- 기술 패널에서 단추를 선택합니다 + .
- 범위( 리포지토리에 저장된 작업 영역 기술) 또는 개인 기술(사용자 프로필에 저장됨)을 선택합니다.
- 기술의 이름을 입력합니다. 이름은 디렉터리 이름이 되며 소문자, 숫자 및 하이픈만 사용해야 합니다.
- SSMS는
SKILL.md새 기술 디렉터리에 템플릿을 생성합니다. 템플릿을 편집하고 파일에 지침을 추가합니다.
수동으로 스킬 생성하기
- 적절한 위치에 기술 디렉터리를 만듭니다. 워크스페이스 스킬의 경우, 리포지토리의 루트에
.github/skills/를 만드세요. - 기술에 대한 하위 디렉터리를 만듭니다. 각 기술에는 자체 디렉터리가 있어야 합니다. 예:
.github/skills/tsql-style-guide/. -
SKILL.md기술 디렉터리 내에 파일을 만듭니다. - 필요에 따라 스크립트, 참조 문서 또는 예제 출력과 같은 지원 파일을 추가합니다.
기술 디렉터리 구조
your-repo/
└── .github/
└── skills/
└── index-verification/
│ ├── SKILL.md # Required: metadata and instructions
│ └── references/ # Optional: supplementary documentation
└── agent-job-failure-triage/
├── SKILL.md
└── examples/ # Optional: example scripts
SKILL.md 형식
각 SKILL.md 파일에는 YAML 프런트매터와 Markdown 지침이 포함되어야 합니다. 프런트매터는 Copilot 기술을 검색하고 활성화하는 데 사용하는 메타데이터를 제공합니다.
Frontmatter 속성
| Property | 필수 | Description |
|---|---|---|
name |
Yes | 소문자, 숫자 및 하이픈만 해당됩니다. 부모 디렉터리 이름과 일치해야 합니다. 최대 64자 |
description |
Yes | 기술이 수행하는 기능과 사용 시기에 대해 설명합니다. 최대 1,024자 기술이 관련되면 신호를 주는 특정 키워드를 포함합니다. |
license |
No | 라이선스 이름 또는 기술과 함께 번들로 제공되는 라이선스 파일에 대한 참조입니다. |
compatibility |
No | 의도한 제품 또는 필요한 시스템 기능과 같은 환경 요구 사항 |
metadata |
No | 다른 메타데이터에 대한 임의의 키-값 쌍입니다. |
allowed-tools |
No | 기술에서 사용할 수 있도록 미리 승인된 도구 이름의 공백으로 구분된 목록입니다. |
기술 패널에서 기술 관리
Copilot Chat 창에서 도구 아이콘을 선택하여 Skills 패널을 엽니다. 패널에는 현재 세션에 대해 Copilot이 찾아낸 모든 기능이 표시됩니다.
패널에서 다음을 수행할 수 있습니다.
-
편집:
...메뉴에서 스킬의SKILL.md파일을 편집기에서 직접 엽니다. - 파일 위치 열기: 디스크의 기술 디렉터리로 이동합니다.
- 검색: 이름 또는 키워드별로 기술을 필터링합니다.
또한 패널은 기술 구성 오류에 대한 진단을 표시하므로 문제를 신속하게 식별하고 해결할 수 있습니다.
효과적인 기술을 작성하기 위한 팁
-
간결하게 유지
SKILL.md: 300줄 미만을 목표로 합니다. 자세한 참조 자료를 관련 하위 디렉터리의 개별 파일로 이동합니다. -
키워드가 풍부한 설명 작성: Copilot
description사용하여 기술을 활성화할 시기를 결정합니다. 기술이 적용되는 특정 작업, 개체 및 시나리오를 포함합니다. - 프로시저에 번호 매기기 단계 사용: 단계별 지침은 모델이 산문보다 더 쉽게 따를 수 있습니다.
- 예상 출력의 예를 포함합니다. 모델이 "완료"의 모양을 알 수 있도록 샘플 코드, 테이블 형식 또는 주석 블록을 표시합니다.
- 명시적인 한계를 설정하세요: 스킬에 하지 말아야 할 일을 알려주세요. 예를 들어 "먼저 쓰기 볼륨을 보고하지 않고 1,000만 개 이상의 행이 있는 테이블에서 인덱스를 삭제하지 않는 것이 좋습니다."
-
참조용 지원 자료: 관련 콘텐츠와 스크립트를
references\,scripts\또는examples\내의 파일에 저장하고 스킬에서 특정 콘텐츠를 참조합니다.
예제 SQL 기술
다음 예제에서는 일반적인 SQL Server 작업에 대한 기술을 작성하는 방법을 보여 줍니다. 시작점으로 사용하고 팀의 규칙에 맞게 조정합니다.
인덱스 확인
중복을 방지하기 위해 새 인덱스를 권장하기 전에 기존 인덱스를 검토합니다.
---
name: index-verification
description: Use when an index recommendation has been generated and must be validated before implementation. Verifies workload benefit, redundancy, write overhead, storage impact, and existing index coverage.
---
# Index Verification
## Use this skill when
- A missing index recommendation exists
- An agent generated an index recommendation
- Query tuning suggests adding an index
- A user asks whether an index should be created
## Never assume
- Missing index DMVs are recommendations, not requirements.
- Do not recommend index creation until validation is complete.
## Verification Checklist
### 1. Check Existing Indexes
Determine whether:
- An equivalent index already exists
- A wider index already covers the workload
- Included columns already satisfy the query
- The recommendation duplicates another recommendation
### 2. Estimate Read Benefit
Evaluate:
- Query execution frequency
- Current execution cost
- Expected seek/selectivity improvement
- Number of affected queries
### 3. Evaluate Write Cost
Determine:
- Insert impact
- Update impact
- Delete impact
- Additional maintenance cost
### 4. Evaluate Storage Impact
Estimate:
- Index size on disk
- Memory pressure
- Replication impact
### 5. Make Recommendation
Return one of:
- Create index
- Modify existing index
- Consolidate with existing recommendation
- Reject recommendation
## Avoid
- Blindly trusting missing-index DMVs
- Creating overlapping indexes
- Recommending indexes for one-off queries
- Ignoring write-heavy workloads
## Output Format
Format output as a table: index name, columns, type, and recommendation (create / modify / consolidate / reject).
에이전트 작업 실패 심사
실패한 SQL 에이전트 작업의 기록을 분석하고 근본 문제를 해결하기 위한 권장 사항을 만듭니다.
---
name: agent-job-failure-triage
description: Use when an automated job, workflow, maintenance task, or agent execution fails. Determines root cause and appropriate remediation while avoiding unsafe recovery actions.
---
# Agent Job Failure Triage
## Objective
Identify root cause before attempting remediation.
## First Rule
Never retry repeatedly without understanding why the job failed.
## Investigation Order
### 1. Collect Failure Details
Gather:
- Job name
- Error message
- Start time
- End time
- Retry history
### 2. Classify Failure
Determine whether failure is:
- Resource-related
- Permission-related
- Configuration-related
- Data-related
- Dependency-related
- Other or unknown
### 3. Check Recent Changes
Investigate:
- Deployments
- Configuration changes
- Schema changes
- Security changes
- Infrastructure changes
### 4. Determine Blast Radius
Identify:
- Data modified by job
- Schema modified by job
- Affected users or departments
- Downstream jobs
- SLA impact
- Data correctness risk
## Safe Actions
- Collect logs
- Validate dependencies
- Escalate when root cause is unknown
## Unsafe Actions
- Retry job
- Disable job
- Force-completing jobs
- Disabling validation checks
- Modifying production data to "make it pass"
- Restarting the SQL Agent service