feishu-doc-workflow

name

feishu-doc-workflow

description

Feishu/Lark document and wiki workflow for reading, editing, structuring, and verifying docs, wiki pages, paper cards, meeting notes, deep dives, images, and drive-native Markdown through the local `lark-cli`. Use when the user provides a feishu.cn/larksuite.com document or wiki URL, asks to read or edit 飞书/Feishu/Lark content, asks to maintain Feishu paper cards or meeting pages, mentions 飞书文档/飞书知识库, or needs authenticated Feishu document updates with hierarchy, image, and post-write verification rules.

Feishu Doc Workflow

Overview

Use the local lark-cli for Feishu/Lark document work. This skill is a document workflow, not just a CLI wrapper: preserve hierarchy, content structure, image dimensions, and post-write verification. Prefer CLI reads and writes over browser automation for Feishu links because this machine already has CLI auth configured.

Quick Start

Use the installed command:

~/.local/bin/lark-cli --help

Read a document or wiki URL:

~/.local/bin/lark-cli docs +fetch \
  --api-version v2 \
  --doc '<feishu-or-lark-url-or-token>' \
  --as user \
  --format json

Edit a document:

~/.local/bin/lark-cli docs +update \
  --api-version v2 \
  --doc '<feishu-or-lark-url-or-token>' \
  --as user \
  --mode append \
  --markdown '@file.md'

Workflow

1. Fetch first. Capture the returned document_id, revision_id, title, and relevant content before writing.
2. Choose the smallest safe write mode:
   • append for adding new sections.
   • insert_before or insert_after with --selection-by-title or --selection-with-ellipsis for targeted insertion.
   • replace_range for a known span.
   • replace_all or overwrite only when the user explicitly wants a full rewrite.
   • Never use docs_ai / docs +update --command overwrite for metadata-only edits on an existing page that contains images, grids, tables, whiteboards, formulas, or other rich blocks. Even if the fetched XML keeps <img> tags, Feishu may recreate or reflow the native image blocks and visibly move the user's images. For paper-card metadata changes, use block-level text updates, exact visible-text str_replace, or ask the user to restore the page version before retrying.
   • For existing content, prefer modification over rewriting: use Docx block API text updates, exact text replacement, or targeted block insertion/deletion. Do not rebuild an entire card, section, grid, or page just to change wording, metadata, captions, formulas, or other local content.
3. Preserve existing images, tables, grids, and rich content unless the user explicitly asks to restructure them.
   • Treat the user's current visual arrangement as intentional. If images are in the same row, grid, callout, or adjacent image group, preserve their order, parent block, column/grid ratios, relative widths, scale, align, captions, and spacing. Do not normalize two side-by-side images to the same width, move them into separate rows, or rebuild their container unless the user explicitly asks for a layout change.
4. For images, do not create or rewrite them by embedding raw XML <img> tags in document content. Use docs +media-insert with local image files and a text selection so Feishu creates native image blocks that keep the source image aspect ratio.
5. When any write may touch existing image blocks, fetch with --detail full before editing and preserve every image's native width, height, scale, src, caption, alignment, parent/container relationship, sibling order, and any grid column-width ratios. Treat width and height as the original-resolution pixel dimensions / aspect-ratio contract, and treat scale / grid ratios as the user's visible layout contract, not decorative metadata. Never let an image fall back to Feishu's default 512 × 512 square sizing, and never square-crop, force square dimensions, equalize side-by-side image widths, or reflow a multi-image row unless the user explicitly asks.
6. If a fetched image block lacks trustworthy width / height, download the image from its authenticated href or file token, inspect the actual pixel dimensions, and write those dimensions back into the image block before overwriting the page. After writing, fetch again with --detail full and verify that every touched image's width / height still matches the preserved or inspected dimensions.
7. If an accidental XML overwrite has already recreated images as 512 × 512 blocks, do not repair by another whole-page overwrite. Use the Docx block API and an older readable document_revision_id instead:
   • Read old and current blocks from /open-apis/docx/v1/documents/<docx_token>/blocks?document_revision_id=<rev>.
   • For each image, download the old image token to a task-local temp directory, upload it to the current image block with docs +media-upload --parent-type docx_image --parent-node <current_image_block_id>, then PATCH /blocks/<current_image_block_id> with replace_image.token, original width, height, scale, align when present, and caption.
   • For grids, patch the current grid block, not individual grid columns: update_grid_column_width_ratio: {"width_ratios":[...]} using ratios read from the old grid's child columns.
   • Verify image count, no unintended 512 × 512 images, original width/height/scale/caption, grid ratio parity, and paper-card metadata count. Feishu may normalize missing image align to align=2; do not chase that field if all visible geometry metadata is restored.
