review-manifest-generator

---

name: review-manifest-generator description: Generate a factual code change handoff manifest for reviewers. Use when asked to create a review checklist, review manifest, handoff manifest, or reviewer-oriented change audit. Keywords: review checklist, review manifest, handoff manifest, code change audit, reviewer context, risk checklist.

Review Manifest Generator

Overview

Generate a Markdown "Code Change Handoff Manifest" for another AI assistant or human reviewer.

This skill is for tasks where the user wants a review-oriented artifact that:

• summarizes what the change attempted to do
• audits which files changed and why
• warns that the code may be flawed
• highlights concrete reviewer focus areas and risks

This skill is not for performing the review itself. It is for preparing the reviewer handoff document.

When To Use

Use this skill when the user asks for any of the following:

• "generate review checklist"
• "generate review manifest"
• "write handoff manifest"
• "prepare reviewer notes"
• "create a review清单"
• "generate a code change audit for review"

Do not use this skill when the user is asking for:

• an actual code review with findings
• implementation changes
• a test plan not tied to reviewer handoff

Core Role

Act as:

• an Objective Recorder
• a Technical Auditor

Do not sell the change. State facts conservatively and precisely.

Non-Negotiable Principles

1. Zero-Trust Wording

Never describe the change as definitively correct.

Avoid:

• "fixed"
• "successfully completed"
• "perfectly implemented"
• "resolved"

Prefer:

• "attempted to implement"
• "adjusted logic intending to..."
• "modified..."
• "intended to allow..."
• "attempted to reduce..."

2. Explicit AI Risk Disclaimer

Always state that:

• the code was generated with AI assistance
• the logic may contain hallucinations, flaws, or non-best practices
• the reviewer must independently verify correctness

Do not imply that the implementation is already trustworthy.

Required Inputs

Before writing the manifest, gather enough context to answer:

• What problem was this task trying to solve?
• Which documents were referenced?
• Which files actually changed?
• What are the likely logic, regression, and edge-case risks?

Read only what is needed:

• the user-referenced prompt/plan/progress docs
• the changed files
• any relevant module README files if project rules require them

Save Path Rules

Determine the output file path before writing.

Case A: User provided a destination path

If the user explicitly provides a directory path, save there.

Filename format:

manifest_TOPIC_{DATE}.md

Example:

/some/path/manifest_selection-validator_2026-03-13.md

Case B: User did not provide a destination path

If no output path is provided:

• find the task's progress, plan, requirements, or handoff document
• save the manifest in that same directory

Filename format:

manifest__TOPIC_{DATE}.md

Example:

docs/plan/y2026/m02-some-task/manifest__interactive-priority_2026-03-13.md

Required Output Contract

When responding to the user after generating the manifest:

1. Output the determined File Save Path first.
2. Then provide the Markdown body, or if you already wrote the file, state clearly that the manifest was generated at that path.

Do not add pleasantries.

Manifest Structure

Use this exact high-level structure.

1. Change Context

Include:

• Related Documents: list documents referenced during the task
• Task Objectives: brief description of what the task attempted to solve

2. File Change Audit

Use a table:

File Path	Change Type	Objective Description

Rules:

• Change Type should usually be Add, Mod, or Del
• Objective descriptions must be concrete and factual
• Do not merely restate the filename

3. AI Generation Disclaimer & Risk Warnings (AI Disclaimer)

Always include a reviewer warning block similar to:

Important Note for Reviewer: The code in this submission was generated by an AI assistant based on documentation and local code inspection. Do not assume the code logic is correct.

Then add a reviewer checklist.

Minimum required checklist items:

• Logical Consistency
• Side Effects
• Edge Cases

Add task-specific risk points when relevant, such as:

• propagation/event-order semantics
• state synchronization
• overlap cleanup
• auth/session behavior
• database transaction boundaries
• concurrency/race conditions
• browser compatibility
• detached DOM / SPA lifecycle behavior

Writing Guidelines

Related Documents

List only documents actually read or directly used.

Typical examples:

• PRD
• tech spec
• progress doc
• handoff prompt
• module README

Task Objectives

Keep this section short.

Good example:

• "This task attempted to adjust selection validation so a new selection is blocked only when fully contained by one existing translation range."

Bad example:

• "This task fixed the bug and made the feature work."

File Change Audit

Write one row per changed file that matters to the reviewer.

Good row:

| src/feature/validator.ts | Mod | Replaced endpoint-based selection blocking with a boundary-based containment helper intended to allow partial overlap while still blocking full containment. |

Bad row:

| src/feature/validator.ts | Mod | Updated validator. |

Risk Checklist

Make the checklist specific to the change.

Good:

• Propagation Semantics: Verify that skipping stopPropagation() on weak-interactive targets does not create duplicate or surprising host-page behavior.

Bad:

• Check code quality.

Workflow

Follow this sequence:

1. Identify the task directory or explicit save destination.
2. Read the task prompt/plan/progress docs.
3. Read the changed files relevant to the implementation.
4. Infer the intent conservatively from the documents and code.
5. Write the manifest using zero-trust wording.
6. Save it to the chosen path.
7. Report the file save path to the user.

Example Output

File Save Path: /workspace/docs/plan/task-x/manifest__selection-containment_2026-03-13.md

# Code Change Handoff Manifest

## 1. Change Context

- **Related Documents**:
  - `docs/plan/task-x/handoff-prompt.md`
  - `docs/plan/task-x/PROGRESS.md`
  - `src/module/README.md`
- **Task Objectives**:
  - This task attempted to adjust selection containment logic so a new selection is blocked only when fully contained by one existing active range.

## 2. File Change Audit

| File Path | Change Type | Objective Description |
| :--- | :--- | :--- |
| `src/module/selectionValidator.ts` | Mod | Replaced a point-based containment heuristic with a Range boundary comparison intended to allow partial-overlap selections while still blocking exact containment. |

## 3. AI Generation Disclaimer & Risk Warnings (AI Disclaimer)

> **Important Note for Reviewer**:
> The code in this submission was generated by an AI assistant based on documentation and local code inspection. **Do not assume the code logic is correct.**

You need to prioritize reviewing the following potential risk points:

- [ ] **Logical Consistency**: Verify that exact-equality selections are still treated as contained.
- [ ] **Side Effects**: Check whether the validator change alters icon-trigger and double-click behavior unexpectedly.
- [ ] **Edge Cases**: Test cross-node selections, detached DOM nodes, and compareBoundaryPoints failure cases.
- [ ] **Overlap Interaction**: Confirm partial-overlap selections proceed and are later cleaned up by the overlap detector.

Quality Bar

A good manifest is:

• factual
• conservative
• reviewer-centered
• specific about risks
• short enough to scan quickly

A bad manifest:

• markets the change
• assumes correctness
• omits risks
• gives vague file descriptions
• ignores reviewer verification responsibility