Add artifact vault contents

projects/skills/053-implement-skill-review-validation-grill.md

@@ -0,0 +1,43 @@
+---
+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.