Add Copilot code review quality guidance (#3665)

* Add Copilot code review quality guidance

Add a repository-specific Copilot Code Review skill for repo-fit, provenance, differentiation, validation, and marketing-signal review. Wire it into the repo review instructions and CODEOWNERS, add an advisory PR quality-signal workflow, and tighten the Learning Hub updater instructions to reuse existing bot PRs instead of creating duplicate stale update PRs.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Fix PR review workflow feedback

Add constrained safe outputs for reusing and closing Learning Hub bot pull requests, and declare the quality-signal workflow name in source frontmatter.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Upgrade agentic workflows

Rebase the PR onto main and upgrade gh-aw to v0.88.8. Refresh setup actions, generated workflow locks, container pins, and updater permissions.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

.github/workflows/pr-quality-signal.md

@@ -0,0 +1,120 @@
+---
+name: PR Quality Signal Review
+description: 'Advisory review for PR quality signals: repo fit, AI disclosure, duplication risk, and marketing-heavy submissions'
+on:
+  pull_request:
+    types: [opened, reopened, synchronize, edited]
+permissions:
+  contents: read
+  pull-requests: read
+tools:
+  github:
+    toolsets: [repos, pull_requests]
+safe-outputs:
+  add-comment:
+    max: 1
+    hide-older-comments: true
+  noop:
+    report-as-issue: false
+---
+
+# PR Quality Signal Review
+
+You are an AI reviewer helping maintain the signal quality of submissions to this repository.
+Your job is to look for high-probability review signals that suggest a pull request may be low-value, shallow, duplicate, or overly marketing-focused rather than clearly useful to the repository.
+
+## Scope
+
+Review pull requests that touch the repository's core resource directories and content, with special attention to:
+
+- `agents/`
+- `instructions/`
+- `skills/`
+- `workflows/`
+- `hooks/`
+- `plugins/`
+- `website/`
+
+This workflow is advisory only. It should flag likely quality issues and suggest a tighter review focus, but it should not block or approve a merge on its own.
+
+## Step 1 — Gather PR context
+
+Read the PR metadata for the current pull request, including:
+
+- title
+- description/body
+- author login
+- labels
+- changed files
+
+If the PR title ends with `🤖🤖🤖`, treat that as an explicit AI-disclosure signal. This is not automatically a bad submission, but it is a signal that the author should make the value and repository fit obvious and concrete.
+
+## Step 2 — Evaluate high-signal quality checks
+
+Assess the PR against these signals, in order of confidence:
+
+### 1. Repository fit and usefulness
+
+Look for evidence that the contribution solves a specific, real problem in the repository's scope.
+
+Flag for review when the PR:
+
+- has vague or generic framing with little concrete value
+- reads like self-promotion or product marketing rather than a useful contribution
+- proposes overlap with existing resources without a clear differentiator
+- adds a broad "AI can do everything" pattern with no domain-specific constraint or workflow
+- changes website or docs content without a clear factual update tied to a feature, migration, or user need
+
+### 2. AI disclosure and provenance
+
+If `🤖🤖🤖` is present, check whether the PR body explains:
+
+- what was generated or iterated with AI
+- why the content is still useful and repo-relevant
+- whether the author tested or validated the result
+
+A PR that uses AI but does not explain the value beyond "I prompted an agent" is a weaker signal.
+
+### 3. Duplicate or low-differentiation risk
+
+Compare the changed files to existing resources in the repository. If the PR appears to be a near-duplicate, a reworded version of an existing pattern, or a marketing wrapper around a generic capability, note it as a reviewer signal.
+
+### 4. Missing evidence
+
+Flag when there is no clear validation or rationale, such as:
+
+- no examples or usage guidance
+- no tests, validation steps, or operational constraint
+- no explanation of why the value is not already covered by a stronger existing resource
+
+## Step 3 — Produce a single review comment
+
+If one or more high-confidence signals are present, leave a single PR comment in this format:
+
+```markdown
+## ⚠️ PR Quality Signal Review
+
+This PR shows one or more review signals that deserve a closer look before merge.
+
+| Signal | Evidence | Recommendation |
+|---|---|---|
+| Repo fit | <short description> | <what to clarify or tighten> |
+| AI disclosure | <AI marker or explanation status> | <ask for concrete value and validation> |
+| Marketing-heavy framing | <why this looks promotional> | <refocus on concrete user need and repo fit> |
+| Duplicate / low differentiation | <why this overlaps existing content> | <explain unique value or merge into existing coverage> |
+| Missing evidence | <what is absent> | <add examples, tests, or rationale> |
+
+This is an advisory signal review only. It does not replace human judgment.
+```
+
+If the PR looks healthy and does not show high-confidence quality concerns, call `noop` with the message:
+
+`No high-confidence quality signals detected in this PR. Repo fit and value look reasonable.`
+
+## Guidelines
+
+- Be conservative: only call out issues when the signal is strong and actionable.
+- Treat `🤖🤖🤖` as a signal of provenance, not a negative by itself.
+- Prefer repo-fit, clarity, evidence, and differentiation over raw file count or "vibe".
+- Keep the feedback brief and specific enough for a maintainer to act on quickly.
+- If a PR is clearly a trusted-source submission (for example, a GitHub/Microsoft plugin submission), do not flag it merely because it is automated or externally sourced. Use the signal map for low-signal and low-value items, not trusted paths.