Confessions of
an AI Vampire

# Example plan: remember a completed checklist

An independently written teaching example for a fictional, browser-local checklist task. It is not copied or adapted from Dale's internal prompts and does not reconstruct his voice conversations or the sequence of a real task. Adapt it to a small app you can safely change.

## Start with a conversation

In a disposable copy of a small checklist app, you could say:

> I keep losing my checkmarks when I reload this app. Can we make them stay checked, and have Reset really clear them? Just on this device. Look at how it works first, tell me what you find, and ask me about anything that's unclear.

After the agent reports back, talk through its proposed approach. You could ask it to write a plan like the example below. Check that the plan matches what you meant before asking it to implement anything. This spoken example and plan are fictional, independently written and untested.

## Outcome
After a reload, checked items stay checked in the same browser. A Reset button clears the saved completion state.

## Boundaries
Use the app's existing UI and test tools. Keep data on this device; accounts and server sync are outside this task. If storage is unavailable, the checklist must still work for the current session.

## Before editing
Find the checklist state, item IDs, and existing tests. Explain where persistence belongs and how removed or renamed items will be handled. Ask about any decision that changes the requested behavior.

## Work
1. Save completion state using stable item IDs and a versioned storage key.
2. Restore valid state on load; recover safely from malformed saved data.
3. Add Reset with a clear accessible label.
4. Check the result in the browser and add focused tests where they catch likely regressions.

## Evidence of completion
- Check an item, reload, and confirm it remains checked.
- Reset, reload, and confirm the saved completion is cleared.
- Corrupt or block storage and confirm the checklist remains usable.
- Use the controls by keyboard and confirm focus is visible.

## Handoff
Report changed files, checks and their actual results, remaining limitations, and any decisions needing human review. Stop after the agreed task and handoff; further features are a separate decision.

## Keep steering after the handoff

Review the demonstration and the actual check results. If the agent misunderstood something, explain the behavior you expected and ask it to update the plan and evidence. For example: ‘Reset clears the screen, but after another reload the checkmarks come back. Can you check that second reload too?’ That is an invented teaching example, not an observed bug. Review the new revision before making a release decision.

---
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.