RedHat Code Review

Review code for correctness, security, performance, and maintainability.

Security Scan

This is an instruction-only code-review skill whose declared capabilities, required resources, and runtime instructions are consistent with its stated purpose and do not request unexpected access.

Purpose & Capability

The name and description (code review for correctness, security, performance, maintainability) match the SKILL.md instructions. The skill is instruction-only and does not request binaries, env vars, or config paths that would be unrelated to code review.

Instruction Scope

SKILL.md clearly describes inputs (scope, intent, constraints) and a bounded review procedure (entrypoints, correctness, security, perf, maintainability) and output schema. It does not instruct the agent to read system files, access unrelated credentials, or transmit data to external endpoints.

Install Mechanism

No install spec or code files are present. Because this is instruction-only, nothing is written to disk or downloaded at install time.

Credentials

No environment variables, credentials, or config paths are required. The skill does not ask for secrets or other sensitive tokens.

Persistence & Privilege

always:false (default) and no special privileges are requested. disable-model-invocation is false (normal), meaning the agent can call the skill when invoked; this is expected for skills and is not flagged alone.

Scan Findings in Context

[no-findings] expected: The regex-based scanner had nothing to analyze because this is an instruction-only skill with no executable code; that is expected.

Assessment

This skill appears coherent and safe in that it only contains instructions for reviewing code and asks for no credentials or installs. Before installing, consider: (1) provenance — the registry owner ID in the manifest differs from the _meta.json ownerId and the source/homepage are missing, so confirm you trust the publisher; (2) data sensitivity — when using the skill, avoid submitting proprietary secrets or sensitive code to any third-party service or agent session unless you trust it; (3) test first — try the skill with harmless sample code to confirm behavior; and (4) metadata oddities — the skill.yml contains a 'System.Object[]' line and the registry owner vs. _meta.json owner mismatch look like metadata/packaging issues (likely harmless, but worth verifying the publisher). If you require a higher assurance of provenance, request a signed or officially published variant with a verifiable homepage or source repository.

SKILL: code-review

Purpose

Analyze code (or a diff) to detect bugs, security issues, performance problems, and maintainability risks, then propose concrete improvements.

When to Use

• Reviewing a PR/diff before merging.
• A bug is suspected but not yet reproduced.
• Hardening/security pass is requested.

Inputs

• scope (required, string): files, diff, or code snippet to review.
• intent (optional, string): what the code is supposed to do.
• constraints (optional, string[]): security/perf/compat constraints.
• risk_tolerance (optional, enum: low|medium|high).

Steps

1. Identify entrypoints, invariants, and trust boundaries.
2. Check correctness:
   • edge cases
   • error handling
   • concurrency/races (if applicable)
3. Check security:
   • input validation
   • authz/authn
   • secrets handling
   • injection risks
4. Check performance and resource usage:
   • hotspots
   • unbounded loops/data growth
5. Check maintainability:
   • naming
   • duplication
   • test coverage gaps
6. Produce a prioritized, actionable report.

Validation

• Findings include concrete evidence (line references, behavior, or reproducible scenario).
• Suggestions are compatible with stated constraints.
• Distinguish “must-fix” from “nice-to-have”.

Output

Review report (example schema):

summary: "<1 paragraph>"
findings:
  - id: "CR-001"
    severity: "high|medium|low"
    category: "bug|security|perf|maintainability"
    issue: "<what>"
    impact: "<why it matters>"
    recommendation: "<how to fix>"

Safety Rules

• Do not claim vulnerabilities without evidence.
• Do not recommend unsafe patterns (e.g., disabling validation to “make it work”).
• Prefer minimal, targeted fixes.

Example

Input:

• scope: “diff for auth middleware”

Output:

• findings include missing audience check on JWTs and a failing negative test case.