Add initial PR review skills and skill validation hooks.

.agents/hooks.json

@@ -0,0 +1,23 @@
+{
+  "skill-linter-and-review-hook": {
+    "PostToolUse": [
+      {
+        "matcher": "write_to_file|replace_file_content|multi_replace_file_content",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "./.agents/scripts/validate_skills_hook.sh",
+            "timeout": 30
+          }
+        ]
+      }
+    ],
+    "PostInvocation": [
+      {
+        "type": "command",
+        "command": "./.agents/scripts/skill_post_invocation_hook.sh",
+        "timeout": 30
+      }
+    ]
+  }
+}

.agents/scripts/skill_post_invocation_hook.sh

@@ -0,0 +1,23 @@
+#!/bin/bash
+
+# Copyright 2026 The Flutter Authors
+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file or at https://developers.google.com/open-source/licenses/bsd.
+
+# Check if any skill file was modified in git working directory
+MODIFIED_SKILLS=$(git diff --name-only HEAD 2>/dev/null | grep "\.agents/skills/.*SKILL\.md$")
+
+if [ -n "$MODIFIED_SKILLS" ]; then
+  # Inject ephemeral message instructing AGY to review the modified skill
+  cat <<EOF
+{
+  "injectSteps": [
+    {
+      "ephemeralMessage": "AGY Skill Hook: The following skill files were modified: ${MODIFIED_SKILLS}. Please review the edited skills to ensure they follow best practices (conciseness, clear frontmatter) and verify that instructions are not repetitive or duplicative with existing style guides or skills."
+    }
+  ]
+}
+EOF
+else
+  echo "{}"
+fi

.agents/scripts/validate_skills_hook.sh

@@ -0,0 +1,23 @@
+#!/bin/bash
+
+# Copyright 2026 The Flutter Authors
+# Use of this source code is governed by a BSD-style license that can be
+# found in the LICENSE file or at https://developers.google.com/open-source/licenses/bsd.
+
+# Read AGY stdin JSON payload
+INPUT=$(cat)
+
+# Extract TargetFile from tool call arguments
+TARGET_FILE=$(echo "$INPUT" | python3 -c "import sys, json; data=json.load(sys.stdin); print(data.get('toolCall', {}).get('args', {}).get('TargetFile', ''))" 2>/dev/null)
+
+# Check if a skill file was modified
+if [[ "$TARGET_FILE" == *"SKILL.md"* ]] || [[ "$TARGET_FILE" == *".agents/skills"* ]]; then
+  echo "Skill edit detected: $TARGET_FILE" >&2
+  echo "Running dart_skills_lint..." >&2
+
+  # Run the skills linter from tool/ directory
+  (cd tool && dart run dart_skills_lint:cli)
+fi
+
+# PostToolUse expects an empty JSON object on stdout
+echo "{}"

.agents/skills/reviewing-devtools-prs/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: reviewing-devtools-prs
+description: DevTools repository-specific PR review workflow enforcing DevTools style guidelines and common review patterns. Use when reviewing pull requests in the flutter/devtools repository.
+---
+
+# Reviewing DevTools Pull Requests
+
+Extends [reviewing-prs](../reviewing-prs/SKILL.md) for pull requests in `flutter/devtools`. Follow [reviewing-prs](../reviewing-prs/SKILL.md) for GitHub CLI data retrieval and the strict user approval workflow.
+
+## References & Style Guidelines
+
+Read and enforce:
+- **Style Guide**: [styleguide.md](../../../.gemini/styleguide.md) (severity tags `[MUST-FIX]`, `[CONCERN]`, `[NIT]`, zero-formatting policy, copyright headers, DRY rules, magic values)
+- **Repository Constraints**: [AGENTS.md](../../../AGENTS.md)
+- **Code Style**: [STYLE.md](../../../STYLE.md)
+
+## Common Review Patterns
+
+1. **Listener & Resource Disposals**:
+   - Ensure controller and notifier listeners use `addAutoDisposeListener(...)`.
+
+2. **Helper Widgets over Helper Methods**:
+   - Prefer small composable `Widget` classes over helper methods returning `Widget` (`_buildFoo()`).
+
+3. **Reuse Shared Components & Test Helpers**:
+   - Use standard shared widgets (e.g. `CenteredMessage`) and test mocks (e.g. `mockConnectedApp`) instead of re-creating them inline.
+
+4. **TODO Formatting**:
+   - Link TODOs to a GitHub issue or LDAP: `// TODO(https://github.com/flutter/devtools/issues/<issue_number>): <description>`.
+
+5. **Async & Unawaited Futures**:
+   - Audit unawaited futures and suggest `unawaited(...)` or `safeUnawaited(...)` where appropriate.
+
+6. **Feature Flags**:
+   - Default feature flags to `false` with explicit test expectations in `feature_flags_test.dart`.
+
+7. **Test File Structure & PR Scope**:
+   - Place test fakes/helpers below `main()`.
+   - Ask authors to revert unrelated file changes or commented-out test code.
+
+8. **Constant Scoping**:
+   - Keep single-use constants local to the component, but extract user-facing UI strings into shared constants when used across multiple places.
+
+9. **Release Notes Scope (`NEXT_RELEASE_NOTES.md`)**:
+   - Release notes are strictly for end-user facing changes (e.g. Inspector, Memory UI/UX). Internal tools (`dt` / `devtools_tool`), CI, and refactors are NOT user-facing.
+   - Request removing release notes added for developer tools like `dt`, or suggest a `* <Description>. [#<PR_NUMBER>](https://github.com/flutter/devtools/pull/<PR_NUMBER>)` entry via [adding-release-notes](../adding-release-notes/SKILL.md) if a user-facing PR lacks one.