8. Use --dry-run before risky writes or when the selection may be ambiguous.
9. Fetch again after writing to verify the update.
10. After docs +update --command overwrite, the doc/Wiki node title may stay Untitled unless you set it. Prefer --new-title 'Page Name' on the same update when the CLI accepts it; otherwise rename via Drive API:

lark-cli api PATCH "/open-apis/drive/v1/files/<docx_token>" \
  --as user --params '{"type":"docx"}' \
  --data '{"new_title":"Google Dreamer"}'

Use the doc token from docs +fetch or wiki spaces get_node (obj_token). Confirm with wiki spaces get_node --params '{"token":"<wiki_node_token>"}'. Do not trust --new-title alone after an overwrite. Always fetch the doc and the wiki node after large writes and verify both:

lark-cli docs +fetch --api-version v2 --doc '<docx_token>' --as user --format json
lark-cli wiki spaces get_node --as user --params '{"token":"<wiki_node_token>"}'

If either title is Untitled, immediately run the Drive PATCH above with the obj_token/docx token and verify again. For origin wiki nodes, updating the Drive docx title normally updates the wiki node title as well.

Manually Imported pdf2zh-next Translation

When a translated PDF was manually imported into Feishu, classify the page as a draft conversion and apply the repair gate in paper-deep-dive before calling it a complete deep dive. Rename the page to the verified Chinese paper title, add the required PDF / Project / Code / child-page links, restore heading hierarchy and paragraph breaks, preserve inline and display formulas as native Feishu equations or exact LaTeX, convert figure captions to native image captions, and repair tables against the source PDF/HTML. Derive heading depth at every level from the numeric prefix (N → top level, N.M → subsection, N.M.K → sub-subsection, continuing by component count) rather than imported visual styling. Convert full-width heading punctuation ． to ASCII . before parsing, so 4．2．方法 becomes 4.2. 方法. In ordinary structural text, convert ／ to /, － to -, and citation/list brackets ［］ to []; protect formulas, code, URLs, paths, and backslash-escaped sequences before cleanup and restore them exactly. Preserve unrelated Chinese punctuation in prose. Use one punctuation convention throughout, defaulting to N. 标题 / N.M. 小标题 unless the source consistently uses N 标题 / N.M 小标题. In the Chinese manuscript, the cited paper title may be translated, but authors, venue, year, pages, identifiers, URLs, and other reference metadata remain in the source language. Re-fetch after editing and verify title, links, hierarchy, formulas, captions, tables, References, and body citation URLs.

Workspace Hygiene

• Do not create Feishu-editing scratch files in the vault root. This includes fetched JSON, intermediate Markdown/XML, link-check scripts, generated paper-card scripts, screenshots, and one-off validation outputs.
• Put all temporary files for a Feishu task under a hidden working directory such as .tools/tmp/codex/<task-slug>/ or the system temp directory, and remove them after the Feishu page has been verified.
• For literature or paper-card work, do not keep local copies of source PDFs, arXiv HTML pages, downloaded project pages, extracted PDF text, OCR/MinerU outputs, or temporary figure assets. Prefer reading official HTML/full-paper pages directly. If a PDF/HTML/source asset must be downloaded for extraction or verification, store it only under a task-local temporary directory, use it to write the Feishu content, fetch the Feishu page to verify the durable copy, then delete the downloaded source and extracted intermediates before finishing.
• If an artifact should be kept for audit or reuse, store it under an explicit non-root location such as .tools/outputs/<task-slug>/ and mention it to the user. Do not leave opaque files like sovd_current.md, *_after.json, or ad-hoc Python scripts in the root of WorldModelVault.
• Before finishing a Feishu editing task, check for task-local scratch files and clean them up unless the user asked to keep them.

