code-review skill

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.

Validate frontmatter as YAML and check the required metadata, not quote style. Plain, single-quoted, double-quoted, literal, and folded scalars are all acceptable when they parse to values that meet the field's type and content requirements. Do not request changes solely because a value is not single-quoted.

For skills, use the Agent Skills specification for SKILL.md structure and field constraints, plus the repository-specific checks in .github/copilot-instructions.md. General YAML validity does not replace the specification: for example, metadata must map strings to strings, and allowed-tools must be a space-separated string, not a sequence. Check parsed types and values without imposing a quote style.

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.

Repository fit is not limited to coding or other text-based developer tasks. Consider the workflows Copilot supports, including image, video, audio, other media generation, and creative work where applicable. Modality or non-coding use alone is not a reason to reject; require concrete Copilot relevance and specific standalone user value.

Flag contributions that:

meaningful uplift (see Knowledge uplift)

• provide generic advice that current models already handle well without

• 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.

Assess knowledge uplift, provenance, product/vendor-funnel evidence, responsible use, and validation appropriate to the workflow independently of its modality. Reject marketing-only funnels, paid or credit-based acquisition paths without standalone user value, duplicates of native Copilot features, and generic content with no meaningful uplift.

Knowledge uplift

A resource is only valuable if it changes what the model does. Well-formatted, compliant content can still add nothing. Apply this test to every agent, instruction, skill, prompt, hook, or workflow that a PR adds or substantially changes:

loaded. What would it do?

1. Picture a current frontier model given the same task with no resource

delta, not the content itself.

1. Identify what this resource makes it do differently. The value is that

Count as real uplift:

APIs, version-specific breaking changes, and non-obvious gotchas

• facts the model is unlikely to know or get right, such as recent or niche

• internal, proprietary, or organization-specific tools and conventions
• constraints that deliberately override sensible defaults
• bundled scripts, templates, or data that produce deterministic results
• multi-step workflows that wire specific tools or MCP servers together
• concrete examples of non-obvious expected output

Do not count as uplift:

writing tests, or handling errors

• generic best practices such as clean code, SOLID, DRY, meaningful names,

frameworks

• restatements of well-known public documentation for mainstream languages and

• persona framing such as "You are an expert X" without new constraints
• checklists of behavior models already exhibit by default
• long prose that a one-line user request would replace

Length, polish, and structure are not evidence of value. Quote or cite the specific lines that carry the uplift; if you cannot find any, say so plainly. Classify the result as:

• high — most of the content is non-obvious to a capable model
• partial — a useful core surrounded by generic filler
• none — a capable model would behave essentially the same without it

Do not recommend approval when uplift is none. For partial, ask the author to cut the named generic sections and expand the specific ones.

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:

use GitHub Copilot

• 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

UTM or referral links, or credit-based upsells pointing at the author's service, including adapted copies where the vendor name was removed but the hook remains. Check the LICENSE copyright holder, metadata.author, and the upstream repository README to confirm who owns the content.

• a "free resource → paid connector" structure: MCP/connector setup commands,

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:

scenario or describe how their output was evaluated

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

validation steps

• scripts and bundled assets should have focused tests or reproducible

permissions, constrained outputs, and expected event behavior

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