.agents/skills/reviewing-prs/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: reviewing-prs
+description: General workflow for fetching, inspecting, reviewing GitHub Pull Requests using the gh CLI, drafting user-aligned review comments, and securing approval before posting. Use when asked to review a GitHub PR or pull request.
+---
+
+# Reviewing Pull Requests
+
+This skill outlines the workflow for inspecting GitHub Pull Requests using the `gh` CLI, drafting review feedback, and securing user approval before posting review comments.
+
+## Approval Safeguard (Strict Requirement)
+
+> [!IMPORTANT]
+> **NEVER post comments or reviews to GitHub without explicit prior user approval.**
+> Always present draft review comments to the user in natural language first. Only execute write commands (`gh pr comment`, `gh pr review`) after the user approves.
+
+## Workflow
+
+### 1. Request Information via GitHub CLI
+
+- **PR Details**:
+  ```bash
+  gh pr view <pr-number> --repo <owner/repo> --json title,body,author,state,headRefName,baseRefName,comments,reviews,files
+  ```
+- **Code Diff**:
+  ```bash
+  gh pr diff <pr-number> --repo <owner/repo>
+  ```
+- **Existing Inline Comments**:
+  ```bash
+  gh api repos/<owner/repo>/pulls/<pr-number>/comments
+  ```
+- **CI / Status Checks**:
+  ```bash
+  gh pr checks <pr-number> --repo <owner/repo>
+  ```
+
+### 2. Inspect Context & Prior Feedback
+
+- Read the PR description, linked issues, and full diff.
+- Verify whether existing bot or human comments have already been addressed in subsequent commits.
+
+### 3. Draft Review Comments
+
+- Keep comments direct, concise, and focused on code quality and correctness.
+- **Approvals**: Keep comments concise (`LGTM` or `A couple comments but lgtm.`). Avoid fluffy praise or re-summarizing the PR.
+- **Actionable Feedback**: Reference specific files, line numbers, and rationale when leaving suggestions.
+
+### 4. Present Draft & Post Only Upon User Approval
+
+> [!IMPORTANT]
+> **NEVER post comments or reviews to GitHub without explicit prior user approval.**
+
+1. Present the drafted review comments to the user in your response window.
+2. Ask for confirmation: *"Would you like me to submit this review to GitHub?"*
+3. Once explicitly approved by the user, post the review:
+   ```bash
+   gh pr review <pr-number> --repo <owner/repo> --comment --body "<approved review text>"
+   ```

.gemini/styleguide.md

@@ -27,7 +27,8 @@ and the CI testing ensures that the code is formatted correctly.
 * **Readability**: Code should be easy to understand for all contributors.
 * **Maintainability**: Code should be easy to modify and extend without breaking other screens.
 * **Consistency**: Adhering to consistent style across all DevTools packages improves collaboration and reduces errors.
-* **Code Reuse**: Use shared primitives and components rather than recreating them from scratch.
+* **Code Reuse & DRY**: Use shared primitives and components rather than recreating them from scratch. Flag duplicated code blocks (90%+ identical) and repeated sub-expressions or function calls within the same method as `[CONCERN]` or `[NIT]`, and suggest extracting them into local variables or constants.
+* **Constants & Magic Values**: Avoid using raw/magic strings or numbers. Extract them into descriptive named constants so the intent and meaning of the values are clear.
 * **Testing**: All changes should include automated tests to ensure correctness and prevent regressions.
 
 ## 3. Guidelines from Existing Documentation