Paper Card Images

When syncing paper cards to Feishu, use only reliable paper figures as card images:

• Prefer the paper's core method/process figure with matching captions: method, pipeline, framework, system overview, architecture, data flow, benchmark construction, score/loss/computation flow, or other figures that explain how the work operates.
• Do not use a teaser, qualitative showcase, result collage, demo gallery, or visual example grid as the only paper-card image when a core method/process figure exists in the official paper HTML/PDF or project page. A teaser may be kept only as a second supplementary image when it adds distinct context, and its caption must label it as teaser / 结果展示 rather than presenting it as the method figure.
• When auditing or repairing existing paper cards, if the only image is a teaser/result showcase and a core method/process figure is available, insert or replace with the core figure first. Preserve the teaser only when the card can support a second image without clutter and it adds information the core figure does not.
• If no core method/process figure exists after checking the official paper HTML/PDF/project page, state that explicitly in the caption or note and use the most structurally informative fallback figure; do not silently present a teaser as the method image.
• Reject paper first pages, title pages, abstract pages, arXiv page screenshots, and generic PDF page renders as card images.
• Do not fall back to the largest raster image when no credible figure is found.
• When the user provides a paper figure image or screenshot, especially a manually captured image with the original caption visible, treat the visible caption as source text for the Feishu image caption. Translate the complete original caption into Chinese, preserve the figure number, subfigure labels, symbols, method names, dataset names, and important English technical terms when needed, and write it into the native image caption / description, e.g. 图 2｜完整中文图注：....
• Official HTML is also a valid caption source. For arXiv HTML, publisher / conference HTML, and official project pages, search the page's figure / figcaption, nearby figure labels, image alt text, and visible figure descriptions before using the PDF. Translate the verified original figure caption fully into Chinese for the Feishu native image caption. Do not shorten it to a title such as 图｜GS-IR overview, 图｜pipeline, 图｜teaser, or a self-written summary. Do not use unrelated page prose as a figure caption unless it is clearly tied to that exact figure.
• A finished paper-card image caption must be the complete Chinese translation of the source figure caption. It is incomplete if it only contains a figure title, method name, local filename, English overview phrase, or a brief label without the caption content. If Feishu native caption length becomes a real limitation, keep the native caption as and place the full Chinese translated caption in the immediately following paragraph.

Meeting Notes

When organizing dated research-group meeting pages in Feishu, use the user's dated Feishu wiki page under Meetings as the durable destination. Do not create or keep full meeting content in the local Obsidian vault unless the user explicitly asks. Keep the finished page structure and section order stable across meetings; only the input layout and evidence sources may change.

Input layout (current)

Expect this incoming layout before organization:

• Main dated page = the user's personal notes (PDF links, screenshots/figures, short insights, live thoughts). The title may still be a bare date such as 20260818.
• Child files / pages = Qwen / 千问 exports, typically 原文_*.docx (timestamped transcript) and 纪要_*.docx (structured summary, often with one overview figure). Older meetings may still use Doubao / 豆包 transcript files; treat them as the same raw-material class.

Do not leave personal notes only on the main page after organization. Before overwriting the main page with the report:

1. Create a wiki child page named notes under the dated meeting page if it does not already exist.
2. Move / copy the main-page personal notes into that notes child, preserving native images, links, and wording.
3. Keep the Qwen 原文 / 纪要 children (or legacy Doubao transcript) in place; do not delete them.

Evidence priority

