Research Doc Workflow

Research Document Workflow

Core Contract

Keep research content standards independent from storage platforms. Use one canonical Markdown-first document for the shared body: headings, paragraphs, lists, block quotes, links, tables, code blocks, and LaTeX formulas should remain the same unless the target demonstrably requires a small conversion. The task-specific skill owns what the document means and which sections are required; this skill selects the destination backend, loads the matching platform adapter, applies only the necessary platform deltas, performs the write, and verifies the durable result.

Do not create separate Feishu, Notion, and Obsidian versions of the same content skill or template. Maintain one Markdown structure and three thin delivery adapters (feishu-doc-workflow, notion-doc-workflow, obsidian-doc-workflow) so field definitions, evidence standards, wording, and acceptance gates cannot drift.

Platform Resolution

Resolve the target in this order:

1. Explicit user instruction (写到飞书 / 写到 Notion / 写到 Obsidian/vault).
2. URL or path in the request (feishu.cn / larksuite.com → Feishu; notion.so → Notion; vault .md path / WorldModelVault folder → Obsidian).
3. Platform of an existing durable document being updated (never silently migrate).

The user normally supplies a link or an explicit destination. If none of the above resolves a single platform, ask one concise destination question. For a new deep dive without an explicit destination, use Notion. Do not silently duplicate across platforms.

Never silently migrate, duplicate, or delete an existing durable document. A platform change requires an explicit target or a user-approved migration task.

Backend Router

After resolving the platform, also load the matching adapter:

Feishu / Lark → feishu-doc-workflow

• Wiki resolution, fetch-before-write, narrow block edits, native images/captions/formulas/whiteboards, hierarchy preservation, and fetch-after-write verification.
• Use lark-whiteboard only when an editable Feishu whiteboard or mind map is required.
• New deep dive work is not routed to Feishu; use Notion as the durable target. This route remains for non-deep-dive Feishu documents and explicit legacy repairs.

Notion → notion-doc-workflow

• Search/fetch the destination before updating. Resolve the exact parent page, database, or data source and inspect required properties before creating records.
• Prefer native Notion headings, callouts, equations, image captions, tables, page links, relations, and database properties.
• Do not paste Obsidian frontmatter, Obsidian callout fences, Feishu block artifacts, or absolute vault paths into reader-facing Notion content.
• If Notion tools are unavailable, report that Notion must be connected. Do not claim that a page was written and do not silently redirect to Feishu or Obsidian.

Obsidian / Markdown → obsidian-doc-workflow

• Inspect the target folder, neighboring notes, frontmatter schema, attachment convention, and link style before editing.
• Use YAML frontmatter, > [!type] callouts, [[wikilinks]], relative assets, and $...$ / $$...$$ as required by the vault.
• Also use llm-wiki when the task includes wiki ingestion, provenance, atomic notes, indexes, or Research-Wiki placement. Format/write verification still belongs to obsidian-doc-workflow.

Small Platform Deltas

Assume Markdown parity first. Convert only the features that are not represented consistently:

Do not perform platform-specific rewrites merely for visual styling. Require semantic parity: the same Markdown body, source claims, fields, section order, captions, formulas, links, and completion status must survive; only the small deltas above may differ.

Shared Write Workflow

1. Read the task-specific content skill and identify its non-negotiable semantic contract.
2. Resolve the target platform and exact destination. Preserve the current platform for existing documents.
3. Load the matching *-doc-workflow adapter.
4. Fetch or read the current document, hierarchy, properties/frontmatter, linked assets, and nearby conventions.
5. Prepare one canonical Markdown draft: title, metadata, sections, lists, tables, callouts, formulas, figures/captions, links, and child artifacts.
6. Preserve the Markdown directly where possible. Convert only unsupported callouts, captions, properties/frontmatter, hierarchy, diagrams, citation chrome, or upload references to native target primitives.
7. Make the narrowest safe update. Preserve user notes and trusted existing media unless replacement is requested.
8. Re-fetch or re-read the durable result. Run content and platform validators, then report the actual destination and any unsupported native feature.

