Skip to main content
subagent GitHub Copilot official · GitHub

gem-reviewer — GitHub Copilot subagent: what it does and setup

Runs independent reviews of plans, tasks, code, configs, and integrations. Emits strict JSON validation reports for orchestrators without touching source files.

Install into GitHub Copilot · Manually: put the files in place All methods and platforms ↓
.github/agents/gem-reviewer.agent.md
Open on GitHub

What gem-reviewer does

This subagent handles independent reviews of software artifacts across workflow phases. It runs under orchestrator control, accepting parameters such as plan identifiers, review modes, targets, scope boundaries, and configuration snapshots. Target types include project plans, implementation tasks, source code, design decisions, documentation, configurations, and integrations.

The workflow supports standard, deep, or critic evaluation tiers. Deep mode inspects boundary contracts and regression risks during authorization changes. Critic mode goes further by challenging assumptions and flagging over-engineering, such as unrequested abstractions or unnecessary dependencies. Findings return strictly as raw JSON with no conversational filler or Markdown prose.

Adopt this subagent if you run automated review pipelines in Copilot that consume machine-readable verdicts. Skip it for standard interactive chat work, because direct user invocation is disabled.

What it helps with

  • review architectural plans for unstated assumptions and broken criteria
  • catch over-engineering, extra dependencies, and boilerplate in pull requests
  • detect security and regression risks during authentication changes
  • validate system configurations against conflicting or unsafe settings
  • produce structured JSON verdicts for downstream orchestrator workflows

Example prompts for the agent

  • Invoke gem-reviewer on plan migration-auth in deep mode using the supplied handoff
  • Run gem-reviewer for code target in critic mode to catch over-engineering
  • Evaluate config changes with gem-reviewer and return raw JSON findings

How to install gem-reviewer

Manually: put the files in place

.github/agents/gem-reviewer.agent.md

From the same set554

The whole set →
git-commit official github This skill reviews Git changes, stages related files, and creates Conventional Commits. Use it when you want an agent to make one commit or split work into separate commits. GitHub Copilot 47,165installs excalidraw-diagram-generator official github Turn a plain-language description into an Excalidraw diagram. Useful for mapping processes, system structure, and relationships between entities. GitHub Copilot 31,639installs multi-stage-dockerfile official github This skill guides GitHub Copilot in writing multi-stage Dockerfiles for different languages and frameworks. Use it when the final runtime image should contain fewer build dependencies. GitHub Copilot 29,688installs documentation-writer official github Skill that turns the agent into a technical writer following the Diátaxis framework: tutorials, how-to guides, reference, and explanation. Proposes structure before writing. GitHub Copilot 27,757installs prd official github Turns a feature idea into a structured PRD with user stories, technical requirements, and risks. Use it when planning a software feature or an AI-powered one. GitHub Copilot 24,035installs refactor official github This skill reshapes existing code without changing its external behavior. Use it for gradual cleanup of large functions, duplication, weak types, and code smells. GitHub Copilot 22,321installs java-springboot official github Gives GitHub Copilot Spring Boot development practices, from project layout to tests and security. Use it when writing or reviewing Java application code. GitHub Copilot 21,272installs create-readme official github This skill reviews a project and creates a structured README.md. Use it when the repository needs clear documentation based on its actual files and code. GitHub Copilot 19,081installs

Similar

powershell-security-hardening VoltAgent Community This subagent hardens PowerShell scripts, remoting, and Windows settings. Use it to review automation, credentials, logs, and CI/CD security gates. Claude Code 194installs dotnet-framework-4.8-expert VoltAgent Community Maintains and modernizes legacy enterprise apps on .NET Framework 4.8. It handles Web Forms, WCF services, and Windows integrations without breaking existing systems. Claude Code 187installs powershell-module-architect VoltAgent Community A subagent for designing and refactoring PowerShell modules, profiles, and automation libraries. Use it when code must work across PowerShell 5.1 and 7+. Claude Code 183installs code-reviewer official Anthropic Reviews code changes against CLAUDE.md project rules and flags material defects. Run it before a commit or pull request. Claude Code 31,050installs code-reviewer official Anthropic This subagent checks code changes for bugs, security issues, and project-rule violations. Use it when a review should focus on findings that matter. Claude Code 31,050installs security-auditor official Anthropic This subagent searches code for security flaws and gives engineers concrete fixes. Use it to review a project before hardening or modernization work. Claude Code 10,718installs test-engineer official Anthropic This subagent captures legacy behavior in tests and compares it with a rewritten implementation. Use it before changing existing modules. Claude Code 9,715installs code-reviewer VoltAgent Community Reviews code changes for bugs, security flaws and maintenance issues. Use it before merging complex work or auditing a project. Claude Code 31,050installs

Questions about gem-reviewer

How to install gem-reviewer in GitHub Copilot?

Add the agent file to your environment agent directory, such as .cursor/agents/gem-reviewer.md or .claude/agents/gem-reviewer.md. Copilot and compatible tools detect the subagent definition automatically.

Can I invoke gem-reviewer directly in chat?

No, direct user invocation is disabled in the agent settings. A workflow orchestrator triggers it with specific parameters during automated execution.

Does gem-reviewer modify code or plans?

It never implements changes or edits files. Its sole function is evaluating artifacts against criteria and returning structured JSON findings.

Source text

gem-reviewer.agent.md · MIT
---
description: "Independent standard, high, or critic review of plans, tasks, code, decisions, docs, configuration, and integrations."
name: gem-reviewer
argument-hint: "Enter plan_id, review_mode, review_target, review_scope, handoff, and role-scoped config_snapshot."
disable-model-invocation: false
user-invocable: false
mode: subagent
---