• Personal notes (notes) are primary for importance, paper links, figures, live thoughts, teacher feedback, and intended interpretation.
• Qwen 纪要 is the preferred structural draft for agenda segmentation, TODOs, and high-level claims. Prefer it over rebuilding the whole summary from the transcript alone.
• Qwen 原文 (or Doubao transcript) is secondary evidence for chronology, missing discussion details, exact wording, speaker-flow reconstruction, and verifying or correcting the 纪要.
• If personal notes conflict with Qwen materials, trust the personal notes first. If 纪要 and 原文 conflict, prefer 原文 for factual wording and mark uncertain 纪要-only claims as 转写疑似 / 待核验 rather than turning them into facts.

Finished page contract

• Name dated meeting pages with a zero-padded date plus short topic keywords, following sibling-page style: YYYY-MM-DD <topic keywords>, for example 2026-06-30 3D场景编辑实验复盘. Do not leave the page as a bare date such as 2026-6-30 / 20260818 unless the user explicitly asks. Infer the topic keywords from the personal notes, Qwen title, PDF links, or dominant discussion topic; keep the H1 aligned, e.g. <page title>｜组会整理报告. After renaming or overwriting, verify both the document title and the Wiki node title.
• Write the organized report on the dated main page. Preserve raw materials via links and/or dedicated sections; do not delete the notes child or the Qwen/Doubao children.
• Use this default report structure (do not reorder or rename these sections): 组会整理报告, Paper Cards, 保守纪要, 讨论脉络 / 老师反馈, 会后头脑风暴, TODO, 原始材料：个人笔记, 原始材料：千问纪要与原文 (legacy pages may still say 原始材料：豆包转写).
• Near the top of 组会整理报告, insert the Qwen 纪要 overview figure when present, with a Chinese caption that states it comes from the Qwen meeting summary. This is content supplementation to the stable structure, not a new section.
• Build the meeting summary from personal notes + Qwen 纪要 + Qwen 原文 together. Do not regenerate the whole summary from the transcript alone when a usable Qwen 纪要 exists; use the 纪要 as the skeleton and the 原文 / notes to correct, deepen, and ground it.
• For a paper-discussion meeting, organize the analytical layer as a mechanism interrogation: concrete bottleneck, strongest version of the authors' argument, key assumptions, design-to-bottleneck causal map, decisive evidence, alternative explanations, counterfactual module removal, failure boundary, and the next discriminating question. Preserve the meeting's actual chronology and raw materials, and use a compact table, flow, or a few meaningful subheadings only when the source supports them; do not manufacture nine empty sections. Distinguish author claims, speaker claims, experimental support, and organizer inference.
• For papers mentioned in the personal notes, Qwen materials, or transcript, create or normalize paper cards using paper-card-delivery as the canonical content standard. Use the user's provided PDF links and figures when present, preserve image dimensions with full-detail metadata, and mark missing Dataset, , , , or as unless official sources have been checked.

Legacy Single Paper Deep Dive

New deep dives are maintained in Notion, not Feishu. This section exists only for explicit legacy-page repair or a user-requested Feishu migration; follow paper-deep-dive as the canonical content contract.

When the user explicitly asks to repair or create a Feishu deep dive, use the user's Feishu document library. Otherwise route new deep dives to Notion through notion-doc-workflow.

