AI: Introduce Perf Police and reusable code review and profiling skills

.github/PULL_REQUEST_TEMPLATE.MD

@@ -41,6 +41,9 @@ REFACTOR: (short-description)
 > For performance improvements
 PERF: (short-description)
 
+> For AI tooling, agents, skills, prompts, or AI-assisted development workflows
+AI: (short-description)
+
 > For release related changes, without any feature changes
 RELEASE: #<RELEASE_VERSION> (short-description) 
 

.github/agents/perf-police.agent.md

@@ -0,0 +1,25 @@
+---
+name: Perf Police
+description: "Evidence-led performance review for mssql-python. Use for native binding, parameter detection, fetch, streaming, allocation, caching, or profiler-related pull requests. Identify correctness risks, costly patterns, and unnecessary machinery without changing production code."
+tools: [read, search, execute]
+argument-hint: "PR number, branch, or local diff to review"
+---
+
+You are **Perf Police**, the performance reviewer for `microsoft/mssql-python`.
+Your job is to challenge a change's correctness, performance evidence, and
+maintainability, not to implement or merge it.
+
+Before reviewing, read and apply the
+[performance code-review skill](../skills/performance-code-review/SKILL.md).
+That file is the single source of the review procedure, patterns, evidence
+requirements, and reporting rules. Do not maintain a second checklist here.
+
+Use the supplied review checkout and the tools available in the current host.
+Keep production files and Git refs unchanged. Isolated scratch repros, builds,
+and test outputs are allowed when execution is permitted. Review requests do
+not authorize pushes, additional PR comments, thread resolution, or merges.
+
+Return concise findings with current file/line anchors and evidence. Separate
+confirmed defects, unverified concerns, performance observations, and structural
+suggestions. Missing runtime access is a stated limitation, not permission to
+invent measurements or declare the change safe.

.github/agents/release-manager.agent.md

@@ -87,7 +87,7 @@ Classify each PR — **show user both lists**:
 | Prefix | Include? |
 |--------|----------|
 | `FIX:`, `PERF:`, `FEAT:`, `DOC:` | ✅ Yes — customer-facing |
-| `CHORE:`, `REFACTOR:`, `STYLE:`, `RELEASE:` | ❌ No — unless title clearly describes a user-visible change |
+| `CHORE:`, `REFACTOR:`, `STYLE:`, `RELEASE:`, `AI:` | ❌ No — unless title clearly describes a user-visible change |
 
 #### 2c — Rust changes (see Rust Dependency section above)
 

.github/copilot-instructions.md

@@ -42,7 +42,8 @@ black --check --line-length=100 mssql_python/ tests/     # BLOCKING in CI
 python -m pytest -v                                       # 'stress' marker excluded by default
 ```
 
-- **`pr-format-check` (BLOCKING):** PR title must start with one of `FEAT: FIX: DOC: CHORE: STYLE: REFACTOR: RELEASE:`; the body must link a work item/issue and have a `### Summary` of at least 10 characters.
+- **`pr-format-check` (BLOCKING):** PR title must start with one of `FEAT: FIX: DOC: CHORE: STYLE: REFACTOR: PERF: RELEASE: AI:`; the body must link a work item/issue and have a `### Summary` of at least 10 characters.
+- Use `AI:` for AI tooling, agents, skills, prompts, and AI-assisted development workflows, not merely because AI helped write an ordinary fix or feature.
 - `flake8`, `pylint`, `mypy`, `clang-format`, and `cpplint` run but are **informational**, not blocking.
 - The authoritative cross-platform validation runs on **Azure DevOps** (broader OS / Python / arch coverage than the GitHub checks); consult the specific pipeline in `eng/pipelines/` for the exact matrix rather than assuming full coverage. A coverage bot posts a report comment on the PR.
 

.github/prompts/create-pr.prompt.md

@@ -218,6 +218,8 @@ The PR title **MUST** start with one of these prefixes (enforced by CI):
 | `CHORE:` | Maintenance tasks |
 | `STYLE:` | Code style/formatting |
 | `REFACTOR:` | Code refactoring |
+| `PERF:` | Performance improvements |
+| `AI:` | AI tooling, agents, skills, prompts, or AI-assisted development workflows |
 | `RELEASE:` | Release-related changes |
 
 > ⚠️ **CONFIRM #1 - PR Title:** Suggest 3-5 title options to the developer and ask them to pick or modify one.
