---
status: resolved
parent: "[[038-implement-skill-map]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-08-01T07:38:25-04:00"
blocked-by:
  - "[[039-implement-skill-old-workflow-research]]"
  - "[[042-implement-skill-no-mistakes-research]]"
  - "[[078-implement-skill-matt-code-review-research]]"
tags:
  - ticket/grill
---

# Implement workflow review skill contract grill

## Question

What should the packaged review skill be named, and what standalone review contract should it expose?

## Resolution

The packaged review skill should be named `review`.
The previous conflict with Claude Code built-ins does not apply to this packaged workflow.

`review` should preserve agent flexibility rather than overprescribing a rigid mode taxonomy.
It reviews the change set the agent selects from current context, such as uncommitted changes, branch changes, a PR, explicit files, or another clear source.
It states what change set it selected before reviewing, and asks or stops only when the scope is ambiguous enough that a trustworthy review cannot proceed.

`review` produces a structured review report, not a gate artifact and not a pass/fail verdict.
The report should cover Risk, Standards, Intent, Evidence, and Documentation when those dimensions apply.
The skill may run targeted checks when useful, but it remains report-only and does not edit code.

The skill should use independent dimension reviewers when the runtime supports subagents or isolated workers, with a single-agent fallback that preserves separate sections.
Reviewer prompt files should live under the skill directory, for example `skills/review/reviewers/`.
Each reviewer file should be self-contained about its purpose, boundary, rubric, and output expectations.
The top-level `SKILL.md` should orchestrate input capture and aggregation without overdefining each reviewer’s judgment.

Findings should use a flexible shared base schema with dimension-specific additions where useful.
The base shape includes severity, blocking yes/no, location, finding, why it matters, and suggested fix.
Reviewers classify findings as blocking or non-blocking, while the caller or user decides final disposition.

Intent handling should remain flexible.
The reviewer may use a Wayfinder task, issue, spec, direct request, branch context, or other available context as intent source when relevant, but `review` itself should not know about or mutate implementation lifecycle, Wayfinder claiming, task resolution, PR creation, or ticket closeout.