/curate

name: curate
description: >
  Power-user audit of Wenlan's pending surfaces: show pending revisions
  (conflicts/merges) for the person to accept in the Wenlan app, dismiss the
  ones they turn down, or audit pending captures (not yet confirmed).
  Most users want `/brief` for revisions; that handles the daily flow. Use
  `/wenlan curate` only for explicit deep-walk audits after bulk imports, or to walk
  the full queue rather than the top 3 shown in /brief.
  Invoked as `/wenlan curate captures`, `/wenlan curate revisions`, or `/wenlan curate refinements`.
argument-hint: "captures | revisions | refinements"
allowed-tools: ["Bash", "AskUserQuestion", "mcp__plugin_wenlan_wenlan__list_pending", "mcp__plugin_wenlan_wenlan__confirm_memory", "mcp__plugin_wenlan_wenlan__forget", "mcp__plugin_wenlan_wenlan__capture", "mcp__plugin_wenlan_wenlan__recall", "mcp__plugin_wenlan_wenlan__list_refinements", "mcp__plugin_wenlan_wenlan__reject_refinement"]
user-invocable: false

/wenlan curate

Power-user audit lever. Most users do not need /wenlan curate in daily flow:

• **Pending revisions** surface in `/brief` automatically (top 3; the person accepts them in the Wenlan app).
• **Pending captures from this session** surface in `/handoff`'s preview block (top 3).
• **Orphan wikilinks** can be inspected while steep processes a requested knowledge arrangement; they are not pending revisions.

Use /wenlan curate only when you want the deep walk those skills intentionally do not force.

**Only the person accepts a card, in the Wenlan app.** A pending revision or a review proposal is a card. You never accept one: the daemon refuses an accept from any AI tool, and so does the `wenlan` CLI. Show the cards, tell the person they wait in the app, and dismiss or reject one only when the person says so.

**Captures are meant to decay.** A capture lands pending (not yet confirmed) and, if nothing ever conflicts with it, it quietly fades — that is by design, not a backlog you owe the system. The only items that *need* a human are genuine conflicts (a contradiction, or a richer re-capture worth merging); those surface as pending revisions. `/wenlan curate captures` is an **opt-in audit** for when you *want* to seal a batch (e.g. after a bulk import), not a daily chore to zero out.

Decide in native cards, not prose

Walk the queue with `AskUserQuestion` — the same native picker `/wenlan pages` uses. **Never narrate items one-by-one in chat prose.** A card is a real decision; prose is a wall of text the user has to reply to by hand.

`AskUserQuestion` takes **up to 4 questions per card** (one per item) and **2-4 options** each, plus an auto "Other" free-text slot. So batch the queue in groups of ≤4:

1. List the pending items (per section below). 2. Take the next ≤4. Build ONE `AskUserQuestion` call:

• one **question** per item — `question` is the item's content, trimmed to ~1-2 lines.
• `header`: a short tag, ≤12 chars (the memory type, or `Revision 3`).
• `options`: the actions for that section (below).
• The card always adds an "Other" slot.

3. Apply each answer (below), then repeat with the next ≤4 until the queue is empty. 4. Cancel / close the card = **no mutation**. "Skip" is the safe per-item escape.

`/wenlan curate revisions` (and bare `/wenlan curate`) → via the `wenlan` CLI

Revisions go through the **CLI**, not MCP — no deferred-tool round-trip, so the picker comes up fast. Resolve the binary once, then list:

W="$(command -v wenlan || echo "$HOME/.wenlan/bin/wenlan")"
"$W" --format json curate

That prints a JSON array; each element is ONE logical revision (the CLI already groups the per-chunk rows and joins their text, so you never see a mid-sentence fragment):

• `revision_source_id` — the staged revision; the **action key** for dismiss.

Keying on this (not the target) means the *named* revision is acted on even when several compete for one memory.

• `target_source_id` — the memory this revision would replace (context only).
• `content` — the full revised text.
• `source_agent` — who proposed it (or `null` = daemon).
• `original` — the current text the revision would replace (`null` if unavailable).
• `diff` — a card-ready, length-bounded `OLD:` / `NEW:` preview of what the

revision would replace (two labeled lines, original then revision, each clipped). `null` when `original` is unavailable.

**Read the JSON straight into the card — in one step, no shell tooling.** Each element's `content` is the card question (trim to ~1–2 lines inline as you write it); `revision_source_id` is the action key. Parse the array yourself — do not pipe it through `jq`/`python`/`awk` to reshape first. That extra round-trip is what makes the picker feel slow (each retry is a model turn) and is failure-prone (quoting, sandboxed temp paths); the model reads JSON natively, so go from CLI output to card directly.

**Show the diff so the user isn't deciding blind.** Put `diff` verbatim into the `preview` field of the **Leave for the app** option — `AskUserQuestion` renders `preview` in a monospace box and switches to a side-by-side layout, so it reads like a git diff. If `diff` is `null`, omit the preview and keep `content` as the question. Don't reformat the diff — it's already card-ready and length-bounded for the picker.

Walk it as native cards (≤4 per card). Per revision, options:

• **Leave for the app** → nothing: it keeps waiting in the Wenlan app, where the

person accepts it. (carries the `diff` preview)

• **Dismiss** → it was NOT an edit: unstage the false revision link and keep BOTH

memories as independent rows. (Non-destructive — nothing is deleted. To delete a genuinely unwanted capture, use `/wenlan curate captures` → Reject.)

After the card returns, apply the picks in ONE Bash call (Leave for the app runs nothing):

"$W" curate dismiss <revision_source_id>     # for each Dismiss

If the array is empty, say so in one line ("Nothing needs you — no pending co