/wenlan-capture

name: wenlan-capture
description: "Save a memory to Wenlan in flow, or save something from this conversation as one note when the user asks for a note. Use proactively when the user states a preference, makes a decision, corrects you, or shares a durable fact. Invoked as `/wenlan-capture <content>`."

/wenlan-capture

Capture a single memory in the moment. Active verb: agent captures the moment of insight, like a photograph.

Resolve the active space

The `/wenlan-capture` skill accepts one optional inline token of the form `space:<name>` anywhere in the argument string. The bundled resolver strips it and returns the rest as the content. It prints the resolved Space line itself:

raw_args="<the full argument string passed to /wenlan-capture>"
resolved="$("{{WENLAN_SKILLS_DIR}}/wenlan/scripts/resolve-space.sh" --cwd "$PWD" --args "$raw_args")"
space="$(printf '%s\n' "$resolved" | cut -f1)"
source_layer="$(printf '%s\n' "$resolved" | cut -f2)"
content="$(printf '%s\n' "$resolved" | cut -f3-)"

If `content` is empty, ask the user what they want to capture before calling the tool. Pass `space="$space"` to the `capture` MCP tool only when `space` is non-empty.

The resolver line reports the proposed client context. After capture, relay the tool's returned `space`, `space_source`, and `write_outcome`; those fields describe what the daemon actually persisted and are authoritative.

Unknown spaces are not auto-created. Register one through the resolved CLI binary, or omit `space` to store uncategorized:

W="$(command -v wenlan || echo "$HOME/.wenlan/bin/wenlan")"
"$W" spaces add <space>

Memory or note

Default to one memory. Save a note instead only when the user asks for one in their own words: "save this as a note", "write this up", "存成筆記", "寫成一篇筆記", or `/wenlan-capture` text that starts with "note:". Proactive captures are always memories; never create a note on your own initiative, and never save the same thing as both a memory and a note in one turn. Turning many memories into notes is a different job: that is `/wenlan distill`.

To save a note, follow "Save a note" below and skip the memory steps.

Something from another app or the web

When the user wants to keep something you read in another app or on the web (an email, a Notion or Drive page, a Slack thread, an issue, an article), save the original with `save_source` instead of capturing it. Pass its permanent link as `url`, its title, the text as you read it (not a summary), a `source_label` such as `gmail`, `notion`, `drive`, `slack`, `github` or `web`, and `space` when it is non-empty. Never make up a link: if you have no link to the original, capture the insight as a memory instead. Save only what the user asked to keep; never copy a whole inbox or channel.

The saved copy does not update on its own. When the original changes and the user wants Wenlan to follow, save it again with the same link; notes built on it are then marked for refresh. Report the link and the Space the result names.

How to invoke

Call the `wenlan` MCP server's `capture` tool with the user's content as a complete, self-contained statement. Attach `topic` from cwd or the conversation — don't make the user type it.

capture(content="<args, written as a full sentence with WHY>",
        memory_type="<picked from the 6 types>",
        entity="<primary entity name, if any>",
        entity_type="<person, project, tool, ...>",
        space=<resolved if non-empty>)

Set `memory_type` and `entity` yourself on every capture, whether Steep runs automatically or on demand. You already know both from the conversation, so this is a one-word choice, not extra work; nothing later may classify or link the memory for you.

`memory_type` — agent picks one of 6

Pick the type from the content itself with this mapping:

| Type | Use for | |---|---| | `identity` | Durable facts about the user (role, company, language preference) | | `preference` | "I prefer X because Y" — a habit, a correction, a stylistic choice | | `decision` | "Going with A over B because C" — a specific choice with rationale | | `lesson` | Root cause found, workaround discovered, technical insight earned | | `gotcha` | Sharp edge, surprising behavior, a thing to watch out for | | `fact` | Durable info about people, projects, tools — anchor to `entity` when possible |

If two types fit, pick the one closest to *why the memory matters*. A decision *also* implies a preference, but `decision` is more specific.

`entity` — extract the anchor

Pick the single most important named thing in the content: a person, project, tool, place. Use the exact full name, and say what it is in `entity_type`. Example: "Alice Chen prefers TDD because…" → `entity="Alice Chen", entity_type="person"`. A name the wiki already knows links; a new name is created and linked. If the content has no named anchor, omit both.

When the name matches more than one entity, nothing is stored and the reply lists them with their ids. Capture again with `entity_id` set to the one the user means; when you cannot tell, ask the user, or capture without `entity`.

Space inference

• cwd inside a repo → repo name (e.g. `~/Repos/wenlan/...` → `"wenlan"`).
• Outside configured or registered repo context → omit the client Space and

let the daemon Default decide the write.

• Pass `space` only when scope is known. If uncertain, omit it or inspect the

registered spaces first:

W="$(command -v wenlan || echo "$HOME/.wenlan/bin/wenlan")"
"$W" spaces list

Multiple entities or relations

Ordinary captures stop after `capture`: pass the single most important named anchor through `capture.entity` with its `entity_type`. Do not call `create_entity` for ordinary captures. Never infer a relation the user did not state.

Use the explicit KG tools only when the user explicitly states a durable relation:

1. Call `create_entity` for both named endpoints first and collect their stable