requesting-code-review

Files (1)

• SKILL.md

SKILL.md (first lines)

# HOTL Requesting Code Review

## Lifecycle

Executors invoke `requesting-code-review` at defined checkpoints. This skill dispatches the `code-reviewer` agent with structured context. Returned findings are handled by `receiving-code-review`.

## Precondition

Only request review when the checkpoint work is in a reviewable state and its planned verification has completed. Do not request review for code that has failing required verification unless the purpose of the review is to diagnose the failure.

## When to Request Review

### Mandatory Triggers

- **executing-plans:** After each 3-step batch boundary
- **subagent-execution:** After meaningful delegated implementation batches (3+ completed implementation steps, or cross-module change, or high-risk/user-facing/shared-infra change)
- **All executors:** Before final completion (claiming done, merging, or creating a PR)

### Conditional Triggers

- **loop-execution:** At intermediate gates only when the change is high-risk, cross-module, or feature-scale. Always at final completion.
- **Ad-hoc development:** Before merge to main. Optionally when stuck or before a large refactor.

### When NOT to Request

- After trivial single-step changes (typo, config value, import fix)
- Mid-loop iterations that haven't reached a gate
- When the same code was already reviewed and hasn't changed since
- Do not request a second full review when a scoped follow-up review is enough

## Review Base (Deterministic)

The review base defines the git range for the reviewer. Executors record this before starting each reviewable batch.

- **Batch review:** `git rev-parse HEAD` recorded by the executor before starting the batch
- **Final review:** Branch point or last recorded review base, whichever is more recent. A final review is required unless the most recent review already covers all current changes and no code changed afterward.
- **Follow-up review:** `HEAD` immediately before the fix. Re-review only the changed scope unless the fix affects shared architecture, risk level, or multiple modules.

## Dispatch Template

When dispatching the `hotl:code-reviewer` agent, provide this context:

```
Review the following implementation work.

**Review type:** checkpoint | final | follow-up | direct
**Workflow:** {workflow_file} (or "No workflow — reviewing against stated intent")
**Steps reviewed:** {step_range} (or "N/A")
**Git range:** {review_base}..{HEAD_SHA}

**Intent contract:**
- intent: {intent}
- constraints: {constraints}
- success_criteria: {success_criteria}
- risk_level: {risk_level}
(or "No formal contract — review against stated intent and general correctness/risk")

**Implementation summary:**
{summary}

**Changed files:**
{git_diff_stat}

**Verification evidence:**
- Commands run: {verification_commands}
- Outcomes: {pass_fail_status}
- Known gaps: {limitations}

Review against the workflow plan and HOTL contracts (if provided),
or against the stated intent and general correctness/risk.
Produce findings with file:line references.
```

## Acting on Results

1. Invoke `receiving-code-review`
2. Follow Verify → Evaluate → Respond → Implement
3. If any accepted BLOCK finding requires re-review after fix, dispatch a scoped follow-up review
4. Do not proceed past the checkpoint until all BLOCK findings are resolved

## Review Types

- **checkpoint** — executor mid-run at a batch boundary (uses PROCEED/HOLD verdict)
- **final** — executor completing a governed workflow run (uses READY/NOT READY verdict)
- **follow-up** — scoped re-review after fixing BLOCK findings
- **direct** — user-invoked review via `hotl:code-review` (uses READY/NOT READY verdict). Findings are returned to the user without automatically invoking `receiving-code-review`.

From yimwoo/hotl-plugin, MIT.

More from yimwoo/hotl-plugin