/import-claude-context

name: import-claude-context
description: "Bring the owner's Claude Code history into Sutando: index, extract and haiku-summarise the stock ~/.claude/projects transcripts, stage the result, show the owner a digest and — only on their 'bring it in' — land it in core memory, notes/claude-import/ and People payloads. Triggers: 'import my Claude history', 'read my Claude Code sessions', 'bring my Claude context along', 'what did I work on in Claude Code', and the review replies 'bring it in' / 'bring in <slug>' / 'forget <slug>' / 'include <date>' / 'include personal' / 'hold <date>' / 'forget <date>'. Personal sessions are held back and never quoted; people the store already has are updated, never overwritten. Read-only on ~/.claude; conversation text only; transcripts are processed by Anthropic's Claude API, the provider the Sutando already runs on, which does not train on them. Nothing is uploaded to s.space except the people you approve in the digest, which are saved to your People store."
user-invocable: true

Import Claude context

Sutando starts out knowing the owner's projects, decisions, open threads and people by reading the conversations they already had with Claude Code. The transcripts under the **stock** `~/.claude/projects/` (`claude_home_path("projects", vanilla=True)` — never Sutando's relocated `.claude-sutando`) are indexed without a model, the dialog is cleaned and redacted on disk, cheap-model subagents summarise it, the result is **staged** and shown to the owner as a digest, and only their "bring it in" moves it into the Sutando-owned sinks.

**Usage**: `/import-claude-context [--projects a,b] [--session uuid] [--since 30d] [--dry-run] [--counts-only] [--json] [--new] [--cloud] [--stage [--known-people file]] [--commit] [--discard] [--forget slug] [--include date|uuid] [--include-personal] [--hold date|uuid] [--forget-session date|uuid] [--purge-dumps]`

When it runs

1. **Owner ask** (any install, standalone or desktop) — the owner says "import my Claude history", "read my Claude Code sessions", the Settings button's sentence *"Import my Claude Code history, consented in Settings at <ISO>."*, or invokes `/import-claude-context`. Same procedure with `--run-kind user`. 2. **s.space desktop onboarding** — the owner's first-contact DM message carries the import request when they consented on the onboarding card: *"Hi — I'm all set up, say hello. Then import my Claude Code history: I consented on the onboarding card at <ISO>, found N conversations across M projects."* The trigger is an owner message containing **"import my Claude Code history"** together with **"consented on the onboarding card"**, both **case-insensitively** — the standalone form below opens the sentence, so it capitalises "Import" (`classify.py`'s `IMPORT_TRIGGER_SENTENCES` already matches case-insensitively; this keeps the documented rule and the classifier in step). **Match the phrase, not the `at`:** the consent time follows it as `at <ISO>` only when the client recorded one, and as `(time not recorded)` when it did not — a consent captured before the client stored a timestamp is stated, never invented, so a trigger keyed on `at` stops matching exactly those installs. The counts clause is optional the same way. The request also arrives **standalone, without a greeting**, when the card consent was given but its first-contact message already went out: *"Import my Claude Code history, consented on the onboarding card at <ISO>, found N conversations across M projects."* — same case, same `--run-kind onboarding`. Run the procedure below with `--run-kind onboarding`; the message's counts are the card's file count, the acknowledgement uses the index's `conversations` (step 2). **Legacy / fallback:** an earlier desktop wrote the same request as its own task file — `channel_id: onboarding-wizard`, `user_id: onboarding-wizard`, `access_tier: owner`, `priority: low`, body "Run the import-claude-context skill (onboarding run). Consent given on the onboarding card at <ISO> …" — and installed clients may still do so; treat that task exactly as this case (it is consented; `priority: low` orders it after a pending greeting and defers nothing — see `src/task_priority.py`). Its result is `[no-send]` (the wizard channel has no delivery path). A queued import task is never left in `tasks/` for a later turn: `/task-orphan-check` step 3a keeps a started one out of the recovery DM (a started run whose `status.json` has not moved for an hour is listed there as stalled, and still resumes on the next sweep), but only this procedure starts it. 3. **Review reply** — while `$DATA/staged/review.md` exists, an owner message saying **"bring it in"**, **"bring in <slug>"**, **"forget <slug>"**, **"include <date>"**, **"include personal"**, **"hold <date>"** or **"forget <date>"** answers the pending review: run the matching command from step 10 and nothing else. Any other message is not an answer; the set stays staged. The owner may ask what a held session was about: answer in the owner DM only, on request, from the summary — answering does not include it.

This skill is part of the engine and needs nothing from s.space: a standalone Sutando (an OSS install with no desktop app) has cases 1 and 3, where the owner asks in whatever channel they talk to their Sutando in — "DM" below means that owner channel. Case 2 is only how the s.space desktop's onboarding card and Settings button reach the same procedure with the same consent.

In cases 1 and 2 the import is a **background job**: the triggering message gets its reply (case 2: the hello plus one line that the import has started; case 1: the acknowledgement text of step 2 as the reply itself, no separate proactive file), and everything after that — the digest, a failure note — is a proactive message to the owner DM (`results/proactive-<ts>.txt`). The legacy task file's own result is `[no-send]`, with the acknowledgement as a proactive message. The owner's answer (case 3) ar