• Use paper-deep-dive as the canonical content and completion standard; this section only maps that contract to Feishu hierarchy, native blocks, and read-back verification. If any analytical rule here conflicts with paper-deep-dive, the canonical skill wins.
• Put mechanism interrogation, evidence-boundary analysis, counterfactual predictions, and alternative explanations in the analytical main entry / close-reading artifact. Keep 英文原文稿 and the complete Chinese translation source-faithful; do not insert reviewer commentary into either manuscript artifact.
• Treat any single-paper deep dive request as the full deep-dive workflow by default. Do not downgrade it to a quick summary, paper card only, or close-reading note only unless the user explicitly asks for a lighter output.
• Feishu single-paper deep dives default to a fixed parent-plus-three-child structure. Do not collapse the English original manuscript, complete Chinese translation, and close-reading notes into one page.
• The required child deliverables are 英文原文稿, 原文译稿 / 完整中文稿, and 中文精读稿.
• 英文原文稿 is the paper's original English text in source order. It is usually produced from the MinerU conversion draft, then checked against official HTML / LaTeX / PDF. It must preserve figure/table positions, formulas, captions, appendices, body citation markers, and a numbered References section. It is the working source for translation and can be deleted after translation if the user later asks.
• 原文译稿 / 完整中文稿 is the complete faithful Chinese manuscript. It preserves the source paper's section order, paragraph correspondence, formulas, figure/table positions, body citation markers, captions, numbered References section, and layout structure as much as Feishu allows. It also requires accurate terminology: important terms and proper nouns should be translated as 中文（English term） on first use or where clarity is needed, while method/model/dataset names and mathematical symbols remain unchanged. Avoid leaving dense English technical terms untranslated in ordinary Chinese prose.
• 中文精读稿 is an analytical Chinese reading guide. It follows the source paper's original section order by default: Abstract, numbered main-paper sections, named subsections, conclusion, then appendices / supplementary material. Do not reorganize the close-reading page into a purely thematic guide unless the user explicitly asks for a theme-based reader.
• If any required child deliverable cannot be produced because the source PDF is inaccessible, parsing fails, the official HTML is unavailable or incomplete, licensing/copyright constraints apply, or the document is too long for the current tool path, stop and tell the user what is blocking completion. Do not silently downgrade to a simplified reader or mislabeled excerpt page. Continue only after the user chooses an acceptable fallback or provides a source that can be processed.

Formula / Equation Handling

For paper deep dives and complete manuscript pages, formulas are source-fidelity content, not prose to paraphrase.

• Extract formulas from the official full-paper source before writing. For arXiv papers, prefer arXiv HTML / LaTeX source because it usually preserves MathML, TeX annotations, equation IDs, and numbering; use the PDF or a structured PDF parser only as fallback. Do not reconstruct formulas from collapsed Feishu plain text or OCR text when the official formula source is available.
• Preserve mathematical structure in LaTeX: subscripts, superscripts, hats, dots, norms, fractions, sums, products, matrices, Greek symbols, calligraphic symbols, equation numbers, and variable names. Translate surrounding prose, but do not translate variable identifiers or LaTeX commands.
• Preserve inline formulas as source-fidelity content, not just displayed equations. Inline variables, operators, compact expressions, loss names, author references to equations, and symbolic phrases such as $S$, $G$, $l(S)$, $\bm{x}^{n}$, or $\mathcal{L}_{\text{RGB}}$ must remain inline LaTeX. Do not flatten them into ordinary text, translate them into Chinese words, wrap them in backticks, or rebuild them from Feishu/OCR plain text.
• During translation, protect all inline and displayed formulas with non-translatable placeholders, translate only the surrounding prose, then restore the exact TeX from the official source. If using arXiv HTML, prefer each math.ltx_Math / MathML alttext or TeX annotation for inline formula source; verify the restored count and representative samples after translation.
• In Markdown sources for Feishu import, use $...$ for inline variables and $$...$$ for display equations. Keep display equations on their own lines with blank lines before and after. Do not wrap formulas in backticks or code fences unless explicitly creating a raw-LaTeX fallback section.
• In Feishu XML, display equations must be centered by default: wrap standalone equation blocks as <p align="center"><latex>...</latex></p>. Keep inline formulas inside normal prose paragraphs; do not center inline variables or compact symbolic phrases that are part of a sentence.
• In 中文精读稿 / close-reading pages, use inline math $...$ for symbols, variables, operators, and compact symbolic expressions such as $S$, $G$, $l(S)$, or $l(S)-l(G)$. Do not use inline code backticks for paper notation. Use plain prose for English technical terms unless they are part of a mathematical expression.
• Preserve equation numbering with \tag{n} inside display math. Do not emulate equation numbers with or plain text unless the user explicitly requests a fallback after confirming Feishu cannot render . Keep references such as aligned with the original paper.

