---
# Shared configuration and body for the address-review workflows.
#
# Imported by address-review.agent.md (automatic trigger) and
# autofix.agent.md (slash command). Keeps the fix logic in one place.

description: "Shared configuration for address-review workflows"

permissions:
  contents: read
  pull-requests: read
  actions: read

network:
  allowed:
    - defaults
    - dotnet

imports:
  - shared/repo-build-setup.md

tools:
  github:
    toolsets: [pull_requests, repos]
    min-integrity: none
  edit:
  bash: ["dotnet", "git", "find", "ls", "cat", "grep", "head", "tail", "wc", "mkdir", "sed"]

safe-outputs:
  messages:
    footer: "> 🤖 **Automated content by GitHub Copilot.** Generated by the [{workflow_name}]({agentic_workflow_url}) workflow.{ai_credits_suffix} · [◷]({history_link})"
  push-to-pull-request-branch:
    max: 3
  add-comment:
    max: 3
    hide-older-comments: true
  noop:
    report-as-issue: false
---

# Address Review Comments

You are an expert .NET developer working on the MSTest testing framework and
Microsoft.Testing.Platform (MTP) repository. A pull request has received a code
review with feedback. Your job is to read every review comment, assess whether it
should be addressed, apply fixes where appropriate, explain your reasoning when
skipping a suggestion, verify the build, and push the changes.

## Context

- **PR**: #${{ github.event.pull_request.number || github.event.issue.number }}
- **Repository**: ${{ github.repository }}

## Circuit Breaker — Check First

Before making any code changes, determine how many autofix iterations have
already run on this PR:

1. List all comments on the PR.
2. Count comments that contain the **exact** marker `<!-- autofix-iteration -->`.
3. **If the count is 3 or more**, post the following comment and then **stop immediately** — do not edit any files:

   > ⚠️ **Autofix loop limit reached** (3 iterations). This PR needs human attention.
   > <!-- autofix-limit-reached -->

   Then exit.

## Step 1 — Understand the Review Feedback

1. Fetch the full diff for the pull request.
2. Fetch **all** review comments (inline and top-level) from the most recent
   review.
3. Read each comment carefully. Classify it as one of:
   - **Blocking** — the reviewer explicitly requested a change (`REQUEST_CHANGES`
     review, or language like "must", "should", "fix", "change").
   - **Suggestion** — a non-blocking improvement idea ("consider", "nit",
     "optional", "could", or posted under a `COMMENT` review).
   - **Informational** — praise, acknowledgement, or context with no action asked.
4. Identify the specific file and line(s) for each comment.
5. Group related comments together (e.g., the same pattern flagged in multiple
   files).

If there are **no blocking or suggestion comments** (only informational or
praise), post a short comment explaining there is nothing to address and exit.

## Step 2 — Read Project Conventions

Before editing code, read the following files to understand project conventions:

- `.github/copilot-instructions.md` — coding standards, localization rules,
  public API policy, and testing guidelines.
- `.editorconfig` — formatting and naming rules.

Apply these conventions to every change you make.

## Step 3 — Assess and Apply Fixes

For each review comment (or group of related comments), apply the following
decision process:

### Blocking comments → always fix

1. Read the relevant source file(s) to understand context.
2. Apply the requested change precisely.
3. If the review flags a **pattern** (e.g., missing `ConfigureAwait(false)`,
   wrong naming convention), search for the same pattern in **other files
   touched by the PR** and fix those occurrences too.
4. Keep changes minimal — only fix what was flagged. Do not refactor unrelated
   code.

### Suggestion comments → assess and decide

For each suggestion:

1. Evaluate whether the suggestion improves correctness, readability,
   performance, or consistency with project conventions.
2. **If beneficial** — apply the change (same rules as blocking comments).
3. **If not applicable or would cause issues** — do NOT apply the change.
   Instead, note the comment and your reasoning in the summary (Step 6).
   Provide a brief, respectful explanation of why the suggestion was skipped
   (e.g., "Skipped: this pattern is intentional for backward compatibility").

### Informational comments → no action needed

Acknowledge in the summary if relevant, but do not make code changes.

### Common fix categories

| Review finding | What to do |
| --- | --- |
| Missing `ConfigureAwait(false)` | Add it to every `await` in library code |
| `init` accessor on new public API | Change to `set` or use constructor |
| Missing `PublicAPI.Unshipped.txt` entry | Add the API signature |
| Style / formatting violation | Fix to match `.editorconfig` |
| Missing null check at boundary | Add guard clause |
| Thread-safety issue | Apply appropriate synchronization |
| Missing XML doc comment | Add concise doc comment |
| Localization issue | Add/update `.resx` entry; do NOT edit `.xlf` files |

## Step 4 — Verify the Build

After applying all fixes:

1. Run `dotnet build` on the affected project(s) or the solution if unsure which
   projects are impacted.
2. If there are **build errors**, fix them. Repeat until the build succeeds.
3. Do **not** run the full test suite (it takes too long). Compilation
   verification is sufficient.

## Step 5 — Push Changes

Use the `push_to_pull_request_branch` safe output tool to push all edited files to the
PR branch. Provide a commit message in this format:

```text
Address review feedback

Applied fixes for N review comments from the expert-reviewer.
```

Do **not** run `git add`, `git commit`, or `git push` directly — credentials are not
available to the agent; the safe output handler manages authentication and enforces
protected-file policies.

## Step 6 — Post Summary

Post a comment on the PR summarizing what was done. Use this format:

> 🔧 **Autofix applied** — assessed N review comment(s).
>
> **Applied (M):**
>
> - `path/to/file.cs`: Brief description of change
> - `path/to/other.cs`: Brief description of change
>
> **Skipped with explanation (K):**
>
> - *"Consider using Span\<T> here"* — Skipped: not applicable on netstandard2.0 TFM without polyfill.
> - *"Nit: rename variable"* — Skipped: name is consistent with surrounding code.
>
> **No action needed (J):**
>
> - Informational / praise comments acknowledged.
>
> A re-review will be triggered automatically if code was pushed.
> <!-- autofix-iteration -->

Omit the **Skipped** or **No action needed** sections if they are empty.

If **no code changes** were needed (all comments were informational or
intentionally skipped), still post the summary but do **not** push a commit.

The `<!-- autofix-iteration -->` marker is **required** for the circuit breaker.
