Fact based code review

Skill RobinGru/AgentSkillForge/skills/fact-based-code-review

Portable, reusable instruction packages for AI coding assistants.

Install

npx -y skills add RobinGru/AgentSkillForge --skill fact-based-code-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Review a concrete code change by tracing its relevant effects and separating observed defects, risks, missing facts, and preferences. Use when a diff or changed files can be inspected.

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.3 KB, as published. Nobody here has run it

Fact-based code review

Use the repository's established language and conventions for any artifacts you create or update.

Review a proposed change against its intended behavior and the facts available in the repository. Do not turn unknown context into a forced approval or rejection.

Use this skill when

A diff, patch, pull request, or changed-file set is available.
The change needs an integration decision or actionable findings.
Tests, configuration, interfaces, or runtime effects can be inspected.

Do not use this skill when

No concrete change is available.
The request is to implement rather than assess a change.
The primary question is a measured performance investigation.

Workflow

1. Scope

Record supplied files or diff, available specification or issue, existing tests, and checks that can actually run. State any missing review context.

2. Reconstruct intent

Identify intended behavior change, contracts that should remain stable, affected users or systems, and success criteria. If intent cannot be inferred, record the review as blocked rather than inventing a verdict.

3. Trace change effects

Follow only paths relevant to the change:

public interfaces and callers;
added, removed, or transformed data;
side effects and persistence or migration paths;
failures and recovery behavior;
authorization boundaries;
runtime or resource impact.

Do not apply irrelevant lenses by default.

4. Classify supporting details

Label each claim with one status:

Observed: directly present in code, configuration, or supplied artifact.
Reproduced: demonstrated by an executed test or controlled run.
Required: imposed by the stated contract or authoritative requirement.
Inferred: reasoned from available facts but not directly observed.
Unverified: cannot be confirmed with available information.

5. Write findings

Use a finding only when it has a location or a precisely bounded missing context. Classify type as Defect, Risk, Missing information, Maintainability concern, or Preference. Use severity Blocker, Major, Moderate, or Minor. Preferences cannot block integration.

### [Severity] Title

- Type:
- Location:
- Supporting details:
- Affected behavior:
- Impact:
- Confidence:
- Recommended correction:
- Verification:

Set confidence to High, Medium, or Low. Mark unexecuted checks as unverified.

6. Decide

Choose one decision:

APPROVE: the facts support integration and no blocking finding remains.
COMMENT: observations or suggestions do not require a change.
REQUEST CHANGES: a supported defect, risk, or missing information requires action.
BLOCKED: required intent or review context is unavailable.

Output contract

Return sections named Scope, Intent, Facts considered, Findings, Checks not run, and Decision. Every finding must include all template fields. The decision must name its factual basis and remaining uncertainty.