# Project Forge Review

> Perform an independent adversarial review of an integrated game or software project using reproducible runtime, visual, interaction, accessibility, determinism, and performance evidence. Use after a Project Forge slice enters review, before accepting a baseline, or when a project looks complete but its quality claims have not been independently verified.

- Skill: `moinsen-dev/project-forge-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add moinsen-dev/project-forge-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/moinsen-dev/project-forge-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- License: MIT
- Author: moinsen-dev (https://skillmd.com/u/moinsen-dev)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/moinsen-dev/project-forge-review

---


# Project Forge Review

Review the integrated result, not an implementer's summary. Be demanding,
specific, reproducible, legally distinct, and honest about unavailable evidence.

Read [references/critic-protocol.md](references/critic-protocol.md) before
reviewing.

## Independence Check

Record:

- reviewed slice and revision,
- whether this context authored any reviewed code,
- available runtime and capture capabilities,
- required gates,
- missing evidence.

If this context authored the implementation, do not issue final approval.
Perform a useful self-review, label independence `limited`, and require another
reviewer for acceptance.

## Review Workflow

1. Read the project contracts and current assignment.
2. Inspect the worktree and identify the exact reviewed revision.
3. Build and run the integrated product.
4. Exercise the real player, user, or request path.
5. Reproduce every required named review state.
6. Inspect console, server, lifecycle, and failure behavior.
7. Review deterministic captures at representative viewports.
8. Inspect motion, audio, and timing when relevant.
9. Profile active worst-case scenarios when required.
10. Perform a blind A/B comparison when legal references are available.
11. Rank defects by severity and player or user impact.
12. Return `PASS`, `REWORK`, `BLOCKED`, or `UNVERIFIED`.

Do not edit the reviewed subsystem silently. The lead may explicitly assign a
separate correction slice after the report.

## Findings

Every finding must include:

- severity: `critical`, `high`, `medium`, or `low`,
- observable symptom,
- exact reproduction,
- evidence path or metric,
- likely owning subsystem,
- root-cause hypothesis clearly labeled as a hypothesis,
- observable closing condition.

Aggregate repeated symptoms when one root cause explains them.

## Verdict Rules

Return `REWORK` while any critical or high finding remains.

Return `UNVERIFIED` when a required claim lacks evidence or the environment
cannot capture it.

Return `BLOCKED` only for a real external constraint after meaningful available
review work is exhausted.

Return `PASS` only when:

- all required states were exercised,
- evidence belongs to the reviewed revision,
- all applicable gates pass,
- no critical or high defect remains,
- originality and legal-distinctness checks pass,
- residual risks are explicit.

## Rework Loop

After corrections:

1. Rebuild the integrated product.
2. Reproduce the original defect.
3. Capture fresh evidence.
4. Rerun affected neighboring states.
5. Update rather than erase the finding history.
6. Issue a new verdict.

Do not lower the threshold because several iterations were required.

## Output

Write or return a report using the schema and template in
[references/critic-protocol.md](references/critic-protocol.md). Keep evidence
status distinct from subjective scoring.