@lumoai/cli 1.25.1 → 1.27.0

package/assets/skill/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lumo
-description: 'Use the Lumo CLI to work with Lumo (project management for dev teams) from the terminal: load task context, bind/wrap Claude Code sessions, and create/update/list/show/comment on tasks, projects, milestones, sprints, documents, artifacts, Figma links, dependencies, and team memory — plus acceptance criteria, machine verification (verify / task status), lineage audit, worktree scaffolding, and CLI setup/auth/update. Activate when the user mentions a Lumo task identifier (LUM-N) or the lumo CLI; asks to load task background or bind/check/wrap a session; manages any of the resources above in Lumo; is starting, resuming, or about to claim completion of a task; or asks what to work on next. Key triggers: "LUM-", "lumo", "task context", "session attach", "session wrap", "验收", "verify", "task status", "milestone", "里程碑", "sprint", "冲刺", "文档", "记忆", "memory", "依赖", "deps", "lineage", "worktree", "下一个任务", "what should I work on", "设计稿", "验收标准", "机器验收", "恢复任务".'
+description: 'Use the Lumo CLI to work with Lumo (project management for dev teams) from the terminal: load task context, bind/wrap Claude Code sessions, and create/update/list/show/comment on tasks, projects, milestones, sprints, documents, artifacts, Figma links, dependencies, and team memory — plus acceptance criteria, machine verification (verify / task status), lineage audit, worktree scaffolding, and CLI setup/auth/update. Activate when the user mentions a Lumo task identifier (LUM-N) or the lumo CLI, in any language; asks to load task background or bind/check/wrap a session; manages any of the resources above in Lumo; is starting, resuming, or about to claim completion of a task; or asks what to work on next. Key triggers: "LUM-", "lumo", "task context", "session attach", "session wrap", "verify", "task status", "acceptance criteria", "milestone", "sprint", "docs", "memory", "deps", "lineage", "worktree", "design link", "what should I work on", "resume task".'
 ---
 
 ## Prerequisites
@@ -26,7 +26,7 @@ The command catalog below is a **map**: it lists every command grouped by domain
 | `task create/update/list/show/comment`, `next`                                    | [references/tasks.md](references/tasks.md)                     |
 | `task artifact*`, `task figma*`                                                   | [references/artifacts-figma.md](references/artifacts-figma.md) |
 | `task criteria set/list`, drafting the acceptance contract                        | [references/criteria.md](references/criteria.md)               |
-| `verify`, `task status` — machine verification loop, claim-done flow, 自查/恢复   | [references/verify.md](references/verify.md)                   |
+| `verify`, `task status` — machine verification loop, claim-done flow, self-check/resume | [references/verify.md](references/verify.md)                   |
 | `project list`, `milestone*`                                                      | [references/milestones.md](references/milestones.md)           |
 | `doc*`                                                                            | [references/docs.md](references/docs.md)                       |
 | `sprint*`                                                                         | [references/sprints.md](references/sprints.md)                 |
@@ -64,19 +64,19 @@ The command catalog below is a **map**: it lists every command grouped by domain
 
 **Task dependencies**
 
-- `lumo task deps list <id>` — list dependency edges in both directions, grouped CONFIRMED / SUGGESTED(待确认) / DISMISSED; each row shows a short edge id `[xxxxxxxx]`, the other task, and detected evidence (`shared_files(N 个共享文件: …)` / `task_mention(…)`); SUGGESTED rows include a copy-pasteable confirm hint
+- `lumo task deps list <id>` — list dependency edges in both directions, grouped CONFIRMED / SUGGESTED (pending confirmation) / DISMISSED; each row shows a short edge id `[xxxxxxxx]`, the other task, and detected evidence (`shared_files(N shared files: …)` / `task_mention(…)`); SUGGESTED rows include a copy-pasteable confirm hint
 - `lumo task deps add <id> --blocked-by <LUM-N>` — declare a manual hard dependency (created CONFIRMED, source MANUAL; if a SUGGESTED/DISMISSED edge already exists in the same direction, it is confirmed in place rather than creating a new row)
 - `lumo task deps confirm <id> <edge> [--reverse]` — confirm a detected candidate; `<edge>` is a short edge-id prefix (≥6 chars) or the other task's identifier (case-insensitive); `--reverse` flips the direction when the detector guessed it backwards
 - `lumo task deps dismiss <id> <edge>` — dismiss a candidate (never re-suggested)
 - `lumo task deps rm <id> <edge> --yes` — delete an edge (refuses without `--yes`)
 - On an ambiguous/unknown `<edge>` selector the CLI prints all candidates with short ids and exits 1 — retry with one of them
 
-**Acceptance criteria（验收合约）** — see [criteria.md](references/criteria.md)
+**Acceptance criteria (contract)** — see [criteria.md](references/criteria.md)
 
 - `lumo task criteria set <task> --file <criteria.json> [--human] [--cause <tag>]` — submit the whole contract: default = initial agent draft (AGENT_DRAFT, locked once submitted); `--human` = a HUMAN_EDIT revision transcribed from the conversation (desired final list; items with `id` keep/update, missing ones are deleted); `--cause` (with `--human`) annotates why the contract drifted: `NEW_INFO | SCOPE_CHANGE | DRAFT_BLIND_SPOT | GRANULARITY | OTHER`
 - `lumo task criteria list <task>` — print the contract (id, MACHINE/HUMAN, provenance source@round, checkpointer)
 
-**Verification（机器验收循环）** — see [verify.md](references/verify.md)
+**Verification (machine acceptance loop)** — see [verify.md](references/verify.md)
 
 - `lumo verify [task] [--timeout <seconds>]` — run every MACHINE criterion's checkpointer locally, report one structured PASS/FAIL verdict per criterion to the server, print next actions. Defaults to the session-bound task. Round cap 3: an all-pass round moves the task to IN_REVIEW (agent stops there); a round-3 fail escalates to a human (stop retrying). **Run this before claiming a task is done.**
 - `lumo task status [task] [--json]` — read-only acceptance self-check (no LLM, milliseconds): the contract with each criterion's latest verdict (REVIEW_ADDED provenance visible), verification history, current round, last round's failure reasons, and `nextActions` = the unmet criteria (the declarative "what's next" — no separate plan). Defaults to the session-bound task; `--json` emits a versioned payload (`version` field). **Run it first when resuming a task in a new session or after a verification round was rejected.**
