You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/copilot-instructions.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -129,6 +129,10 @@ When a new issue is created, follow these steps:
129
129
- Suggest release note entries for fixes by updating files under `release-notes/` or by using the `release-notes` prompt (instead of editing `CHANGELOG.md` directly).
130
130
- Tag reviewers based on `CODEOWNERS` file
131
131
132
+
## 🌿 Branch Naming
133
+
- All branches created by AI agents **must** use the `dev/automation/` prefix (e.g. `dev/automation/fix-connection-timeout`).
134
+
- Do **not** create branches directly under `main`, `dev/`, or any other top-level prefix.
135
+
132
136
## 🧠 Contextual Awareness
133
137
- All source code is in `src/Microsoft.Data.SqlClient/src/`. Do NOT add code to legacy `netfx/src/` or `netcore/src/` directories.
134
138
- Only `ref/` folders in `netcore/ref/` and `netfx/ref/` remain active for defining the public API surface.
-**`mds_package_validation`** — Validates signed SqlClient package; `dependsOn: build_dependent`; runs in parallel with Stage 4
38
38
39
+
Each build job copies PDB files into `$(JOB_OUTPUT)/symbols/` so they are included in the auto-published pipeline artifact alongside the NuGet packages in `$(JOB_OUTPUT)/packages/`.
40
+
39
41
Stage conditional rules:
40
42
- Wrap stages/jobs in `${{ if }}` compile-time conditionals based on build parameters
41
43
-`buildSqlClient` controls Stages 2, 3, validation, and Logging (when AKV is disabled)
-**`publish-nuget-package-job.yml`** — Reusable release job using OneBranch `templateContext.type: releaseJob` with `inputs` for artifact download; pushes via `NuGetCommand@2`
54
+
-**`publish-symbols-job.yml`** — Reusable symbols job: downloads a build artifact, locates PDBs under `symbols/`, and invokes `publish-symbols-step.yml`
52
55
53
56
When adding a new csproj-based package:
54
57
- Use `build-signed-csproj-package-job.yml` with appropriate `packageName`, `packageFullName`, `versionProperties`, and `downloadArtifacts`
55
58
- Add build and pack targets to `build.proj`
56
59
- Add version variables to `variables/common-variables.yml`
57
60
- Add artifact name variable to `variables/onebranch-variables.yml`
58
61
62
+
## Symbols Publishing Stage
63
+
64
+
- Defined in `stages/publish-symbols-stage.yml`; produces stage `publish_symbols`
65
+
- Entire stage excluded at compile time when `publishSymbols` is false
66
+
-`dependsOn` is conditional based on which `build*` parameters are set, mirroring the build stage dependency graph
67
+
- One job per package (`publish-symbols-job.yml`), each downloading its build artifact and publishing PDBs from `symbols/`
68
+
- Each package's PDBs are published separately with unique artifact names and version information
69
+
- Build jobs copy PDBs into `$(JOB_OUTPUT)/symbols/` so they are included in the auto-published artifact
70
+
- The `publish-symbols-step.yml` accepts a `symbolsFolder` parameter to point at the downloaded PDB location
71
+
- The publish step calls an extracted `publish-symbols.ps1` script with structured error handling and diagnostic logging
72
+
- Symbols publishing credentials come from the `Symbols Publishing` variable group
73
+
- In the official pipeline, symbol server destination follows `releaseToProduction`: Production when true, PPE when false
74
+
- Non-official pipeline always targets the PPE symbol server
75
+
59
76
## Release Stage
60
77
61
78
- Defined in `stages/release-stages.yml`; produces stage `release_production` (official) or `release_test` (non-official) via `stageNameSuffix` parameter
-`releaseToProduction` — push to NuGet Production feed (default `false`)
104
+
-`releaseToProduction` — controls both NuGet target feed and symbol server destination (default `false`):
105
+
-`true` → NuGet Production feed + Production symbol server
106
+
-`false` → NuGet Test feed + PPE symbol server
88
107
89
108
When `isPreview` is true, pipeline resolves `effective*Version` variables to preview versions; otherwise GA versions. All versions defined in `variables/common-variables.yml`.
90
109
@@ -98,8 +117,7 @@ When `isPreview` is true, pipeline resolves `effective*Version` variables to pre
98
117
- When adding a new package, add GA version, preview version, and assembly file version entries
99
118
100
119
Variable groups:
101
-
-`Release Variables` — release configuration (in `common-variables.yml`)
102
-
-`Symbols publishing` — symbol publishing credentials (in `common-variables.yml`)
120
+
-`Symbols Publishing` — symbol publishing credentials (in `onebranch-variables.yml`)
103
121
-`ESRP Federated Creds (AME)` — ESRP signing credentials (in `common-variables.yml`)
104
122
105
123
## Code Signing (ESRP)
@@ -115,15 +133,19 @@ Variable groups:
115
133
116
134
- TSA: enabled only in official pipeline; disabled in non-official to avoid spurious alerts
117
135
- ApiScan: enabled in both; currently `break: false` pending package registration
118
-
- Each build job sets `ob_sdl_apiscan_*` variables pointing to `$(Build.SourcesDirectory)/apiScan/<PackageName>/`
136
+
- Each build job sets `ob_sdl_apiscan_softwareFolder` to `$(JOB_OUTPUT)/assemblies` and `ob_sdl_apiscan_symbolsFolder`to `$(JOB_OUTPUT)/symbols`
119
137
- CodeQL, SBOM, Policheck (`break: true`): enabled in both pipelines
Review the pull request "${input:pr}" in `dotnet/SqlClient`.
9
+
Review the changes in "${input:target}" for `dotnet/SqlClient`.
10
+
11
+
The target may be either a **PR number** (e.g., `4106`) or a **branch name** (e.g., `dev/user/my-feature`). Determine which by checking whether the value is purely numeric.
10
12
11
13
Follow this structured review process:
12
14
13
15
## 1. Understand the Change
14
-
- Fetch the PR details: title, description, linked issue(s), and diff.
15
16
- Read the PR description to understand the intent and scope of the change.
17
+
- Check for linked issues referenced in the description (e.g., `Fixes #...`).
16
18
- Check which files are modified and categorize them:
17
19
-**Source code** (`src/Microsoft.Data.SqlClient/src/`) — the main review focus
Copy file name to clipboardExpand all lines: .github/prompts/generate-prompt.prompt.md
+63-1Lines changed: 63 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,6 +2,7 @@
2
2
name: generate-prompt
3
3
description: Generates high-quality VS Code Copilot prompt files (.prompt.md) based on user descriptions, leveraging available skills.
4
4
argument-hint: Describe the prompt you want to create (e.g., "A prompt to generate unit tests for C#")
5
+
tools: [read, edit, search, todo]
5
6
---
6
7
You are an expert AI prompt developer specialized in creating **Visual Studio Code Copilot Prompt Files (`.prompt.md`)**.
7
8
@@ -34,6 +35,7 @@ Before generating the prompt, review the available skills in the `.github/skills
34
35
*`name`: A concise, kebab-case name for the prompt.
35
36
*`description`: A clear, short description of what the prompt does.
36
37
*`argument-hint`: (Optional) A hint for what arguments the user can provide when using the prompt.
38
+
*`tools`: (Recommended) A list of tool identifiers the prompt is allowed to use. See the **Tool Scoping** section below.
37
39
***Body Structure**:
38
40
***Role**: Define the AI's persona (e.g., "You are an expert C# developer...").
39
41
***Context**: Include specific context instructions or references.
@@ -50,19 +52,78 @@ Before generating the prompt, review the available skills in the `.github/skills
50
52
* Use `${input:variableName}` for user inputs (e.g., `${input:methodName}`).
51
53
* Use built-in variables like `${selection}`, `${file}`, or `${workspaceFolder}` where appropriate context is needed.
52
54
53
-
6.**Best Practices**:
55
+
6.**Scope Tools**: Restrict the tools available to each prompt using the `tools` frontmatter field. See the **Tool Scoping** section below for detailed guidance.
56
+
57
+
7.**Best Practices**:
54
58
* Be specific and explicit.
55
59
* Encourage chain-of-thought reasoning if the task is complex.
56
60
* Reference workspace files using Markdown links `[path/to/file.cs](path/to/file.cs)` only if they are static and necessary for *all* invocations of this prompt.
57
61
* Prefer referencing skills over duplicating instructions that already exist in skills.
58
62
63
+
## Tool Scoping
64
+
65
+
Every generated prompt **should** include a `tools` list in its YAML frontmatter. Scoping tools keeps the model focused by limiting it to approved, known-effective tools for the task. Without tool scoping, the model may invoke irrelevant tools, waste context, or produce unpredictable results.
66
+
67
+
### Why scope tools?
68
+
-**Focus**: Fewer tools means the model spends less reasoning on tool selection and more on the task.
69
+
-**Reliability**: Restricting to tested tools avoids unexpected side effects (e.g., a read-only review prompt shouldn't have edit tools).
70
+
-**Safety**: Prevents prompts from accidentally running terminal commands or making file changes when they shouldn't.
71
+
72
+
### How to choose tools
73
+
Apply the **principle of least privilege** — include only the tools the prompt actually needs:
|**Needs terminal** (build, test, scripts) | All of the above + `execute/runInTerminal`, `execute/getTerminalOutput`|
80
+
|**Needs GitHub data** (triage, release notes) | All of the above + `github/search_issues` or other GitHub tools |
81
+
|**Needs web content** (docs lookup) |`web/fetch`|
82
+
83
+
### Available built-in tool identifiers
84
+
85
+
You can specify individual tools or tool sets (which include all tools in that group).
86
+
87
+
**Tool sets** (use these to include all tools in a category):
88
+
-`edit` — File creation and editing tools
89
+
-`read` — File and notebook reading tools
90
+
-`search` — Codebase, text, and file search tools
91
+
-`execute` — Terminal, task, and notebook execution tools
92
+
-`web` — Web content fetching tools
93
+
94
+
**Commonly used individual tools:**
95
+
96
+
| Tool identifier | Purpose |
97
+
|---|---|
98
+
|`edit/editFiles`| Apply edits to existing files |
99
+
|`edit/createFile`| Create a new file |
100
+
|`read/readFile`| Read file contents |
101
+
|`read/problems`| Get workspace problems/diagnostics |
102
+
|`search/codebase`| Semantic code search |
103
+
|`search/textSearch`| Text/regex search in files |
104
+
|`search/fileSearch`| Search for files by glob pattern |
105
+
|`search/listDirectory`| List directory contents |
106
+
|`search/usages`| Find references and implementations |
107
+
|`execute/runInTerminal`| Run a shell command |
108
+
|`execute/getTerminalOutput`| Get terminal output |
109
+
|`execute/testFailure`| Get test failure details |
110
+
|`web/fetch`| Fetch a web page |
111
+
112
+
**Extension / MCP tools** can also be included using their identifier (e.g., `github/search_issues`). Use `<server-name>/*` to include all tools from an MCP server.
You are an expert .NET Test Engineer specialized in optimizing test coverage and reducing technical debt.
7
9
@@ -10,19 +12,19 @@ Your task is to analyze the user's test suite using the `AnalyzeTestOverlap.ps1`
10
12
11
13
## Skills
12
14
This prompt leverages the following skills for specific sub-tasks:
13
-
-[generate-mstest-filter](../skills/generate-mstest-filter/SKILL.md) - For generating well-formed MSTest filter expressions
15
+
-[generate-mstest-filter](.github/skills/generate-mstest-filter/SKILL.md) - For generating well-formed MSTest filter expressions
14
16
15
17
## Tools
16
-
You have access to the analysis script at `[AnalyzeTestOverlap.ps1](./scripts/AnalyzeTestOverlap.ps1)`.
18
+
You have access to the analysis script at [AnalyzeTestOverlap.ps1](.github/prompts/scripts/AnalyzeTestOverlap.ps1).
17
19
18
20
## Workflow
19
21
1.**Parse or Generate Test Filter**:
20
22
* If `${input:filter}` is a valid MSTest filter expression (e.g., `FullyQualifiedName~MyTests`), use it directly.
21
-
* If `${input:filter}` is a loose description (e.g., "connection tests" or "SqlCommand class"), follow the instructions in the [generate-mstest-filter](../skills/generate-mstest-filter/SKILL.md) skill to generate a proper filter expression.
23
+
* If `${input:filter}` is a loose description (e.g., "connection tests" or "SqlCommand class"), follow the instructions in the [generate-mstest-filter](.github/skills/generate-mstest-filter/SKILL.md) skill to generate a proper filter expression.
22
24
* If `${input:filter}` is empty, ask the user for a test filter or description to target specific tests.
23
25
24
26
2.**Run Analysis**:
25
-
* Run the script using the filter: `.\scripts\AnalyzeTestOverlap.ps1 -Filter "<filter>"`.
27
+
* Run the script from the workspace root: `.\.github\prompts\scripts\AnalyzeTestOverlap.ps1 -Filter "<filter>"`.
26
28
**Note*: The script produces a console summary and a `test-coverage-analysis.json` file.
0 commit comments