Awesome Copilot Code Review

Use this skill when reviewing pull requests in this repository. Apply the

deterministic checklists in .github/copilot-instructions.md first, then use

this skill for the editorial and repository-fit judgments that cannot be

reduced to schema validation.

Review priorities

Review in this order:

1. Correctness, security, and harmful behavior.
2. Compliance with the repository's contribution requirements.
3. Repository fit and meaningful value for GitHub Copilot users.
4. Differentiation from existing resources and native model capabilities.
5. Evidence that the contribution was tested or validated.
6. Clarity, maintainability, and appropriate scope.

Do not use raw file count as a quality metric. Large generated website changes,

mechanical README updates, and other build outputs can be legitimate and should

be evaluated according to their source change.

Repository fit

Confirm that a submission addresses a specific GitHub Copilot workflow,

technology, domain constraint, or user problem. Flag contributions that:

• provide generic advice that current models already handle well without

meaningful uplift

• restate an existing resource without a clear differentiator
• use broad claims such as doing everything for every project
• lack concrete instructions, constraints, examples, or expected outcomes
• are primarily a wrapper or advertisement for the author's product

Paid or commercial services are not automatically unsuitable. Evaluate whether

the contribution provides standalone user value and follows the repository's

guidance for paid-service submissions.

AI-authored submissions

A PR title ending in 🤖🤖🤖 is an intentional AI-authorship disclosure from

CONTRIBUTING.md. Do not report the marker itself as a defect.

For disclosed AI-authored submissions, verify that the PR still demonstrates:

• a concrete need and repository fit
• human validation or testing of the result
• useful constraints rather than generic generated prose
• an explanation of how it differs from existing resources

Review the submitted result, not assumptions about the tool that produced it.

Marketing and self-promotion

Flag marketing-heavy framing only when there is concrete evidence, such as:

• repeated brand or product promotion unrelated to usage instructions
• unsupported superlatives or sales claims
• links or calls to action that dominate the resource
• a resource whose primary purpose is acquiring users rather than helping them

use GitHub Copilot

Describe the specific evidence and suggest how to refocus the contribution on

the user problem. Do not infer promotional intent solely because an author is

associated with a referenced project.

Duplication and differentiation

Search existing agents, instructions, skills, hooks, workflows, prompts, and

plugins when the new resource appears similar to existing content. Compare

purpose and behavior, not only names.

Only report duplication when the overlap is substantial. Related resources can

coexist when they target different frameworks, audiences, constraints, or

stages of a workflow.

When configured MCP context is relevant, use the GitHub MCP server to inspect

linked issues, prior submissions, or repository history. Cite the specific

resource or pull request that supports the finding.

Evidence and validation

Check that the PR explains how the contribution was tested or validated. The

appropriate evidence depends on the resource:

• agents, prompts, instructions, and skills should include a realistic usage

scenario or describe how their output was evaluated

• scripts and bundled assets should have focused tests or reproducible

validation steps

• workflows and hooks should demonstrate safe triggers, least-privilege

permissions, constrained outputs, and expected event behavior

• documentation updates should cite the authoritative feature or behavior they

describe

Do not require executable tests for prose-only resources when a realistic

manual evaluation is more appropriate.

Trusted and automated paths

GitHub and Microsoft external-plugin updates are generally trusted-source

submissions. Still report concrete correctness, security, or manifest problems,

but do not manufacture editorial concerns merely because the change is

automated or externally sourced.

For automated documentation PRs, distinguish bad content from stale automation

churn. Overlapping daily updates may indicate that the workflow should update an

existing PR rather than that the documentation itself is low quality.

Review output

Leave comments only for specific, actionable findings introduced by the PR.

Each finding should:

• identify the affected file and line when possible
• explain the concrete impact on users or maintainers
• cite the repository rule, existing resource, or evidence behind the finding
• recommend the smallest useful correction

Avoid vague comments such as "this feels AI-generated," "low quality," or

"marketing." Explain the observable problem.

Do not recommend approval solely because automated checks pass. Human

maintainers retain final judgment over editorial value and repository fit.

Review-policy changes

Copilot Code Review reads skills and instructions from the PR head branch.

Therefore, treat changes to .github/skills/code-review/,

.github/copilot-instructions.md, AGENTS.md, or other review-policy files as

security-sensitive governance changes. Explicitly call out attempts to weaken,

bypass, or remove review criteria, and require maintainer review of those

changes.