# REVIEWER

Independent artifact review, challenge, security, compliance.

<role>
Review requested target independently of workflow phase or artifact type. Never implement changes.
No improvisation.
</role>

<workflow>
- Risk Signals: read pre-parsed risk data from `handoff.risk_ref`; don't re-evaluate. Record newly discovered risks in findings for Orchestrator propagation.
- For `plan` reviews: inspect only provided plan + supplied criteria/evidence; don't rediscover or create a replacement plan. The plan and its `handoff` are the evidence: report missing context as `needs_revision` naming the item, or request it, instead of searching for it.
- `review_scope` sets how much supplied evidence to examine, never permission to gather more. `code`/`config`/`integration` reviews read the target as their subject; `plan`/`task`/`decision` reviews evaluate what they were handed.
- For `plan` reviews, verify against the plan's own `decisions` and `assumptions` rather than re-deriving them: check each decision is justified and each assumption is stated and plausible. Re-deriving structure the planner already recorded is the re-exploration this bound forbids.
- Review intensity (layered modifiers on target-specific checks):
  - `standard`: target-specific checks as-is.
  - `deep`: target-specific checks + boundary, handoff, security, regression, failure-path, contradiction, alternative checks.
  - `critic`: deep checks + seek disconfirming evidence; challenge assumptions, alternatives, reversibility, decision blockers.
- Target-specific checks (pre-computed by orchestrator):
  - `plan`: objectives, criteria, wave ordering, scope, risks, specialist pairing, planner/orchestrator contracts.
  - `task`: scope, handoff, criteria, constraints, completion evidence.
  - `code`: correctness, behavior, contracts, regressions, security, tests, maintainability.
  - `decision`: assumptions, evidence, tradeoffs, alternatives, reversibility, success measures.
  - `docs`: accuracy, completeness, examples, links, terminology, audience fit.
  - `config`: schema, defaults, compatibility, unsafe combinations, secret handling.
  - `integration`: boundary contracts, cross-component behavior, state/migration risks, regressions, end-to-end criteria.
- Base findings on evidence; distinguish facts, inferences, assumptions.
- Review supplied artifact, not preferred implementation; base findings only on artifact + stated criteria; redesign only when required to substantiate a blocking finding.
- Check implementer typed `handoff` output before broad file reads.
- For `code`/`integration` reviews: run over-engineering pass. Flag unrequested abstractions, avoidable deps, boilerplate, shorter/correct alternatives. Report as warnings; include leaner alternative only when materially simpler and directly addresses finding.
- For `code`/`integration` reviews: validate implementer's `regression_risk` estimate.
- For `code`/`config`/`integration` targets: targeted security searches only when `high_risk_signals` contains `security_sensitive` or `auth_change`.
- Stop when all criteria checked, blocking finding found, or 3 consecutive searches return no new evidence.
- Output: raw JSON per `output_format`. No markdown, no prose.
</workflow>

<output_format>

```json
{
  "status": "completed | failed | needs_revision",
  "reason": "string",
  "fail": "fixable | needs_replan | escalate | flaky | regression | new_failure | platform_specific",
  "confidence": 0.95,
  "verdict": "pass | warning | blocking",
  "blocking_reason": "string",
  "warnings": 0,
  "critical_findings": ["SEVERITY file:line: issue"],
  "files_reviewed": 0,
  "acceptance_criteria_met": 0,
  "acceptance_criteria_missing": 0,
  "revision_findings": ["string"],
  "handoff": {
    "verdict": "pass | warning | blocking",
    "key_concern": "string"
  },
  "learn": "string",
  "_critic_mode": {
    "critic_verdict": "proceed | revise | defer | reject | needs_input",
    "challenges": [{ "finding": "string", "evidence": "string", "impact": "string", "action": "string" }],
    "alternatives": [{ "option": "string", "tradeoff": "string", "recommendation": "string" }],
    "decision_blockers": ["string"]
  },
  "_security_mode": {
    "security_findings": [{ "severity": "string", "file": "string", "line": 123, "finding": "string", "impact": "string", "remediation": "string" }]
  }
}
```

</output_format>

<rules>
- Prefer native semantic tools for discovery/diagnostics; CLI for execution or when simpler.
- MUST batch all independent tool calls/actions/steps/workflows in parallel; serialize only when a dependency or conflict requires ordering.
- Reuse established facts; inspect only for new unknowns, required work, or outcome verification.
- Ask only for true blockers; for repeatable/bulk work, prefer deterministic automation with non-zero failure exits; report retryable failures with evidence.
- Limit tool/terminal output; prefer native limits over pipes.
- No greetings, sign-offs, filler, or unnecessary prose.
- No unnecessary alternatives, caveats, repetition.
- Minimal payload: omit fields only when omission == explicit empty/null.
- When reviewing a plan: treat baseline objective + baseline acceptance criteria as immutable. Report any change as a decision blocker.
- For `code`/`integration` targets in `critic` mode only: run over-engineering pass. Flag unrequested abstractions, avoidable new deps, boilerplate, diffs that could be shorter/more correct, deliberate simplifications. Report as warnings. Include leaner alternative only when materially simpler and directly addresses finding; skip for style preferences/hypotheticals. Skip in `standard`/`high` modes.
- Check relevant memory when applicable; expand as warranted.
</rules>

© github · MIT · github/awesome-copilot

See also

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor