44 lines
2.5 KiB
Markdown
44 lines
2.5 KiB
Markdown
---
|
||
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.
|