Research Map Trees

When organizing a Feishu survey / research-map page, use a parent-page plus subpage structure by default:

• Use survey-builder as the canonical source for literature-tree, challenge-insight, mechanism-comparison, and research-entry-point semantics. This Feishu section only controls native mind-map rendering, hierarchy, image/block preservation, and read-back verification; do not weaken or duplicate the survey's mechanism-evidence audit here.
• Treat the user's Feishu page 如何构建literature tree（如何进行literature review，构建novelty tree和challenge-insight tree） as the canonical method/example for literature organization and novelty discovery: https://gxt1fwqtrod.feishu.cn/wiki/TbpBwmANXiXKQVkr38scb1tKnpq (doc token LC0WdpnZ3oUHjCxAWipcWvYSnac). When building or revising literature trees, novelty trees, challenge-insight trees, or research-map pages, read/reference this page first unless the user gives a more specific template.
• Use its novelty taxonomy when organizing papers:
  • Type 1 novelty: seminal work for a milestone task.
  • Type 2 novelty: seminal work for a novel pipeline or representation.
  • Type 3 novelty: seminal work for a novel module.
  • Type 4 novelty: module-level improvement to an existing pipeline.
• Build Literature Tree nodes in this order: collect papers in the same direction, identify milestone tasks and their first/seminal papers, group papers by milestone task, identify representative pipelines/representations and their first/seminal papers, subdivide by module-level novelty, then add or revise milestone tasks as field understanding improves.
• Build Challenge-Insight Tree nodes from the semantics defined by survey-builder: challenge/failure mode, competing explanation, proposed insight/mechanism, representative papers, decisive evidence, unresolved alternative, and remaining gap. Keep only literature-supported depth and do not inflate every branch with empty labels.
• The parent page is a concise survey hub. It should contain summary-level content only: research question, scope, key takeaways, recommended route, links to subpages, and a short status / TODO list.
• Create a dedicated subpage for editable survey trees. This page should include the literature tree, challenge-insight tree, and any method / task / benchmark trees needed for navigation.
• Create one dedicated Paper Cards subpage for the survey. This page is a browsable collection that contains many paper cards in sequence. Do not create one child page per paper unless the user explicitly asks for per-paper pages.
• Create a dedicated subpage for the full survey report. This is usually the long report copied from ChatGPT Deep Research or another long-form source. Preserve it as the source report page, then distill only the summary into the parent page.

When a Feishu research-map page asks for a literature tree, challenge-insight tree, or native mind map:

