Feishu OpenClaw Paper Manager

---

name: feishu-openclaw-paper-manager

description: Design or implement a paper-management workflow built on a Feishu bot plus OpenClaw. Use when the user wants to ingest papers from Feishu messages, save PDFs or source links into a Feishu cloud-docs paper folder, maintain a searchable multi-dimensional table of paper metadata and reusable tags, or evolve the tag taxonomy after every 50 newly added papers.

---

# Feishu OpenClaw Paper Manager

Use this skill when the task is to design, review, or implement a paper-management agent that runs through a Feishu bot and OpenClaw.

Primary objective

Build a workflow with three durable outputs:

1. A cloud-docs `paper` folder that stores the paper asset or an index document for the source link.

2. A Feishu multi-dimensional table that stores normalized paper metadata.

3. A taxonomy iteration loop that improves labels whenever total paper count crosses `50`, `100`, `150`, and so on.

Workflow

Follow this sequence:

1. Map the ingestion sources from Feishu messages.

2. Normalize each paper into one canonical record.

3. Save or register the paper in the cloud-docs `paper` folder.

4. Generate summary and reusable multi-label tags.

5. Write the record into the multi-dimensional table.

6. Check whether the total record count has reached a multiple of 50.

7. If yes, run taxonomy refinement and backfill historical rows.

Ingestion rules

Treat these as valid paper inputs:

For every incoming item:

1. Extract the raw message URL, sender, timestamp, and all detected paper candidates.

2. Resolve whether the message refers to a new paper or an existing one.

3. Create exactly one canonical paper record per paper.

Deduplication priority:

1. DOI

2. arXiv ID or OpenReview forum ID

3. normalized title

4. source URL fingerprint

If a duplicate exists, update missing fields instead of creating a new row.

Storage model

Always separate binary storage from metadata storage:

When a PDF is available:

When only a link is available:

Required table fields

Create or expect these fields in the Feishu multi-dimensional table:

Use multi-select fields for all `tags_*` columns so users can filter and search by labels directly in Feishu.

Tagging policy

A paper can have multiple tags, but tags must stay reusable. Do not create a new free-form label when an existing reusable label is close enough.

Use a layered taxonomy:

Keep tags short, lowercase, and singular where possible.

Prefer this decision rule:

1. reuse an existing tag if it is at least 80 percent semantically correct

2. add a synonym mapping instead of a brand-new visible tag when possible

3. only introduce a new visible tag if it will likely apply to at least 5 papers in the next 100 rows

See `references/tag-taxonomy.md` for the starter taxonomy and merge rules.

One-line summary policy

The `summary_one_line` field must answer:

Avoid hype, citation-style phrasing, and long clauses.

Taxonomy iteration loop

Whenever the table row count reaches a multiple of 50, run a taxonomy review pass.

The review pass must:

1. export or inspect all existing tags and their frequencies

2. identify sparse tags, duplicates, synonyms, and overloaded tags

3. propose a new taxonomy version that improves reuse and filtering quality

4. map old tags to new tags

5. backfill historical rows

6. mark affected rows with the new `taxonomy_version`

7. produce a short change log explaining merges, splits, and renamed tags

Optimization goals:

Do not relabel everything from scratch unless the old taxonomy is clearly broken. Prefer merge-and-backfill over wholesale replacement.

Output contract

When asked to design the system, return:

1. end-to-end workflow

2. Feishu table schema

3. tagging strategy

4. taxonomy iteration logic

5. implementation notes for Feishu bot and OpenClaw boundaries

When asked to implement or review code, anchor decisions to:

Boundary between Feishu bot and OpenClaw

Default division of responsibility:

If the user has an existing architecture, preserve it and only adapt the workflow.

Development contract

When the user wants implementation guidance, assume this integration shape unless the project already defines another one:

1. Feishu bot receives the event and verifies the request.

2. Feishu bot converts the raw event into a normalized ingestion payload.

3. Feishu bot calls an OpenClaw workflow entrypoint with that payload.

4. OpenClaw performs enrichment, storage, classification, and table updates.

5. OpenClaw returns a structured result for user-visible confirmation.

6. Feishu bot posts a success, duplicate, or failure message back to the conversation.

Design the integration around these engineering constraints:

Use `references/api-contracts.md` for payload shapes and responsibility boundaries.

Use `references/event-flows.md` for event sequences and retry behavior.

Feishu-side implementation expectations

On the Feishu side, prefer these components:

The Feishu bot should emit one normalized payload per detected paper candidate, not one per message if a message contains multiple papers.

Before calling OpenClaw, the Feishu side should:

1. verify event authenticity

2. extract message metadata

3. collect attachment metadata and URLs

4. collect raw hyperlinks in the message body

5. attach a stable `event_id` and `message_id`

6. include enough source metadata for later retries without rereading the original message when possible

OpenClaw-side implementation expectations

On the OpenClaw side, prefer these stages:

1. ingest payload validation

2. paper candidate normalization

3. metadata enrichment from PDF or source page

4. duplicate lookup

5. cloud-docs write

6. one-line summary generation

7. multi-dimensional tagging

8. table upsert

9. taxonomy-threshold check

10. taxonomy review workflow when threshold is hit

OpenClaw should treat the table as an upsert target, not append-only storage.

For duplicates:

Taxonomy review trigger contract

The threshold is based on canonical non-duplicate paper rows, not raw messages.

Trigger a taxonomy review only when:

Persist a review checkpoint such as `last_review_count = 100` or `taxonomy_version = v3` so retries do not rerun the same migration.

Output expectations for implementation tasks

When implementing code, prefer returning these artifacts:

1. module boundaries

2. payload schemas

3. idempotency rules

4. event sequence

5. failure handling and retry rules

6. sample success and duplicate responses

When reviewing code, check specifically for:

Failure policy

The default failure strategy is:

If partial writes are possible, require compensating logic or a resumable reconciliation job.

Resources