@@ -98,6 +98,8 @@ The command catalog below is a **map**: it lists every command grouped by domain
 **Documents** — see [docs.md](references/docs.md)
 
 - `lumo doc create/update/show/list/delete` — document CRUD
+- `lumo doc show <doc> --raw` — print the byte-identical markdown source of the last markdown upload (the only legal edit base; errors when no source is stored — never falls back to the lossy HTML→md render)
+- `lumo doc diff <doc> --file <local.md>` — compare the server-side markdown source against a local file (exit 0 identical, 1 with unified diff)
 - `lumo doc move` — reparent under a parent / to root
 - `lumo doc bind/unbind <doc> <task>` — task linkage
 - `lumo doc share/unshare/share-list` — member sharing
@@ -149,10 +151,10 @@ Typical flow when a user says "help me with LUM-42":
 1. `lumo session attach LUM-42` — bind this session
 2. `lumo task context LUM-42` — load background
 3. Review unresolved items, PR-review todos, and the task description
-4. **If the task has no acceptance criteria** (context shows the 草拟提醒 instead of a contract): draft 3–7 outcome-level criteria and submit them with `lumo task criteria set` **before writing the first line of code** — see [criteria.md](references/criteria.md) for the drafting guide
+4. **If the task has no acceptance criteria** (context shows the draft reminder instead of a contract): draft 3–7 outcome-level criteria and submit them with `lumo task criteria set` **before writing the first line of code** — see [criteria.md](references/criteria.md) for the drafting guide
 5. Begin working on the task
 6. **Before claiming the work is done: run `lumo verify`** — the machine half of the acceptance loop. Fix failures and re-run (round cap 3). On all-pass the task moves to IN_REVIEW and you stop; never set DONE yourself after a verify loop — that adjudication is human-only. See [verify.md](references/verify.md)
 
 **Status-first recovery:** when you pick a task back up — a new session resuming earlier work, or a task that came back after a rejected verification round / review findings — run `lumo task status` **before** re-reading code or planning. It tells you where the loop stands (current round, what passed, what's unmet and why, any REVIEW_ADDED criteria appended during review) so you don't redo finished work or miss the reason it bounced. See [verify.md](references/verify.md)
 
-**Git-suggest at start:** when the session is unbound, session-start may infer the task from the git branch / recent commits and print a suggestion — `检测到 LUM-N … 运行 lumo session attach LUM-N 绑定。` — **without** binding. Confirm it's the right task, then run `lumo session attach <LUM-N>` yourself (binding only happens on an explicit attach). See [sessions.md](references/sessions.md) for the full session-start behavior.
+**Git-suggest at start:** when the session is unbound, session-start may infer the task from the git branch / recent commits and print a suggestion — `Detected LUM-N (from branch name). Run lumo session attach LUM-N to bind.` (or `from recent commits`) — **without** binding. Confirm it's the right task, then run `lumo session attach <LUM-N>` yourself (binding only happens on an explicit attach). See [sessions.md](references/sessions.md) for the full session-start behavior.

package/assets/skill/references/artifacts-figma.md

@@ -2,7 +2,7 @@
 
 ### Task ↔ Spec Artifacts
 
-Record Claude Code spec-engineering products (spec / plan / design …) on a task. The artifacts show up in the task detail "规格" (definition) layer and are injected into `lumo task context`.
+Record Claude Code spec-engineering products (spec / plan / design …) on a task. The artifacts show up in the task detail definition ("spec") layer and are injected into `lumo task context`.
 
 #### `lumo task artifact add <task> --kind <kind> --title <title> --file <path> --source <source> --agent <agent>`
 

package/assets/skill/references/criteria.md

@@ -1,16 +1,17 @@
-# Acceptance criteria（验收合约）
+# Acceptance criteria (contract)
 
 The acceptance contract is a small set of structured criteria the task's work
 will be verified against (Acceptance v1, LUM-341/342). The agent drafts it;
 the server validates and stores it; verification rounds (`lumo verify`,
-Slice 1 任务 ③) judge against it. Criteria are injected at session start and
-in `lumo task context` as the `## 验收标准（合约）` section.
+Slice 1 task #3) judge against it. Criteria are injected at session start and
+in `lumo task context` as the `## Acceptance criteria (contract)` section.
 
 ## When to draft — the golden rule
 
 **Attach → read context → draft criteria → THEN write the first line of code.**
 
-If `lumo task context` / session-start shows 该任务尚无验收标准 instead of a
+If `lumo task context` / session-start shows the draft reminder ("This task
+has no acceptance criteria yet. …") instead of a
 contract, you MUST draft and submit criteria before starting implementation:
 
 1. Read the task description, comments, linked resources, and memory first —
@@ -38,7 +39,7 @@ to-do list you trim to fit what you built.
   - `MACHINE` = an executable check exists. It **must** carry a `checkpointer`
     (the runnable check: a test command, script, probe…). The checkpointer
     runs on the agent's machine; the structured verdict is reported back to
-    the server (执行在客户端，裁判在服务端).
+    the server (execution on the client, adjudication on the server).
   - `HUMAN` = needs human judgment (UX feel, copy tone, design fidelity).
   - **If you can't attach a checkpointer to a MACHINE criterion, demote it to
     HUMAN** — the server rejects checkpointer-less MACHINE criteria rather
@@ -97,7 +98,7 @@ time, even after the agent lock. The file is the **desired final list**:
 - existing criteria missing from the file are **deleted** — refused with 409
   if the criterion already has verification runs (reword it instead)
 
-The revision is auto-recorded as a task comment with the session 出处
+The revision is auto-recorded as a task comment with the session origin
 (`X-Lumo-Session-Id`). **Transcribing the contract is allowed; transcribing a
 verdict is never** — human verdicts only enter through human-initiated paths
 (web UI / Slack action), and the agent has no write path to them.
@@ -123,10 +124,10 @@ before a `--human` revision. Empty contract prints a drafting pointer.
 
 - **Session start** (bound task): the contract is the highest-priority
   section in the injection budget — ahead of memory/PR/Slack/Figma/web. If a
-  still-open task has no criteria, a 草拟提醒 is injected instead.
-- **`lumo session attach`**: prints the contract (or the 草拟提醒) right after
+  still-open task has no criteria, the draft reminder is injected instead.
+- **`lumo session attach`**: prints the contract (or the draft reminder) right after
   binding.
-- **`lumo task context`**: the `## 验收标准（合约）` section appears after the
+- **`lumo task context`**: the `## Acceptance criteria (contract)` section appears after the
   task description, before memory.
 - Review-time gap findings (`REVIEW_ADDED`, appended at the round they
   surface) arrive via the verification loop, not via `criteria set`.

package/assets/skill/references/docs.md

@@ -42,7 +42,7 @@ The `Tags:` line is omitted when no tags were attached.
 
 ### When to suggest `doc create`
 
-- User says "write a doc", "起一篇 RFC", "新建文档", or describes a deliverable that should live as a document.
+- User says "write a doc", "draft an RFC", "new document" (in any language), or describes a deliverable that should live as a document.
 - After a discussion that needs a write-up, offer to create the doc with a title and the right scope.
 
 ### `lumo doc update <doc> [flags]` — update a document
@@ -85,17 +85,50 @@ lumo doc update RFC --tag final --add-tag oops
 - User wants to revise an existing doc.
 - After running `lumo doc list` or `doc show`, if the user wants to change a doc's scope, title, or content.
 
-### `lumo doc show <doc>` — print one document's detail
+### `lumo doc show <doc> [--raw]` — print one document's detail
 
-Prints a key:value header (id, title, scope, project, created/updated timestamps, mentioned tasks) and the content rendered back to markdown.
+Default mode prints a key:value header (id, title, scope, project, created/updated timestamps, mentioned tasks) and the content rendered back to markdown.
 
 ```bash
 lumo doc show "RFC: doc CLI"
+lumo doc show cmd_xxx --raw > base.md   # byte-identical edit base
 ```
 
-Note: the markdown rendered by `doc show` is best-effort. Round-trip via `doc show > tmp.md && doc update --file tmp.md` is NOT guaranteed to be a no-op.
+**`--raw` (LUM-408)** prints the byte-identical markdown source of the last markdown upload — no header, no trailing newline added. The server stores the raw markdown (`sourceMarkdown`) alongside the rendered HTML on every markdown write (`doc create/update --content/--file/stdin`, gdoc import/sync), so `--raw` output IS a legal edit base: `doc show --raw > base.md`, edit, `doc update --file base.md` round-trips losslessly.
 
-Use when the user wants the current state or content of a doc without loading full task context.
+- A web-editor (HTML-direct) edit or revision restore **invalidates** the stored source — the doc's markdown source is gone until the next markdown upload.
+- When no source is stored (legacy doc or after an HTML edit), `--raw` **fails with exit 1 and a rebuild hint** — it never silently falls back to the lossy HTML→markdown reverse render (that fallback flattened tables: LUM-349). Rebuild flow: `doc show` (rendered) → reconstruct the markdown faithfully → `doc update --file rebuilt.md` → `--raw` works from then on.
+- Raw output is verbatim (unsanitized) by design — redirect it to a file rather than reading it in a terminal when the doc's provenance is uncertain.
+
+Note: the markdown rendered by **default-mode** `doc show` is still best-effort (tables flatten). Round-trip via `doc show > tmp.md && doc update --file tmp.md` is NOT a no-op — use `--raw` as the edit base instead.
+
+Use default mode when the user wants to read a doc; use `--raw` whenever the output will be edited and uploaded back.
+
+### When to suggest `doc show --raw`
+
+- Before any `doc update --file` that starts from existing remote content — fetch the base with `--raw`, never from rendered `doc show` output.
+- User asks "what's the exact source of this doc", or an agent needs a faithful local copy of a live doc.
+- If `--raw` errors (no stored source), walk the rebuild flow above instead of editing the rendered output.
+
+### `lumo doc diff <doc> --file <local.md>` — compare remote markdown source vs a local file
+
+Compares the server-side stored markdown source (the byte-identical last markdown upload) against a local file, making remote/local split-brain visible on demand.
+
+| Flag            | Type   | Notes                                                                              |
+| --------------- | ------ | ---------------------------------------------------------------------------------- |
+| `--file <path>` | string | Required. Local markdown file; same project-local sandbox as `doc update --file`. |
+
+Exit codes: **0** = byte-identical (prints `Clean: …`), **1** = divergent (prints a unified diff, `--- remote/<id> (sourceMarkdown)` vs `+++ local/<file>`) or error. A doc without a stored markdown source errors explicitly (upload a markdown base once, then diff works).
+
+```bash
+lumo doc diff cmd_xxx --file docs/live-docs/research-intake-ledger.md
+```
+
+### When to suggest `doc diff`
+
+- Before uploading a locally edited file with `doc update --file` — check whether the remote source moved since the local copy was taken (prevents stale-upload clobbering, the #460 incident class).
+- When a repo-tracked markdown source (e.g. `docs/live-docs/`) and the live doc may have drifted and the user asks which is current.
+- After a suspected concurrent edit: a clean diff (exit 0) proves remote and local are in sync.
 
 ### `lumo doc list [flags]` — list documents
 
@@ -156,7 +189,7 @@ Moved cmd_xxx "Sub-doc" → root
 
 ### When to suggest `doc move`
 
-- User says "move doc X under Y", "把文档 X 挂到 Y 下", "reparent X to root", "promote X to top level".
+- User says "move doc X under Y", "reparent X to root", "promote X to top level".
 - After `doc create`, if the user realizes the new doc should live elsewhere in the tree — suggest `doc move` rather than recreating.
 
 ### `lumo doc delete <doc> --yes` — delete a document
@@ -232,7 +265,7 @@ lumo doc share-list "RFC"
 
 ### When to suggest the doc share commands
 
-- User says "share doc X with Y", "give Y access to X", "把文档分享给 Y"
+- User says "share doc X with Y", "give Y access to X"
 - After `doc create --scope personal`, if the user mentions teammates needing access, suggest `doc share` rather than `doc update --scope workspace` when only specific members should see it
 - Before `doc unshare`, run `doc share-list` if the user hasn't named a specific member
 
@@ -266,7 +299,7 @@ The `Bound ... ↔ LUM-N` line appears only when `--task` is supplied.
 
 ### When to suggest `doc import-gdoc`
 
-- User pastes a Google Doc URL or says "import this Google Doc", "pull this gdoc into Lumo", "把这篇 Google 文档导入".
+- User pastes a Google Doc URL or says "import this Google Doc", "pull this gdoc into Lumo".
 - User wants a Google Doc tracked alongside Lumo tasks/docs — suggest import (with `--task LUM-N` if a task is in context) and remind them about the over-share semantics for `--scope workspace`.
 
 ### `lumo doc sync <doc>` — re-sync an imported doc from Google
@@ -290,7 +323,7 @@ Synced cmd_xxx "Quarterly Plan" from Google
 
 ### When to suggest `doc sync`
 
-- User says "re-sync the Google Doc", "pull the latest from Google", "refresh the imported doc", "更新一下从 Google 导入的文档".
+- User says "re-sync the Google Doc", "pull the latest from Google", "refresh the imported doc".
 - After the user mentions the Google Doc changed upstream. Warn first that local Lumo edits to that doc will be overwritten (one-way, destructive).
 
 ### Out of scope (CLI v1)
@@ -298,7 +331,7 @@ Synced cmd_xxx "Quarterly Plan" from Google
 The CLI does **not** currently support:
 
 - `--from-editor` (interactive $EDITOR).
-- Lossless markdown round-trip.
+- Lossless markdown round-trip from **rendered** `doc show` output (use `doc show --raw` — lossless whenever a markdown source is stored).
 - Reordering siblings within the same parent (`--before` / `--after`); use the Web UI for that.
 
 ### When to suggest session binding for docs

package/assets/skill/references/memory.md

@@ -45,17 +45,29 @@ the bound task; `lumo project memory add ...` records onto its project.
 
 The command prints **one** of these outcome lines:
 
-| Output line | Meaning |
-|---|---|
-| `Added <CATEGORY> <SCOPE> memory …` | No near-duplicate found; stored as a new row. |
-| `Merged into existing memory <id> (near-duplicate) …` | Near-duplicate found; the existing row was refined/updated in-place (UPDATE). |
-| `Superseded an existing memory; new version <id> …` | New content contradicts an old memory; old row invalidated, new row created (SUPERSEDE). |
-| `Skipped — duplicate of existing memory <id>, nothing written …` | Exact or near-exact duplicate; no write performed (NOOP). |
+| Output line                                                      | Meaning                                                                                  |
+| ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
+| `Added <CATEGORY> <SCOPE> memory …`                              | No near-duplicate found; stored as a new row.                                            |
+| `Merged into existing memory <id> (near-duplicate) …`            | Near-duplicate found; the existing row was refined/updated in-place (UPDATE).            |
+| `Superseded an existing memory; new version <id> …`              | New content contradicts an old memory; old row invalidated, new row created (SUPERSEDE). |
+| `Skipped — duplicate of existing memory <id>, nothing written …` | Exact or near-exact duplicate; no write performed (NOOP).                                |
 
 Content is **always normalized to English** before storing — the memory store has
 a single canonical language. If you supply text in another language the CLI
 translates it automatically; the stored memory will be in English.
 
+### Lumo memory vs the harness memory tool
+
+Claude Code / the Claude API may expose a file-based **memory tool** (a
+`/memories` directory the model writes autonomously). That store is the agent's
+private scratchpad — un-grounded, free-form, invisible to the team, and outside
+Lumo's flywheel. **Project engineering lessons always go through `lumo task/project
+memory add`** — never record them only in the harness memory tool, and never bulk-copy
+harness memory files into Lumo memory (they are ungrounded drafts; Lumo's
+extract→ground→reconcile write path is the only vetted entry). The two stores are
+layered, not mirrored: transient working notes may live in the harness tool,
+durable team knowledge lives in Lumo memory.
+
 ### When to record a memory (worthiness)
 
 Record only knowledge that is **invisible in the codebase** — the _why_ behind a

package/assets/skill/references/milestones.md

@@ -45,7 +45,7 @@ lumo milestone list --all --search launch   # search across archived + non-archi
 
 - Before suggesting `task create --milestone <ref>` or `task update --milestone <ref>` to confirm the milestone exists under the expected name.
 - When the user asks "what milestones do we have", "what's on v1.0", or similar.
-- When the user wants to **find/search milestones by keyword** ("find the launch milestone", "搜索里程碑", "which milestones mention X") — use `--search <text>` rather than listing all and eyeballing.
+- When the user wants to **find/search milestones by keyword** ("find the launch milestone", "which milestones mention X") — use `--search <text>` rather than listing all and eyeballing.
 
 When to suggest: before `task create --project <ref>` when the workspace has more than one project and the user hasn't specified which one.
 
@@ -75,7 +75,7 @@ Prints a key:value header (name, status, **health**, dates, project, description
 
 It also prints a **Sprint coverage** section (above the task table) listing which
 sprints the milestone's tasks span — each row shows the sprint number, status, name,
-and `done/total` progress — plus an `未排期` line counting milestone tasks not in any
+and `done/total` progress — plus an `Unscheduled` line counting milestone tasks not in any
 sprint (shown only when there are any). The section is derived from the milestone's
 tasks (no schema relation), so it needs no extra flags. When no task is in any sprint
 it prints `Sprint coverage: (no sprint coverage)`.
@@ -86,7 +86,7 @@ Example coverage section:
 Sprint coverage:
   #3  ACTIVE  Sprint 3   4/6 done
   #4  DRAFT   Sprint 4   0/2 done
-  未排期                  1 task
+  Unscheduled             1 task
 ```
 
 ```bash
@@ -176,7 +176,7 @@ Q3 Launch: 1 removed, 1 skipped
 
 ### When to suggest `milestone add` / `milestone remove`
 
-- The user wants to attach/detach **several** tasks to a milestone at once ("挂这几个任务到 Q3", "把 LUM-1 LUM-2 LUM-3 都放进里程碑", "remove these from the milestone"). For a single task, `task update --milestone <ref>` (or `--milestone ""` to clear) is equally fine.
+- The user wants to attach/detach **several** tasks to a milestone at once ("attach these tasks to Q3", "put LUM-1 LUM-2 LUM-3 into the milestone", "remove these from the milestone"). For a single task, `task update --milestone <ref>` (or `--milestone ""` to clear) is equally fine.
 - `remove` only clears the binding for tasks actually in the named milestone, so it's safe to pass a broad list — anything not in it is reported as skipped, not clobbered.
 - For one-at-a-time sprint binding see `lumo sprint add / remove` (sprint batch is not yet supported).
 
@@ -197,7 +197,7 @@ lumo milestone summary "Q3 Launch" --retry
 lumo milestone summary 11111111-2222-3333-4444-555555555555
 ```
 
-When to suggest: user asks "summarize the milestone", "milestone retro", "give me a summary of the Q3 milestone", "里程碑总结", "里程碑复盘".
+When to suggest: user asks "summarize the milestone", "milestone retro", "give me a summary of the Q3 milestone".
 
 ### `lumo milestone reorder <ref...> [--project <ref>]` — set the full milestone order
 
@@ -241,4 +241,4 @@ Both commands resolve to a full ordered list client-side and call the same `PATC
 
 **Ambiguous names:** milestone names are not unique within a project (only the slug is). A ref whose name matches more than one milestone is **rejected** with an `ambiguous milestone name … re-run with the id` error listing the candidate cuids — pass the cuid instead. This applies to every name-based milestone ref (`reorder`, `move`, and also `show` / `update` / `delete` / `summary` / `add` / `remove`).
 
-When to suggest: user asks to "reorder milestones", "排序里程碑", "调整里程碑顺序", "move milestone X before/after Y", "把里程碑 X 移到 Y 前面/后面", "put this milestone first".
+When to suggest: user asks to "reorder milestones", "move milestone X before/after Y", "put this milestone first".

package/assets/skill/references/sessions.md

@@ -13,7 +13,8 @@ infer the task from local git so it can **suggest** one — it never binds for y
   `LUM-<n>`.
 - On a hit it prints a single suggestion line and stops — the session stays
   **unbound** and no context is injected yet:
-  `检测到 LUM-145（依据分支名/最近 commit）。运行 lumo session attach LUM-145 绑定。`
+  `Detected LUM-145 (from branch name). Run lumo session attach LUM-145 to bind.`
+  (the basis reads `from recent commits` when the hit came from commit subjects instead of the branch name)
   No task title is shown here because nothing was fetched; the title, memory,
   and PR-review todos appear only once you actually attach.
 - No match (detached HEAD, a non-lumo branch with no tagged commits, not a git
@@ -27,7 +28,7 @@ just attach the correct task instead.
 
 ### Layer 2 project-memory review at session start
 
-When the session is bound, session-start may inject a **"🆕 待核对：上次会话自动合并的项目级记忆"** section alongside the memory / PR-review blocks (LUM-165). It lists the **PROJECT-scope** memories that the member's **immediately-preceding session** auto-consolidated (Layer 2 runs asynchronously when a task is marked `done`). Each item shows its `id`.
+When the session is bound, session-start may inject a **"🆕 Review needed: project memories auto-consolidated by the previous session"** section alongside the memory / PR-review blocks (LUM-165). It lists the **PROJECT-scope** memories that the member's **immediately-preceding session** auto-consolidated (Layer 2 runs asynchronously when a task is marked `done`). Each item shows its `id`.
 
 - **Why it's here:** Layer 2 promotions land async, so they can't be reviewed in the synchronous `session wrap` panel — they're surfaced at the _next_ session-start instead, when they've definitely landed.
 - **Show-once:** the section appears only at the session that immediately follows the one that produced the memories. It does **not** re-nag on later sessions, so act on it now or it scrolls off.
@@ -45,31 +46,31 @@ When the bound task has live blockers or SUGGESTED dependency candidates, the at
 
 **Output form A — live blockers exist (with or without SUGGESTED candidates):**
 
-Starts with the `## ⚠ 依赖告警` header, followed by one line per live blocker, then the advice line. If there are also SUGGESTED candidates the candidate-hint line is appended after the advice line.
+Starts with the `## ⚠ Dependency alerts` header, followed by one line per live blocker, then the advice line. If there are also SUGGESTED candidates the candidate-hint line is appended after the advice line.
 
 ```
-## ⚠ 依赖告警
+## ⚠ Dependency alerts
 
-- 本任务被 LUM-9「Fix auth token expiry」阻塞(状态 IN_PROGRESS)。
-- 本任务被 LUM-15「Upgrade Postgres driver」阻塞(状态 IN_REVIEW,PR #42 未 merge)。
+- This task is blocked by LUM-9 "Fix auth token expiry" (status IN_PROGRESS).
+- This task is blocked by LUM-15 "Upgrade Postgres driver" (status IN_REVIEW, PR #42 not merged).
 
-建议先等 blocker 合并再开工,避免白跑 run;如边已过时,用 `lumo task deps rm/dismiss` 清理。
-检测到 3 条候选依赖待确认:运行 `lumo task deps list LUM-42`。
+Consider waiting for the blocker(s) to merge before starting work to avoid a wasted run; if an edge is stale, clean it up with `lumo task deps rm/dismiss`.
+Detected 3 candidate dependencies awaiting confirmation: run `lumo task deps list LUM-42`.
 ```
 
 **Output form B — NO live blockers, but SUGGESTED candidates exist:**
 
-Output is **only** the hint line — no `## ⚠ 依赖告警` header, no advice line. Design rationale: 纯候选是提示不是告警,不戴 ⚠ 头,避免稀释真告警。
+Output is **only** the hint line — no `## ⚠ Dependency alerts` header, no advice line. Design rationale: pure candidates are a hint, not an alert — they don't get the ⚠ header, so real alerts aren't diluted.
 
 ```
-检测到 3 条候选依赖待确认:运行 `lumo task deps list LUM-42`。
+Detected 3 candidate dependencies awaiting confirmation: run `lumo task deps list LUM-42`.
 ```
 
-- Each blocker line shows: identifier, title, current status. If the blocking task has an open pull request, a `,PR #N` note is appended (no space after the comma) — `,PR #N (draft) 未 merge` for draft PRs.
-- The guidance line ("建议先等 blocker 合并…") appears only when there is at least one live blocker (form A).
+- Each blocker line shows: identifier, title, current status. If the blocking task has an open pull request, a `, PR #N not merged` note is appended — `, PR #N (draft) not merged` for draft PRs.
+- The guidance line ("Consider waiting for the blocker(s) to merge…") appears only when there is at least one live blocker (form A).
 - The function never throws — if it fails it silently returns an empty string, leaving the session start unaffected.
 
-**Agent guidance — watch for EITHER the `## ⚠ 依赖告警` header (form A) OR the standalone hint line (form B):**
+**Agent guidance — watch for EITHER the `## ⚠ Dependency alerts` header (form A) OR the standalone hint line (form B):**
 - **Form A — live blockers:** Evaluate whether to wait. If the blocking task's work overlaps with yours (same files, same API surface), starting immediately risks rework. Read the blocker's status and open PR note before deciding.
 - **Stale or wrong edge?** Run `lumo task deps list <LUM-N>` to inspect the full edge list, then `lumo task deps rm <LUM-N> <edge> --yes` (if manually added and now obsolete) or `lumo task deps dismiss <LUM-N> <edge>` (if a false positive from detection).
 - **Candidate hint present (form A or B)?** Run `lumo task deps list <LUM-N>` and review each SUGGESTED edge — confirm real ones, dismiss false positives. Leaving SUGGESTED edges unreviewed means repeated hints every session.
@@ -89,7 +90,7 @@ What it does:
 - Calls `POST /api/sessions/<session_id>/bind-task` on the Lumo server, which sets the Session row's `taskId` and re-tags previously-untagged HookEvent rows in this session.
 - The binding lives entirely on the server (`Session.taskId`); subsequent hooks read it back via the session row. The CLI keeps no local sentinel.
 
-- Prints the task's **验收标准（合约）** (acceptance contract, LUM-342) right after the bind confirmation — or, when a still-open task has none, the 草拟提醒 telling you to draft 3–7 criteria before the first line of code (see [criteria.md](criteria.md)). The same section is auto-injected at session start when the session is already bound (highest priority in the injection budget, ahead of memory).
+- Prints the task's **acceptance contract** (`## Acceptance criteria (contract)`, LUM-342) right after the bind confirmation — or, when a still-open task has none, the draft reminder telling you to draft 3–7 criteria before the first line of code (see [criteria.md](criteria.md)). The same section is auto-injected at session start when the session is already bound (highest priority in the injection budget, ahead of memory).
 
 **After attaching, always run `lumo task context <identifier>` to load the task background.**
 
@@ -97,7 +98,7 @@ What it does:
 
 Re-attaching a session that's already bound to a **different** task no longer silently clobbers the binding. The server returns the current binding instead of overwriting, and the CLI decides what to do:
 
-- **On a TTY** (a human running it directly): prompts `已绑定 LUM-X，覆盖为 LUM-Y? [y/N]`. Answering `y`/`yes` re-binds to `LUM-Y`; anything else (including bare Enter) cancels and leaves `LUM-X` bound.
+- **On a TTY** (a human running it directly): prompts `Already bound to LUM-X. Rebind to LUM-Y? [y/N]`. Answering `y`/`yes` re-binds to `LUM-Y`; anything else (including bare Enter) cancels and leaves `LUM-X` bound.
 - **Off a TTY** (the usual agent case — `stdin` is not interactive): the command **refuses** and prints `Session already bound to LUM-X … Re-run with --force …` without overwriting. Exit code is `0` (a safe refusal, not an error).
 - **`--force`**: skips the prompt/refusal and overwrites unconditionally. Re-attaching to the **same** task is always a no-op re-bind (never prompts).
 
@@ -136,25 +137,25 @@ When to suggest: the user wants to stop tagging the current session with the act
 
 Session-end wrap-up panel with **four sections, run in order**:
 
-**1. 进度评论** — reads back the current Claude Code session's per-turn
-`turnSummary` rows (the one-line Chinese summaries written each STOP), aggregates
+**1. Progress comment** — reads back the current Claude Code session's per-turn
+`turnSummary` rows (the one-line summaries written each STOP), aggregates
 every turn **since the last progress comment** into one bulleted body, and — after
-a `[y] 发送 / [e] 编辑 / [s] 跳过` confirmation — posts it as a comment on the
+a `[y] post / [e] edit / [s] skip` confirmation — posts it as a comment on the
 session's bound task. A server-side watermark (`Session.lastProgressCommentAt`)
 means re-running never re-posts the same turns.
 
-**2. 记忆审阅** — lists the Layer1 memories this session sedimented since the
+**2. Memory review** — lists the Layer1 memories this session sedimented since the
 last review (deduped by a per-session watermark `Session.lastMemoryReviewAt`).
 Each new memory is shown as `[SCOPE] CATEGORY  headline`, numbered from 1. You
 curate with a single line: `d 1,3` deletes rows 1 and 3, `p 2` promotes row 2 to
-project scope, and they combine (`d 1,3 p 2`). **回车 (empty) keeps all**; `s`
-skips the section. Keeping all (回车 or `--yes`) still **advances the watermark**
+project scope, and they combine (`d 1,3 p 2`). **Enter (empty) keeps all**; `s`
+skips the section. Keeping all (Enter or `--yes`) still **advances the watermark**
 so the next wrap won't re-list reviewed memories; `s` leaves them for next time.
 Out-of-range indices are ignored. Deletes/promotes run server-side, scoped to
 memories this session created (you can't touch other sessions' memories through
-this panel). With no new memories the section prints "(无内容)" and does nothing.
+this panel). With no new memories the section prints "(no content)" and does nothing.
 
-**3. 上下文使用投票 (fragment-usage vote, LUM-300)** — lists the context
+**3. Fragment-usage vote (LUM-300)** — lists the context
 fragments this session **consumed** (its lineage edges: memory / slack / web /
 figma / PR / review-todo / session), numbered from 1 with a content snippet
 label. The agent records which it **actually used** via
@@ -166,13 +167,12 @@ candidates and writes nothing** (edges stay `null` = not voted — honest, not
 upgrades the flywheel signal from "co-loaded" (constant, no information) to
 "actually used" (varies → discriminative); `task context` then prefers each
 fragment's usage-based merge rate, falling back to the weaker presence rate when
-usage samples are thin. With no consumed fragments the section prints "(无内容)".
+usage samples are thin. With no consumed fragments the section prints "(no content)".
 
-**4. 卡住检测 (blocked-tag prompt, LUM-153)** — if the **same kind of failure
+**4. Blocked check (blocked-tag prompt, LUM-153)** — if the **same kind of failure
 recurred ≥ 3 times** in this session (server-aggregated from
 `POST_TOOL_USE_FAILURE` events grouped by tool name, plus `STOP_FAILURE`
-turn-level failures), the section surfaces the dominant failure (`卡在 <tool>
-(N 次失败)` + last error summary) and prompts `[y] 标记 / [s] 跳过` whether to
+turn-level failures), the section surfaces the dominant failure (`This session looks repeatedly stuck on <tool> (N failures).` + last error summary) and prompts `[y] tag / [s] skip` whether to
 flag the bound task with a **`blocked` tag**. **Prompt-only — never auto-flips
 status.** It uses a plain tag (no `TaskStatus` enum, no board column, **no
 schema migration**). The prompt is **suppressed** when: there's no bound task,
@@ -183,7 +183,7 @@ opt-in), so a stray Enter never tags the task. Confirming with an explicit `y`
 attaches the tag idempotently. **`--yes` does NOT auto-tag** — tagging the
 shared board requires an interactive `y`, so `--yes` (and non-TTY) prints the
 suggestion and moves on rather than silently flipping board state. When there's
-nothing to prompt, the section prints "(无内容)".
+nothing to prompt, the section prints "(no content)".
 
 ```bash
 lumo session wrap                  # interactive: preview each section, choose per-section
@@ -200,8 +200,8 @@ see the numbered fragment list, decide which you actually used, then re-run with
 
 - Requires `$CLAUDE_CODE_SESSION_ID` (must run inside Claude Code) and a bound
   task (`lumo session attach <LUM-N>` first). With no bound task or no new turn
-  summaries, the 进度评论 section prints "(无内容)" and posts nothing.
-- `[e] 编辑` (进度评论) opens `$EDITOR` (fallback vi/nano) on the drafted body;
+  summaries, the Progress comment section prints "(no content)" and posts nothing.
+- `[e] edit` (Progress comment) opens `$EDITOR` (fallback vi/nano) on the drafted body;
   the edited text is posted and the watermark still advances to the turns the
   draft covered.
 - `--yes` posts the progress comment AND keeps all memories (no

package/assets/skill/references/sprints.md

@@ -36,7 +36,7 @@ lumo sprint create --name "Sprint 4" --start 2026-06-01 --end 2026-06-14 --team
 
 On success: `Created sprint #<number> "<name>"  <id>`.
 
-When to suggest: user says "create a sprint", "new sprint", "新建冲刺", "start a new iteration".
+When to suggest: user says "create a sprint", "new sprint", "start a new iteration".
 
 ### `lumo sprint show <identifier> [--team <ref>]` — show sprint detail + task table
 
@@ -63,7 +63,7 @@ lumo sprint show 3 --team backend
 lumo sprint show 11111111-2222-3333-4444-555555555555
 ```
 
-When to suggest: user asks "what's in sprint 3", "show me the current sprint", "冲刺里有什么", "what tasks are in this sprint", "is this sprint at risk", "冲刺风险", "sprint health".
+When to suggest: user asks "what's in sprint 3", "show me the current sprint", "what tasks are in this sprint", "is this sprint at risk", "sprint health".
 
 ### `lumo sprint update <identifier> [flags]` — patch a sprint
 
@@ -101,7 +101,7 @@ No additional flags. Fails if the sprint is already ACTIVE or CLOSED.
 lumo sprint start 3
 ```
 
-When to suggest: user says "start the sprint", "开始冲刺", "kick off sprint 3", "activate sprint".
+When to suggest: user says "start the sprint", "kick off sprint 3", "activate sprint".
 
 ### `lumo sprint close <identifier> [flags]` — transition ACTIVE → CLOSED
 
@@ -119,7 +119,7 @@ lumo sprint close 3 --move-all --yes         # move unfinished to next sprint
 lumo sprint close 3 --backlog-all --yes      # send unfinished to backlog
 ```
 
-When to suggest: user says "close the sprint", "关闭冲刺", "end sprint 3", "wrap up the sprint". If they haven't decided what to do with unfinished tasks, ask before adding `--move-all` or `--backlog-all`.
+When to suggest: user says "close the sprint", "end sprint 3", "wrap up the sprint". If they haven't decided what to do with unfinished tasks, ask before adding `--move-all` or `--backlog-all`.
 
 ### `lumo sprint summary <identifier> [--retry]` — fetch AI-generated sprint retro
 
@@ -134,7 +134,7 @@ lumo sprint summary 3
 lumo sprint summary 3 --retry
 ```
 
-When to suggest: user asks "summarize the sprint", "sprint retro", "give me a summary of sprint 3", "冲刺总结".
+When to suggest: user asks "summarize the sprint", "sprint retro", "give me a summary of sprint 3".
 
 ### `lumo sprint add <identifier> <task>` — bind a task to a sprint
 
@@ -144,7 +144,7 @@ Adds `<task>` (e.g. `LUM-48`) to the sprint. Same-team check applies — the tas
 lumo sprint add 3 LUM-48
 ```
 
-When to suggest: user says "add LUM-48 to sprint 3", "把任务挂到冲刺", "put this task in the sprint".
+When to suggest: user says "add LUM-48 to sprint 3", "put this task in the sprint".
 
 ### `lumo sprint remove <identifier> <task>` — unbind a task from a sprint
 

package/assets/skill/references/task-context.md

@@ -15,25 +15,25 @@ Example: `lumo task context LUM-42`
 The command prints a markdown document to stdout containing:
 
 1. **Task header** — identifier, title, status, description
-2. **验收标准（合约）** — the task's acceptance criteria (LUM-342), shown right after the header. Each line: `[MACHINE|HUMAN] statement` with a `↳ check:` line for MACHINE checkpointers; HUMAN_EDIT / REVIEW_ADDED provenance is tagged inline. If a still-open task has none, a 草拟提醒 appears instead — draft 3–7 criteria **before writing code** (see [criteria.md](criteria.md))
+2. **Acceptance criteria (contract)** — the task's acceptance criteria (LUM-342), shown right after the header as the `## Acceptance criteria (contract)` section. Each line: `[MACHINE|HUMAN] statement` with a `↳ check:` line for MACHINE checkpointers; HUMAN_EDIT / REVIEW_ADDED provenance is tagged inline. If a still-open task has none, a draft reminder appears instead — draft 3–7 criteria **before writing code** (see [criteria.md](criteria.md))
 3. **Memory section** — cross-session learnings accumulated over prior sessions; treat as trusted background context
 4. **Inline source cards** — Slack / web / Figma / artifacts / documents / comments / Pull Requests (see "Context Retrieval" below)
-5. **PR Review 待办** — mirrored PR review comments as a checkbox todo list: each line-level reviewer comment (shown as `` `file:line` `` + the reviewer's ask + a link to the GitHub comment) and each `changes_requested` review summary (shown as "🛑 整体要求改动"). Present only when the task's PR(s) have review comments. This same block is **auto-injected at session start** (alongside the memory section) when the session is bound to a task — so reviewer asks surface without re-running `task context`.
+5. **PR review todos** — mirrored PR review comments as a checkbox todo list under the `## PR review todos` header: each line-level reviewer comment (shown as `` `file:line` `` + the reviewer's ask + a link to the GitHub comment) and each `changes_requested` review summary (shown as "🛑 Changes requested (whole PR)"). Present only when the task's PR(s) have review comments. This same block is **auto-injected at session start** (alongside the memory section) when the session is bound to a task — so reviewer asks surface without re-running `task context`.
    - The **inline source cards** (Slack / web / Figma / PR) are likewise **auto-injected at session start** when the session is bound, under a single global token budget shared with the memory section (priority: criteria > memory > PR > Slack > Figma > web). Cards that don't fit the budget are degraded to a one-line manifest carrying just the title and its `lumo task … show` retrieval command — so you still know they exist and can pull the full content on demand.
 6. **Previous sessions** — ordered newest-first, each with:
    - A headline summary of what was done
    - Unresolved items (carry-over TODOs from that session)
-7. **飞轮信号 · 历史 merge 贡献** — appended at the very end. For each context fragment with enough history, a one-line historical merge-contribution signal (e.g. `出现在 5 个已闭合任务·4 merged (80%)`), computed from accumulated lineage edges. Denominator = distinct tasks where the fragment appeared with a resolved (non-UNKNOWN) outcome; only fragments with ≥3 such tasks are shown (cold-start gate), so the block is often absent early on. This is **historical correlation, not causation** — don't read it as a prediction.
+7. **Flywheel signal · historical merge contribution** — appended at the very end as the `## Flywheel signal · historical merge contribution` section. For each context fragment with enough history, a one-line historical merge-contribution signal (e.g. `appeared in 5 resolved tasks · 4 merged (80%)`), computed from accumulated lineage edges. Denominator = distinct tasks where the fragment appeared with a resolved (non-UNKNOWN) outcome; only fragments with ≥3 such tasks are shown (cold-start gate), so the block is often absent early on. This is **historical correlation, not causation** — don't read it as a prediction.
 
 ### How to use the context
 
 - **Unresolved items** from the most recent session are the highest-priority carry-overs — address them before starting new work unless the user says otherwise
-- **PR Review 待办** items are reviewer-requested changes — treat each unchecked box as a TODO to resolve, then reply on the PR (a Lumo comment mirrors back to GitHub)
+- **PR review todos** items are reviewer-requested changes — treat each unchecked box as a TODO to resolve, then reply on the PR (a Lumo comment mirrors back to GitHub)
 - **Memory section** provides validated context that persists across sessions — use it to avoid re-learning decisions or constraints
 - Focus on the **most recent 1–2 sessions** for relevant state; older sessions are for historical reference only
 - If there are **no prior sessions**, this is a fresh start — read the task description carefully and ask clarifying questions if needed
 
-## Context Retrieval (按需取全文)
+## Context Retrieval (full text on demand)
 
 LUM-122 split task context injection into tiers. `lumo task context <LUM-N>`
 now emits a **cheap inline card** for each source — a short summary or just