Make android reviewer skill offline-only

.github/aw/actions-lock.json

@@ -1,10 +1,25 @@
 {
   "entries": {
+    "actions/checkout@v6.0.2": {
+      "repo": "actions/checkout",
+      "version": "v6.0.2",
+      "sha": "de0fac2e4500dabe0009e67214ff5f5447ce83dd"
+    },
+    "actions/download-artifact@v8.0.1": {
+      "repo": "actions/download-artifact",
+      "version": "v8.0.1",
+      "sha": "3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c"
+    },
     "actions/github-script@v9": {
       "repo": "actions/github-script",
       "version": "v9",
       "sha": "373c709c69115d41ff229c7e5df9f8788daa9553"
     },
+    "actions/upload-artifact@v7.0.1": {
+      "repo": "actions/upload-artifact",
+      "version": "v7.0.1",
+      "sha": "043fb46d1a93c77aae656e7c1c64a875d1fc6a0a"
+    },
     "github/gh-aw-actions/setup@v0.68.3": {
       "repo": "github/gh-aw-actions/setup",
       "version": "v0.68.3",

.github/skills/android-reviewer/SKILL.md

@@ -10,6 +10,8 @@ description: >-
 
 Review PRs against guidelines distilled from past reviews by senior maintainers of dotnet/android.
 
+This skill is **offline-only**. It analyzes pull requests and prepares review findings, but it must not post GitHub comments, submit pull request reviews, or call write-capable GitHub tools directly. If an agentic workflow invokes this skill, the workflow is responsible for publishing the prepared findings through its configured safe-output tools.
+
 ## Review Mindset
 
 Be polite but skeptical. Prioritize bugs, performance regressions, safety issues, and pattern violations over style nitpicks. **3 important comments > 15 nitpicks.**
@@ -101,16 +103,47 @@ Constraints:
 - **Don't flag what CI catches.** Skip compiler errors, formatting the linter will catch, etc.
 - **Avoid false positives.** Verify the concern actually applies given the full context. If unsure, phrase it as a question rather than a firm claim.
 
-### 7. Post the review
+### 7. Prepare the review output
 
-Post your findings directly:
+Prepare findings for the caller to publish or inspect:
 
-- **Inline comments** on specific lines of the diff with the severity, category, and explanation.
+- **Inline findings** for specific lines of the diff with the severity, category, and explanation.
 - **Review summary** with the overall verdict (✅ LGTM, ⚠️ Needs Changes, or ❌ Reject), issue counts by severity, and positive callouts.
 
-If no issues found **and CI is green**, submit with at most one or two 💡 suggestions and a positive summary. Truly trivial PRs (dependency bumps, 1-line typo fixes) may have no inline comments.
+If no issues are found **and CI is green**, include at most one or two 💡 suggestions and a positive summary. Truly trivial PRs (dependency bumps, 1-line typo fixes) may have no inline findings.
+
+For interactive CLI/chat use, present the review in readable Markdown:
+
+```markdown
+**Verdict:** ⚠️ Needs Changes
+
+Brief summary of the review, including issue counts, positive callouts, and CI status.
+
+**Findings:**
+- `path/to/file.cs:42` — 🤖 ⚠️ **Category** — Explain the issue and what to do instead.
+```
+
+If an agentic workflow or other automation needs machine-readable output, return the same information in this shape so the caller can publish it through its configured mechanisms:
+
+```json
+{
+  "verdict": "LGTM | Needs Changes | Reject",
+  "summary": "Overall review summary with issue counts and positive callouts.",
+  "copilot_pr_summary_prefix_required": false,
+  "findings": [
+    {
+      "path": "src/Example.cs",
+      "line": 42,
+      "side": "RIGHT",
+      "severity": "error | warning | suggestion",
+      "category": "Correctness",
+      "body": "🤖 ⚠️ **Correctness** — Explain the issue and what to do instead.\n\n_{Rule: Brief name (Postmortem `#N`)}_"
+    }
+  ]
+}
+```
 
-**Copilot-authored PRs:** If the PR author is `Copilot` (the GitHub Copilot coding agent) and the verdict is ⚠️ Needs Changes or ❌ Reject, prefix the review summary with `@copilot ` so the comment automatically triggers Copilot to address the feedback. Do NOT add the prefix for ✅ LGTM verdicts.
+**Copilot-authored PRs:** If the PR author is `Copilot` (the GitHub Copilot coding agent) and the verdict is ⚠️ Needs Changes or ❌ Reject, set `copilot_pr_summary_prefix_required` to `true` so a publishing workflow can prefix the review summary with `@copilot `. Do NOT request that prefix for ✅ LGTM verdicts.
 
 ## Comment format
 

.github/workflows/android-reviewer.md

@@ -30,6 +30,8 @@ tools:
     # The /review command is gated to maintainers, so only trusted users can trigger it.
     min-integrity: none
 safe-outputs:
+  add-comment:
+    max: 1
   create-pull-request-review-comment:
     max: 50
   submit-pull-request-review:
@@ -43,15 +45,18 @@ A maintainer commented `/review` on this pull request. Perform a thorough code r
 
 ## Instructions
 
-1. Read the review methodology from `.github/skills/android-reviewer/SKILL.md` — this defines the review workflow, mindset, severity levels, comment format, and which rule files to load based on changed file types.
+1. Read the review methodology from `.github/skills/android-reviewer/SKILL.md` — this defines the offline review workflow, mindset, severity levels, comment format, and which rule files to load based on changed file types. The skill prepares findings only; this agentic workflow is responsible for publishing them.
 2. Follow the skill's workflow to analyze the pull request:
    - Gather context: read the diff and changed files
    - For each changed file, read the **full source file** to understand surrounding context
    - Form an independent assessment before reading the PR description
    - Read the PR title and description — treat claims as things to verify
    - Check CI status
    - Analyze the diff against the review rules
-3. Post your findings as inline review comments and a review summary.
+3. Publish the prepared findings through safe-output tools:
+   - Use `add_comment` once to post a terse PR conversation comment stating that the `/review` run completed and that detailed findings are in the submitted review.
+   - Use `create_pull_request_review_comment` for each inline finding.
+   - Use `submit_pull_request_review` once with the overall review summary. Use `COMMENT` for clean or informational reviews and `REQUEST_CHANGES` when blocking issues are found.
 
 ## Constraints
 
@@ -62,3 +67,4 @@ A maintainer commented `/review` on this pull request. Perform a thorough code r
 - Avoid false positives — verify concerns given the full file context.
 - **Never submit an APPROVE event.** Use COMMENT for clean PRs and REQUEST_CHANGES when issues are found.
 - Prioritize: bugs > safety > performance > missing tests > duplication > consistency > documentation.
+- Do not use direct GitHub write APIs or write-capable MCP tools. Publish only through the configured safe-output tools.