@@ -414,7 +416,7 @@ Before submitting, verify:
 
 **Cause:** PR title doesn't match required format
 
-**Valid prefixes:** `FEAT:`, `FIX:`, `DOC:`, `CHORE:`, `STYLE:`, `REFACTOR:`, `RELEASE:`
+**Valid prefixes:** `FEAT:`, `FIX:`, `DOC:`, `CHORE:`, `STYLE:`, `REFACTOR:`, `PERF:`, `AI:`, `RELEASE:`
 
 **Fix:** Edit PR title in GitHub to start with a valid prefix
 
@@ -541,6 +543,8 @@ git push --force-with-lease
 | `CHORE:` | Maintenance |
 | `STYLE:` | Formatting |
 | `REFACTOR:` | Refactoring |
+| `PERF:` | Performance improvements |
+| `AI:` | AI tooling, agents, skills, prompts, or AI-assisted development workflows |
 | `RELEASE:` | Releases |
 
 ### Common Git Commands for PRs

.github/skills/code-review/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: code-review
+description: "General repository code review for microsoft/mssql-python, based solely on .github/copilot-instructions.md. Use when reviewing pull requests or diffs across the Python API, native bindings, packaging, tests, CI, or documentation. Apply the repository's existing architecture, correctness, compatibility, testing, and credential-handling expectations without replacing normal Copilot review."
+---
+
+# Repository code review
+
+The sole source of repository-specific rules for this skill is
+[copilot-instructions.md](../../copilot-instructions.md).
+Read that file before reviewing. The checklist below organizes its guidance
+for review; it does not introduce policies beyond the repository instructions or a performance-only review methodology.
+review methodology. If this summary drifts, use the source instructions.
+
+## Apply the instructions to the changed area
+
+1. **Architecture:** Identify the affected layer before judging the change:
+   Python API, extension loader, C++/ODBC bindings, or Rust-backed bulk copy.
+   Bulk copy uses `mssql_py_core` and TDS rather than the ODBC path.
+2. **Python API:** Preserve DB API 2.0 semantics, specific exception handling,
+   and connection/cursor context-manager behavior. For public API changes,
+   check that `__all__` and the `mssql_python.pyi` stubs stay consistent.
+3. **Native safety:** Inspect Python-reference shutdown ordering, initialization
+   failures, and error translation. A failed initialization must not expose a
+   half-built object. For hot paths, follow the source's raw-CPython guidance
+   with correct refcounts and error checks.
+4. **Platforms and packaging:** Check all affected shipped architectures, not
+   just the build host. In particular, universal2 dylib/rpath changes must cover
+   arm64 and x86_64. Review wheel/platform tagging where it changes, and do not
+   hand-edit bundled ODBC binaries.
+5. **Tests:** Check that fixes have regression coverage. Assert promised
+   operation counts as well as returned values when the change claims fewer
+   calls. Global type-mapping changes need the typed-NULL cases identified in
+   the source instructions. Keep crash-prone and global-state cases in isolated
+   subprocesses.
+6. **Credentials and examples:** Reject committed real credentials. Connection
+   examples with `UID`/`PWD` use localhost and dummy values. Do not add `Driver=`;
+   the bundled driver is selected automatically. Treat
+   `TrustServerCertificate=yes` as local-development only.
+7. **Scope and contribution requirements:** Keep changes surgical and avoid
+   unrelated edits, build artifacts, or virtual environments. Apply the source
+   instructions' title-prefix, issue-reference, and summary requirements.
+8. **Evidence and context:** Understand the linked issue and existing review
+   threads. Reproduce before asserting a driver bug or fix. Follow the source's
+   no-duplicate-PR and no-unsolicited-comment rules; a review is not an instruction
+   to create or publish changes.
+
+## Validation guidance
+
+Use the setup, native-build, test, and PR guides identified in
+[Development workflow](../../copilot-instructions.md#development-workflow).
+Build the native extension before running Python tests. Most tests need a live
+SQL Server through `DB_CONNECTION_STRING`; the dependency checks do not.
+
+Consult the actual pipeline matrix for supported combinations rather than
+inferring cross-platform coverage from a local run. Preserve the distinction
+between blocking checks and informational tools documented in
+[Validation gate](../../copilot-instructions.md#validation-gate-run-before-you-finish--this-mirrors-ci).
+A formatting recommendation from an informational tool is not automatically
+a failing merge requirement.
+
+Apply only the relevant repository checks alongside normal Copilot review.
+Do not force every change into a native-code or performance investigation.