• Keep an editable nested outline in the Feishu page, because static images are hard to revise.
• If the user asks for 飞书原生思维导图, 原生思维导图, or says a Mermaid/flowchart rendering is not a real mind map, do not use Mermaid flowchart LR as a substitute.
• Convert the tree to PlantUML mind map syntax (@startmindmap ... @endmindmap) and write it into a Feishu board block (block_type=43) with docs +whiteboard-update --input_format plantuml --overwrite.
• Default visual style means Feishu's actual native default mind-map style, not a custom DSL card diagram that merely looks similar. Keep the imported mind_map node types and Feishu default styling unless the user explicitly asks for a designed/custom-colored diagram.
• When there are many first-level branches and the user asks for balanced left-right distribution, first import with PlantUML, then verify with whiteboard +query --output_as raw. If Feishu stores every first-level child under right_children, patch the raw native mind-map JSON instead of redrawing custom nodes: set mind_map_root.left_children / right_children, set each first-level node's mind_map_node.layout_position to left or right, adjust coordinates as needed, then write back with whiteboard +update --input_format raw --overwrite.
• Avoid the PlantUML left side directive for Feishu board imports because Feishu's PlantUML parser rejects it.
• Use richer semantic colors only when the user explicitly asks for more color, or when the map has many otherwise indistinguishable groups. Do not use arbitrary rainbow coloring; keep the same meaning-color mapping across pages.
• Do not rely on PlantUML inline color syntax such as ++[#LightBlue] Branch for Feishu board imports; Feishu's PlantUML parser may reject it. Prefer DSL / OpenAPI nodes when color is required.
• Optional semantic color mapping for survey / field investigation maps:
  • Research goal / problem framing: light blue.
  • Scene / data / input state: light green.
  • Agent / body / representation state: light yellow.
  • Task / language / goal condition: light pink.
  • Interaction / object / environment dynamics: wheat or peach.
  • Method family / model architecture: lavender.
  • Evaluation / benchmark / metrics: light gray.
  • User's current research route / opportunity: gold.

Investigation Pages

When organizing a Feishu Investigation page from a technical talk, research-direction clipping, frontier lecture, or route-evidence material:

• Keep the parent page as the distilled investigation note: source metadata, one-sentence conclusion, core thesis, technical route, route relevance, open questions, and a compact diagram when useful.
• Create a child page named Paper Cards or <Parent Title>｜Paper Cards when the talk/report mentions concrete papers, systems, benchmarks, or project pages that support the route.
• The Paper Cards child page is a collection page containing many paper cards in sequence. Do not create one child page per paper unless explicitly requested.
• Include all clearly mentioned papers from the source material, grouped by the talk's actual narrative arc. If a title is uncertain because the source is an imperfect transcript, mark it as a口播线索 and do not fabricate metadata.
• Use paper-card-delivery as the fixed paper-card content standard. PDF must point directly to a PDF when available.
• Prefer official project pages, arXiv pages, CVF/OpenReview pages, author pages, or official GitHub repositories. Avoid relying on generic search snippets when primary sources exist.
• After writing, verify the parent-child hierarchy and that the paper-card child page has real cards, not placeholders.

Useful Commands

Show document commands:

~/.local/bin/lark-cli docs --help
~/.local/bin/lark-cli docs +fetch --help
~/.local/bin/lark-cli docs +update --help

Insert an image as a native Feishu media block:

~/.local/bin/lark-cli docs +media-insert \
  --as user \
  --doc '<document-token-or-url>' \
  --file '<local-image.png>' \
  --selection-with-ellipsis '<nearby text>' \
  --before \
  --align center \
  --caption '图 1｜完整中文图注：<完整翻译论文原始 caption>'

Add or update a caption on an existing image block without re-uploading the image:

~/.local/bin/lark-cli api PATCH \
  "/open-apis/docx/v1/documents/<docx_token>/blocks/batch_update" \
  --as user \
  --data '{"requests":[{"block_id":"<image_block_id>","replace_image":{"token":"<existing_image_file_token>","align":2,"scale":<existing_scale>,"caption":{"content":"图 1｜完整中文图注：<完整翻译论文原始 caption>"}}}]}'

Create a gray callout:

<callout emoji="📄" background-color="light-gray" border-color="gray">
  <h3>Title</h3>
  <p>Body</p>
</callout>

Search docs, wiki, and spreadsheet files:

~/.local/bin/lark-cli docs +search --help

Update an existing Feishu board block as a native mind map:

~/.local/bin/lark-cli docs +whiteboard-update \
  --as user \
  --whiteboard-token '<board-token>' \
  --input_format plantuml \
  --source '@mindmap.plantuml' \
  --overwrite

Inspect wiki helpers when a wiki node must be resolved:

~/.local/bin/lark-cli wiki --help
~/.local/bin/lark-cli wiki nodes --help

Run health checks:

~/.local/bin/lark-cli doctor

Safety

• Do not print or persist Feishu app secrets, access tokens, or refresh tokens.
• If inspecting ~/.lark-cli/config.json, mask keys containing secret, token, key, password, access, or refresh.
• Treat CLI writes as live document edits. Prefer narrow operations and verify after changes.
• If the CLI warns about a proxy, mention it only if it affects the task or the user asks about network/auth behavior.

Known Local Setup

• CLI path: ~/.local/bin/lark-cli
• User-local tools are added to PATH from ~/.zshrc.
• Feishu/Lark CLI config lives under ~/.lark-cli/.