---
name: review-checklist-persistence
description: Review browser-local checklist persistence when completion state is added, changed, or reported as lost after reload.
---

# Review checklist persistence

This independently written teaching example accompanies a fictional checklist task. It is not copied or adapted from Dale's internal prompts or review instructions. Adapt its checks to the application and available tools.

Before using this skill, agree on the review in conversation and provide the task, exact revision and evidence. An independently written example of what a reader could say is: ‘Can you take a separate look at this? Check that the items stay checked after reloading and that Reset stays cleared. Don’t change the code. Show me what you checked and anything you couldn’t verify.’ The checklist below is a reusable written aid, not Dale’s opening words.

1. Read the requested behavior and locate the state, storage, and Reset code. Identify how saved IDs map to current items.
2. Check one item and reload. Confirm its state survives and unrelated items stay unchanged.
3. Reset and reload. Confirm completion state is cleared.
4. Try malformed stored data and unavailable storage. Confirm the checklist remains usable for the current session.
5. Operate the checklist and Reset by keyboard. Check labels and visible focus.
6. Report each check as passed, failed, or not run, with evidence. For a failure, include reproduction steps and the user-visible effect.

Complete the review when every check has a recorded result. Keep missing tool access visible as a not-run result. Stop at the review report unless implementation was also requested.

Bring findings back to the person directing the work. Clarify disputed behavior, return reproducible failures to the implementation session, and review the resulting revision again. A review report does not authorize release. These examples have not been run or tested.