Imported PDF Translation Repair

When a PDF translated by pdf2zh-next has been manually imported into Notion or Feishu, classify it as a draft conversion and route it through the task-specific content skill's repair gate. The adapter must preserve the imported media where reliable, but repair platform representation: page title, opening links, heading hierarchy, paragraph breaks, inline/display equations, native figure captions, table layout, references, and citation URLs. For numbered paper headings, derive the native heading depth from the number (2 → top level, 2.1 → subsection, 2.1.1 → sub-subsection) and use one punctuation convention throughout: default 2. Title / 2.1. Subtitle, or preserve a consistently punctuation-free source style. Manual import is a valid input path; it is not a completion signal. Verify by fetching or re-reading the durable page after repair.

For imported author metadata, write email addresses as ordinary visible text and do not intentionally add Markdown or mailto: links or code formatting. Notion may auto-link a bare email automatically. Only for the opening resource block of a deep-dive Chinese manuscript, omit a standalone 来源 label and make each link's visible text equal to its URL; do not apply this to English manuscripts or general research documents. For imported tables, explicitly check for garbled characters, broken rows/columns, duplicated pipe-table remnants, repeated cell fragments, and captions fused to table data; preserve one authoritative native table and add an official PDF/HTML screenshot when editable extraction is unreliable.

Migration Rules

• User default scope: “迁移” / “migrate” includes the specified source page and all descendant pages, recursively, even when the user supplies only the root URL. Do not ask whether to include children. Narrow this scope only when the user explicitly says “仅此页” / “不含子页面” or specifies another boundary. This applies to migration, not ordinary page edits or repairs.
• Before writing, enumerate the actual source hierarchy through the platform's child-node/page listing, following pagination at every depth. A body-only fetch or absence of child links in the body does not prove that a page has no children. Traverse descendants, not arbitrary linked pages outside the subtree; track source node IDs to avoid duplicate traversal or shortcut cycles.
• Keep a source-to-destination page map (source ID/URL, source parent, destination ID/URL, verification status). Recreate the source parent-child structure: when asked for a new child page under a destination, place the source root there and nest its descendants beneath that new page. On retries, reuse verified mapped pages instead of creating duplicates; do not treat title alone as identity.
• Verify every migrated page against its source: body, images, captions, tables, formulas, links, and paper-card formatting where present. Preserve each page's source URL at its opening and use the page map for links between migrated pages. Reconcile the enumerated source tree with the destination tree, including parent relationships, not just page counts. Report migrated/verified counts and any excluded, inaccessible, unsupported, or failed nodes; incomplete enumeration or any unverified descendant prevents claiming the whole migration is complete.
• Treat migration as copy-and-verify by default. Do not delete the source document unless the user explicitly asks after the destination passes verification.
• Preserve source URLs, original creation context, authorship, dates, citations, captions, formulas, attachments, and child-page relationships.
• Convert platform-only constructs explicitly. Examples: Feishu whiteboard to an exported image plus editable outline for Notion/Obsidian, Notion database properties to Obsidian frontmatter, or Obsidian wikilinks to Notion page links.
• Record any lossy conversion. Do not call a migration complete when formulas, figures, captions, tables, or child documents were silently dropped.

Acceptance Checklist

Before declaring a document complete:

• the chosen platform matches the user's target or the existing document;
• the matching *-doc-workflow adapter was used;
• the task-specific content contract passes without platform-specific omissions;
• title, hierarchy, metadata/properties/frontmatter, section order, links, formulas, media, and captions were verified in the durable destination;
• user-authored notes and trusted assets were preserved;
• no syntax from another platform remains as reader-facing residue;
• temporary files were cleaned only after the durable copy was verified;
• the response names the platform and actual write status instead of implying a write that did not occur.