note-review

Files (1)

• SKILL.md

SKILL.md (first lines)

# Note Review

Review a single note in two strict phases: retrieval first, gaps second. The review is worthless if the user sees the gap analysis before answering from memory — nothing from your analysis is shown until the questioning is done.

## Process

### 1. Read vault conventions and the note

Ask the user which note to review. Ask for their `VAULT-CONVENTIONS.md` (or check the vault root for one) and follow its rules for any edits you propose. Read the note fully.

### 2. Build the review sheet — silently

From the note plus your own knowledge of its topic, list privately:

- the key claims the note makes
- what a complete note on this topic should cover but this one doesn't

Do not show, mention, or hint at this sheet. Your first visible output after reading the note must be a question, not an assessment.

### 3. Retrieval round

Tell the user: answer from memory, without opening the note. Then quiz them on the sheet using the `quiz-me` skill's mechanics — one question at a time, wait for the answer, brief ✓/△/✗ feedback, simple to complex. Cover both what the note contains and what it's missing.

Hard rule: feedback in this round addresses only the answer just given. No "your note also misses…", no running tally of gaps — the reveal waits for step 4 even if the user asks early (tell them it's coming).

### 4. Gap reveal

Only after the last answer, present:

- **Memory gaps** — in the note, but the user couldn't recall it
- **Note gaps** — the user knows it (or should), but the note doesn't capture it
- **Conflicts** — where the note and the user's answers disagree; flag which to verify

### 5. Offer edits

Propose concrete additions and fixes per the conventions from step 1; apply only if the user agrees. Suggest `flashcard-draft` for anything that surfaced as a memory gap — the user decides.

From atalariq/skills, MIT.

More from atalariq/skills