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/agents/arm-api-reviewer.agent.md
+37-3Lines changed: 37 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -314,10 +314,10 @@ After presenting the review findings to the human reviewer for approval:
314
314
The existing comment already covers the exact same rule violation on the same file and line. **Skip posting.** No action needed.
315
315
316
316
**Scenario B - Same finding, different line, comment was from _this agent or the same engineer running the agent_:**
317
-
The code has shifted (e.g., lines were added/removed) and the existing comment now points to an outdated line, but the violation still exists at a new location. **Resolve the outdated comment** (to reduce noise) and **post a new comment at the correct line** with the updated finding. In the new comment, reference the resolved thread (e.g., "_(Updated from previous comment at \<url\> - line shifted due to code changes.)_"). To identify whether an existing comment was posted by this agent, check if its body contains the hidden marker `<!-- posted-by: arm-api-reviewer-agent -->`. Comments with this marker are agent-posted; comments without it are from human reviewers (apply Scenario C instead).
317
+
The code has shifted (e.g., lines were added/removed) and the existing comment now points to an outdated line, but the violation still exists at a new location. **Resolve the outdated comment** (to reduce noise) and **post a new comment at the correct line** with the updated finding. In the new comment, reference the resolved thread (e.g., "_(Updated from previous comment at \<url\> - line shifted due to code changes.)_"). To identify whether an existing comment was posted by this agent, check if its body contains the substring `posted-by: arm-api-reviewer-agent`. Comments with this substring are agent-posted; comments without it are from human reviewers (apply Scenario C instead).
318
318
319
319
**Scenario C - Same finding, different line, comment was from a _different_ human reviewer:**
320
-
Another ARM reviewer (not this agent) posted the comment at the old line -- i.e., the comment body does **not** contain `<!-- posted-by: arm-api-reviewer-agent -->`. Do **not** resolve their comment - it is their review thread and they may be tracking the conversation. Do **not** post a duplicate comment. Instead, **add a reply** to the existing thread noting the line shift: e.g., "_The code referenced by this comment has moved. The same violation now appears at `<file>` - line <N>. The issue is still unresolved._" This helps the author and reviewer find the right code without creating duplicate threads.
320
+
Another ARM reviewer (not this agent) posted the comment at the old line -- i.e., the comment body does **not** contain the substring `posted-by: arm-api-reviewer-agent`. Do **not** resolve their comment - it is their review thread and they may be tracking the conversation. Do **not** post a duplicate comment. Instead, **add a reply** to the existing thread noting the line shift: e.g., "_The code referenced by this comment has moved. The same violation now appears at `<file>` - line <N>. The issue is still unresolved._" This helps the author and reviewer find the right code without creating duplicate threads.
321
321
322
322
**Scenario D - No new findings beyond what existing comments already cover:**
323
323
If every finding from the current review is already covered by an existing comment (same file, same or nearby line, same rule), **do not post any new comments**. Report to the human reviewer: "_All findings from this review are already covered by existing comments on the PR. No new comments are needed - the existing threads already highlight the required changes._" List the existing comment threads that match, **including the comment URL** for each so the reviewer can click through and verify.
@@ -333,7 +333,22 @@ After presenting the review findings to the human reviewer for approval:
333
333
5. Every posted comment **MUST** clearly tag the issue as `[NEW]` or `[EXISTING]` with an explanation of the classification (e.g., "This issue also exists in `2025-12-01-preview` at the same JSON path" or "Introduced in this PR - this property did not exist in the previous version").
334
334
6. For `[NEW]` issues, include the severity level: `🔴 Blocking`, `🟡 Warning`, or `💡 Suggestion`.
335
335
7. Use the format: ``**[NEW] 🔴 Blocking** **[<Rule ID>]** `<file-path>` - line <N> - <issue description>`` or ``**[EXISTING]** **[<Rule ID>]** `<file-path>` - line <N> - <issue description>`` followed by the classification reasoning and suggested fix.
336
-
8. Every posted comment **MUST** end with the hidden HTML marker `<!-- posted-by: arm-api-reviewer-agent -->` as the very last line of the comment body. This marker is invisible in rendered markdown but enables querying agent-posted comments via the GitHub API and distinguishing them from manually posted comments during reconciliation. Do not omit this marker.
336
+
8. Every posted comment **MUST** end with a hidden HTML telemetry marker as the very last line of the comment body. The marker format is:
-**`rule`**: The rule ID of the finding (e.g., `RPC-Put-V1-01`, `OAPI027`, `SEC-SECRET-DETECT`). Use `summary` for summary comments that don't flag a single rule.
343
+
-**`severity`**: One of `blocking`, `warning`, or `suggestion`.
344
+
-**`classification`**: One of `new` (introduced in this PR) or `existing` (pre-existing technical debt).
This marker is invisible in rendered markdown but enables querying agent-posted comments via the GitHub API, computing telemetry (comments per day, top rule violations, new-vs-existing ratio), and distinguishing agent comments from human comments during reconciliation. Do not omit this marker. All fields after `posted-by` are required.
349
+
350
+
**Backward compatibility:** To detect whether an existing comment was posted by this agent (e.g., during reconciliation in Scenarios B and C), check if the comment body contains the substring `posted-by: arm-api-reviewer-agent`. This matches both the old simple marker and the new extended marker.
351
+
337
352
9. Prioritize posting **New** issues first, as these are the PR author's direct responsibility.
338
353
10.**Report a reconciliation summary** to the human reviewer before posting:
339
354
- Findings to **post as new comments** (with line numbers)
@@ -356,6 +371,24 @@ After successfully posting review comments to the PR:
356
371
4. If the PR does not have the `WaitForARMFeedback` label, skip the removal step and only propose adding `ARMChangesRequested`.
357
372
5. Report to the human reviewer which labels were added and removed.
358
373
374
+
### Step 9: Clean Up Local Workspace
375
+
376
+
If the review required creating any local artifacts to inspect the PR (typically a Git worktree and/or local branch tracking the PR's head ref - for example, when the PR is too large for `gh pr diff` to handle), **clean these up at the end of the review**, after the comments have been posted (Step 7) and labels updated (Step 8).
377
+
378
+
1.**Inventory** anything created during this session:
379
+
- Local branches matching `pr-<number>` or similar patterns created by you.
380
+
- Worktrees created by you (e.g., `<repo>/../specs-pr-<number>`).
381
+
- Temporary files written to the workspace root (e.g., `review-payload.json`, `review-body.txt`).
382
+
2.**Confirm the user is not still using them.** If `git status` in the worktree shows uncommitted work, ask the user before removing.
4.**Do not** touch branches, worktrees, or files that pre-existed the review (e.g., the user's working branch, unrelated worktrees, the user's stashes).
388
+
5.**Report** what was cleaned up to the user.
389
+
390
+
This keeps the user's workspace tidy and prevents accumulation of stale `pr-*` branches across reviews.
391
+
359
392
## Constraints
360
393
361
394
-**Read-only.** This agent does not modify specification files. Its job is to flag issues and suggest fixes, not apply them.
@@ -366,6 +399,7 @@ After successfully posting review comments to the PR:
366
399
-**Clean specs get clean reports.** If after thorough review a specification has no blocking violations, explicitly state that no blocking issues were found. Do not downgrade compliant patterns into violations. For example: a spec that correctly uses common-types, has all required CRUD operations, includes `provisioningState` with the right terminal states, and follows naming conventions should receive a clean bill of health -- not a list of fabricated issues. The absence of findings is a valid review outcome.
367
400
-**Scope boundaries.** Do not review SDK code, pipeline configs, or infrastructure files. Only review specification artifacts (OpenAPI JSON, TypeSpec `.tsp`, `tspconfig.yaml`, examples, readmes for AutoRest config).
368
401
-**Always compare versions.** When a previous API version exists in the repository, load it and check for breaking changes. Do not skip this step.
402
+
-**Clean up after yourself.** Any local branches, worktrees, or temporary files you create to inspect a PR MUST be removed at the end of the review (see Step 9). Never leave stale `pr-*` branches or scratch JSON payloads in the user's workspace.
To detect agent-posted comments during reconciliation, check for the substring `posted-by: arm-api-reviewer-agent` (matches both old and new marker formats).
189
+
182
190
---
183
191
184
192
## Severity Calibration
@@ -246,7 +254,7 @@ When reviewing a PR that already has comments from a prior review:
246
254
The existing comment already covers this violation. **Skip posting.**
247
255
248
256
**Scenario B -- Same finding, line shifted, agent-posted comment:**
249
-
The existing comment has the marker `<!-- posted-by: arm-api-reviewer-agent -->`.
257
+
The existing comment body contains the substring `posted-by: arm-api-reviewer-agent`.
250
258
Resolve the outdated comment and post a new one at the correct line.
251
259
252
260
**Scenario C -- Same finding, line shifted, human-posted comment:**
0 commit comments