Review Vague Fixes

Review comments are unactionable — "improve this", "handle errors", "refactor" without specifics or suggested alternatives.

Security Scan

This is an instruction-only code-review guidance skill that is internally consistent with its stated purpose and requests no credentials, installs, or unusual access.

Purpose & Capability

The name and description match the SKILL.md guidance: it provides concrete advice for making review comments actionable. There are no unrelated requirements (no env vars, binaries, or installs).

Instruction Scope

SKILL.md contains only guidance for writing review comments and how to point to lines/behaviors; it does not instruct the agent to read sensitive files, exfiltrate data, call external endpoints, or access credentials. The scope stays within review-style recommendations.

Install Mechanism

No install spec and no code files — instruction-only. This is the lowest-risk install model and appropriate for the skill's purpose.

Credentials

The skill declares no required environment variables, credentials, or config paths. That matches the simple, non-integrative nature of the guidance.

Persistence & Privilege

always is false and model invocation is allowed (platform default). There is no request for permanent or elevated presence or to modify other skills or system settings.

Assessment

This skill is low-risk and consistent with its description: it's just prose guidance for producing clearer code-review comments. You can install it without granting secrets or filesystem access. Keep in mind that if your agent is allowed to invoke skills autonomously, it may adopt stricter review behavior when using this guidance — test it on non-sensitive PRs first. If you want different tone or stricter/looser rules, edit the SKILL.md before enabling it.

A review that says "this needs work" without saying what work is a cost on the author, not a contribution. The author has to either guess what the reviewer meant or push back and ask — both eat time and erode trust.

Symptoms

• Comments like "refactor this", "improve error handling", "make this cleaner" with no example.
• Blanket style gripes on a change that was explicitly about functionality.
• "I don't like this" with no reason and no alternative.
• Comments that could apply to any file in the codebase — no specificity to what's in front of the reviewer.

What to do

• Every review comment should state what to change, where, and why. If you can't say why, you probably don't have a concrete objection.
• When you want a refactor, give an example: paste the shape you'd prefer, or point at a similar pattern elsewhere in the codebase.
• Distinguish blocking from nice-to-have. Mark must-fix clearly; leave nitpicks labeled as such.
• Reference the exact line, symbol, or behavior. "In processOrder, the retry loop won't back off" beats "improve this function".
• If you don't know the right fix, say so — "this concerns me because X; not sure what the right answer is" is honest and inviting, unlike a vague demand.