2.5 KiB
status, parent, claimed-by, claimed-at, blocked-by, tags
| status | parent | claimed-by | claimed-at | blocked-by | tags | ||||
|---|---|---|---|---|---|---|---|---|---|
| resolved | 038-implement-skill-map | 019fbb66-80d0-7a01-8ac9-01255adfc7b2 | 2026-08-01T07:38:25-04:00 |
|
|
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.