| 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:
- Output the determined File Save Path first.
- 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:
Bad:
Workflow
Follow this sequence:
- Identify the task directory or explicit save destination.
- Read the task prompt/plan/progress docs.
- Read the changed files relevant to the implementation.
- Infer the intent conservatively from the documents and code.
- Write the manifest using zero-trust wording.
- Save it to the chosen path.
- 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