Feishu Doc Workflow

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 图 N｜完整图注见下方 and place the full Chinese translated caption in the immediately following paragraph.
• Do not invent caption content that is not visible in the provided image or verified from the official paper / project page. If the screenshot has no readable caption and no official caption has been checked, write 图注待补：需要从论文或项目页核验并完整翻译原始 caption。.
• Reuse user-captured or previously verified paper-card figures for the same paper before extracting or cropping a new one. Match by stable paper identity such as English title, arXiv ID / DOI, method name, and figure number or caption; do not rely on local filenames alone.
• When the same paper card is used on multiple Feishu pages, preserve the already approved image and Chinese caption unless a page-specific reason requires a different figure. If copying from an existing Feishu card, fetch with full detail when needed and preserve the native image block / caption rather than rebuilding the figure from the paper.
• If a user-provided screenshot should be reused across pages, keep a reusable copy under an explicit non-root library such as .tools/outputs/paper-card-figures/<paper-id-or-normalized-title>/. These retained user-captured figure assets are not disposable extraction intermediates, but OCR text files, processing outputs, and task-local duplicates must still be deleted after Feishu verification.
• For new images inserted with docs +media-insert, pass --caption '<Chinese caption>'; this writes the native Feishu image caption, not just a normal paragraph.
• Insert or preserve paper-card figures using the image's original pixel width and height. If the figure is copied from an existing Feishu page, carry over the full-detail image metadata; if it is inserted from a local/user-provided file, inspect the local file dimensions before upload and verify the resulting Feishu block keeps the same aspect ratio. Do not allow automatic square placeholders such as 512 × 512 to become the final card image size.
• If an existing paper card has multiple images in one visual row, grid, or adjacent group, preserve that relationship exactly. Do not rebuild the group, equalize image widths, alter grid ratios, or split/merge rows while normalizing text, metadata, captions, or bullet content. A same-row two-image layout is user-authored layout state, not disposable formatting.
• For existing image blocks, prefer an in-place Docx API update instead of re-uploading or reinserting the image: call PATCH /open-apis/docx/v1/documents/<docx_token>/blocks/batch_update with replace_image.token set to the existing image src / file token and replace_image.caption.content set to the Chinese caption. Fetch with --detail full first to get the image block id, token, width, height, scale, and current caption; include the existing scale in replace_image so adding a caption does not resize the image.
• Only if the native caption / description API is unavailable or fails, insert a normal Chinese caption paragraph immediately below the image and keep it visually tied to that image; mention this fallback to the user.
• If OCR or visual extraction is used to read a screenshot caption, delete OCR text files, image-processing intermediates, and temporary figure assets after the Feishu write has been fetched back and verified.
• In a Feishu paper card, place the native image block after the metadata paragraph link line (PDF｜Project｜Code) and Dataset, before the seven fixed bullet slots defined by paper-card-delivery. Do not leave the image directly under the #### title.
• If no reliable core method/process figure is available, write 配图待补：需要从论文 HTML/PDF 或项目页补充可信方法流程图；teaser / 结果展示图不能单独作为主图。 instead of inserting a questionable image, and treat the card as incomplete rather than a finished formal delivery unless the user explicitly accepts the missing figure.
• Do not leave Obsidian migration residue such as 图像： EW_IMG_...png, Image: assets/..., local file names, or local vault paths in the reader-facing Feishu page. After inserting the actual figure as a native Feishu image block, keep only the Chinese figure caption or explanation that helps the reader; remove local filename labels.
• Before syncing a paper-card source file, run a text check for first page, first-page, title page, and paper page; after syncing, fetch the Feishu page and verify those strings are absent unless they are part of normal prose.
• After syncing a paper-card page, fetch it and verify that visible body text contains no 图像：, EW_IMG, assets/, ![[, or local filesystem paths. Image block name attributes may still contain source filenames; those are acceptable if they are not visible body text.

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 = one document created by the user, normally named only with the date at first (for example 20260901). The user writes personal notes directly in this page, including PDF links, screenshots/figures, short insights, live thoughts, and questions.
• Conversation input = the user may paste the Qwen / 千问 原文 and 纪要 directly into the current chat for the organization task. This is the default raw-material source for new meetings. Older meetings may use Doubao / 豆包 material; treat it as the same raw-material class.
• Bottom of the same main page = legacy input layout only. If readable 原文 and 纪要 text is already present there, use it; do not require the user to keep raw material at the bottom for new meetings.
• Attachments or child pages = optional backups or legacy sources. DOCX attachments may be kept, but do not rely on an attachment alone when the user can provide readable text in chat.
• Attachments or child pages = optional before organization. They may exist when the user pasted DOCX files or separately organized exports, but they are not required by the incoming workflow.

When organization starts, create a wiki child page named notes under the dated meeting page if it does not already exist. Move or copy the personal notes from the top of the main page into notes, preserving native images, links, wording, and original image dimensions. Treat the 原文 and 纪要 pasted in chat as source material for the report, and embed the two readable raw texts into the dedicated 原始材料：千问纪要与原文 page for durable archival. Do not embed raw materials into the report body itself unless the user explicitly asks.

Evidence priority

• Personal notes in the notes child are primary for importance, paper links, figures, live thoughts, teacher feedback, and intended interpretation. Before that child is created, use the personal-notes region at the top of the dated main page as the source.
• 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.
• If a paper source, title, method, or result cannot be found directly, first exhaust the personal notes / notes clues: PDF URLs, screenshots, visible captions, filenames, method names, terminology, questions, neighboring notes, and the surrounding discussion context. Use those clues to identify the paper and recover source-specific information before marking anything as 待核验. Only mark a field as 待核验 after both official-source search and personal-note clue extraction have been attempted; distinguish a note-derived clue from a verified paper claim.

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. After creating notes, link to the notes child and the dedicated 原始材料：千问纪要与原文 page from the report's raw-material section. Keep the report body focused on the organized analysis; archive the conversation-pasted 原文 / 纪要 in that raw-material page. Do not delete or replace the original images, links, attachments, or existing raw material.
• 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.
• When the user pastes the meeting summary or transcript in chat, any accompanying overview image, discussion-flow image, or paper figure is also source material and may be used in the report. Treat it with the same priority as an image pasted into the dated main page: preserve the original pixel dimensions, aspect ratio, visual order, and readable caption; do not crop, square, redraw, or replace it with a generic placeholder. Place an overview image near the beginning of 组会整理报告, and place a paper figure in the corresponding Paper Card after its metadata and dataset line.
• 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.
• Treat 保守纪要 and 会后头脑风暴 differently. The conservative notes must stay grounded in the personal notes, Qwen summary/transcript, paper links, and visible figures. The brainstorm section may intentionally connect the meeting to JEPA, world models, 3DGS, avatar, long-tail learning, music generation, origami art, or other group topics, but it must be labeled as brainstorming rather than transcript fact.
• End with concrete TODOs from the meeting plus any follow-up paper-card verification tasks. Fetch after writing and verify that the report sections exist, the notes child contains the personal notes, the dedicated raw-material page contains the archived Qwen/Doubao 纪要 and 原文, image dimensions/captions are preserved, and any pre-existing child-page hierarchy did not collapse.

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.
• Use a Feishu parent/child hierarchy:
  • Parent page: the deep-dive notes. This is the main reader-facing page and should contain the paper card / metadata, one-sentence conclusion, paper positioning, technical challenge, core insight, method / pipeline breakdown, losses or training details, datasets and evaluation, key experiments and ablations, limitations, related latest progress or critique, and implications for world-model / embodied-world-model research.
  • Child page 1: English original manuscript (英文原文稿), containing the original English paper text in source order, with formulas, figure/table positions, captions, appendices, citations, and references preserved as much as Feishu allows.
  • Child page 2: complete Chinese manuscript (原文译稿 / 完整中文稿 / Full Chinese Translation), translated sentence by sentence where available and preserving formulas, figure/table placements, citations, captions, and the paper's original image order. Insert paper figures as native Feishu image blocks near their original figure captions whenever reliable official images are available. Follow the Formula / Equation Handling rules below; do not rebuild formulas from already-flattened Feishu plain text.
  • Child page 3: Chinese close-reading page (中文精读稿), with section-level reading notes following the paper's original structure, plus local method decomposition, figure/table guide, key assumptions, experiments, limitations, and research implications inside the corresponding original sections.
• At the beginning of paper-related Feishu documents, use the same compact link style as paper-card-delivery metadata instead of verbose source lists: [PDF](...)｜[Project](...)｜[Code](...), with missing items written as w/o. project page, w/o. verified code, etc. Keep the link row near the title / metadata block and avoid separate long URL paragraphs unless the user explicitly asks for a source audit.
• Before writing the notes, read/parse the paper and search for current context when needed: arXiv/OpenReview/conference page, project page, GitHub, author page, follow-up papers, critiques, benchmarks, and directly related concurrent work.
• Prefer MinerU for PDF-to-Markdown parsing. On this machine, use $WORLD_MODEL_VAULT/.tools/mineru-md.sh first, backed by $WORLD_MODEL_VAULT_MINERU_BIN (mineru 3.3.1 verified). Use Docling / Marker / PyMuPDF / pdfplumber only if MinerU fails or there is no PDF.
• Treat MinerU output as a conversion draft, not the final authority. For arXiv papers, check the MinerU draft against arXiv HTML whenever available before publishing Feishu pages. Verify section order, paragraph continuity, formulas, figures, captions, tables, appendices, citations, and references. If arXiv HTML is unavailable or incomplete, use official LaTeX source, publisher HTML, or the official PDF as the authority.
• References must be repaired before publishing. Do not leave bibliography entries as fragmented paragraphs or bullets; use a numbered bibliography, keep one reference per numbered item, and preserve body citation markers so the manuscript reads like the original paper.
• Do not upload or store a PDF when a stable arXiv PDF exists, unless the user explicitly requests a PDF copy or the source is unstable/non-arXiv.
• After the Feishu deep dive is done, distilled knowledge may be summarized into Feishu knowledge pages. Only content still judged long-term important after distillation should be added back to Obsidian.
• Verify final Feishu hierarchy: the parent notes page has exactly the intended child pages for 英文原文稿, 原文译稿 / 完整中文稿, and 中文精读稿, and the parent page links to them.

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 \qquad(n) or plain text unless the user explicitly requests a fallback after confirming Feishu cannot render \tag. Keep references such as 式 (4) aligned with the original paper.
• Keep formulas near their original paragraph and section. Do not move all formulas into an appendix unless the source page is only a summary rather than a full manuscript page.
• After writing, fetch the Feishu page and verify formula fidelity. Check both inline and displayed formulas: count <latex> / $...$ blocks when possible, inspect samples across early, middle, appendix, formula-heavy sections, and numbered equations, and confirm formulas did not degrade into ordinary text such as L_render = lambda ||..., lose _ / ^ structure, merge with surrounding prose, or become translated words.
• If Feishu Markdown cannot render a formula reliably, use an explicit fallback: keep the exact LaTeX source in a labeled 公式 LaTeX 源 paragraph or block and, for important equations, insert a rendered equation image with a Chinese caption. Mark this as a rendering fallback, not as the preferred final form.
• Before finishing, report any formulas that remain fallback-only or unverified. Do not claim a deep dive is complete when important equations are visibly flattened, malformed, or missing.

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: <FEISHU_OR_LARK_URL> (doc token <DOC_TOKEN>). 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.
• The parent page should link to all three subpages and make their roles obvious: Tree Maps, Paper Cards, and Full Survey Report or equivalent Chinese titles.
• If the user provides an existing long report page, treat that page as the Full Survey Report child page when possible; do not leave the parent page as an overlong pasted report.
• Do not create placeholder survey artifacts. Before writing the parent summary, tree maps, or paper-card page, fetch and read the full survey report, identify the actual task/method/benchmark/research-gap structure, and write content from that understanding.
• The Paper Cards subpage must contain real, report-grounded cards for the important papers mentioned in the survey, usually grouped by theme, method family, or reading priority. Avoid 待补 placeholders except for genuinely missing external links or figures after a best-effort check; in those cases, state what is missing specifically.
• Paper-card content and verification are governed by paper-card-delivery. This feishu-doc-workflow skill must not redefine the paper-card source order, metadata schema, bullet slots, image-selection contract, sorting rules, or validators.
• Before creating, normalizing, auditing, or syncing any paper card, read and follow paper-card-delivery completely. In case of conflict, paper-card-delivery wins for content and card structure; this skill only adds Feishu hierarchy, native-image insertion/preservation, and post-write verification requirements.
• Use the canonical paper-card-delivery format: exact official English title, compact metadata paragraph, direct PDF link, Dataset:,

…(truncated)