SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillswenxian

wenxian

Writing & research

View repository

Updated 10-15 21:40

About this skill

Retrieve literature and push (Cron Skill, multi-channel version)

Goal

Fix "retrieve literature -> generate summary -> push on schedule" as a reusable pipeline, rather than a one-off temporary task.

Partition data sources (locally solidified)

Prioritize the local consolidated table:

  • references/JCR2024_FQBJCR2025_merged.csv: consolidates 2024 JCR and 2025 CAS partitions (aligned by same journal name, retaining the original fields of both sides)

When necessary, refer back to the source tables:

  • references/FQBJCR2025.csv: CAS partitions (including major/minor category partitions, Top, whether OA, WoS index, etc.)
  • references/JCR2024.csv: JCR IF, IF Quartile, IF Rank (can serve as a SCI/JCR partition reference)

Upstream supplementary sources:

  • GitHub：https://github.com/yongqianxiao/share_repo/tree/master/JCR
  • Local list:references/upstream/share_repo_JCR_manifest.txt
  • Sync script:scripts/sync_share_repo_jcr.sh(pull upstream JCR/ to references/upstream_raw/）

EasyScholar open API supplement:

  • API:https://www.easyscholar.cc/open/getPublicationRank
  • Parameters:secretKey、publicationName
  • Example:
    • .../getPublicationRank?secretKey=<EASYSCHOLAR_SECRET_KEY>&publicationName=Nature
  • Current configured secretKey:<请在本地私密配置，不要写入仓库>
  • Key returned fields (data.officialRank.all）：
    • sci(SCI/JCR partition)
    • sciif(latest IF)
    • sciif5(5-year IF)
    • sciBase/sciUp/sciUpSmall(partition fields related to the CAS basic/upgraded version)
    • jci、esi、cpu and other supplementary fields

EasyScholar usage rules:

  • Default order: EasyScholar API -> local consolidated table -> share_repo upstream files (supplementary verification)
  • Request method: GET
  • Request parameters:
    • secretKey(required)
    • publicationName(required, journal name)
  • Success determination:code=200 and msg=SUCCESS
  • Failure example:code=40002(wrong Key)
  • After calling the API, the output must be marked "Source: EasyScholar API"
  • secretKey is regarded as sensitive information: in replies it may only be displayed masked (e.g. f11d...8d95), and must not be echoed in full

EasyScholar return parsing (must be followed):

  • data.officialRank: official data
    • all: all available official ranking fields
    • select: dataset fields selected by the user on the extension side
  • data.customRank: custom data
    • rankInfo: custom dataset definitions (including uuid、abbName、oneRankText...fiveRankText）
    • rank: array element format is {{uuid}}&&&{{level}}
      • first split by &&& to obtain uuid and level(1-5)
      • use uuid in rankInfo to find the corresponding dataset (abbName）
      • use level to map to oneRankText~fiveRankText
      • the final display looks like:DUFE B

Suggested priority display for official fields:

  • Partition core:sci、ssci、sciBase、sciUp、sciUpSmall、sciUpTop
  • Metric core:sciif、sciif5、jci、esi
  • Early warning information:sciwarn
  • China Pharmaceutical University tiering:cpu(displayed by default)
  • Other fields (such as swufe/cufe/ccf/cssci/ahci) are displayed as needed, and full output is not mandatory

Partition display strategy (must be executed):

  • Prioritize displaying the "latest standard": mainly based on what EasyScholar returns.
  • At the same time, provide a "highest partition" summary:
    • CAS: in sciBase/sciUp/sciUpSmall/sciUpTop , take the best result and annotate the source field.
    • SCI/JCR: in sci/ssci , take the best Q category result (Q1 is highest).
  • If multiple sources conflict, retain the conflict description and do not silently overwrite.

Applicable scenarios

  • The user says "Refer to the MDRGNB standard and make a daily/weekly/monthly report on a certain topic"
  • The user issues in natural language: "Help me push the literature on xx to xx at xx:xx"
  • The user requests "push to Feishu/WeCom/QQ/Telegram every day at xx:xx"
  • The user requests adding fields: journal name, CAS partition, SCI partition
  • The user reports "the task shows delivered but the full text is not received"

Standard process (must be followed in order)

  1. Confirm parameters

    • Topic (e.g., MDRGNB, liver cancer/HCC)
    • Frequency (daily/weekly/monthly) and time zone (default Asia/Shanghai)
    • Push time (use default values when the user does not specify: daily report 08:00, weekly report 08:00, monthly report 08:00)
    • Push channel and target ID (feishu/wecom/qqbot/telegram)
    • Output template (daily/weekly/monthly report)

  2. Create/update cron task

    • sessionTarget: "isolated"
    • payload.kind: "agentTurn"
    • timeoutSeconds: 1200(default)
    • Default linkage rule (must be executed): when a daily report task is successfully created for the first time, weekly and monthly report tasks for the same topic are automatically created as well (unless the user explicitly disables this).
    • Independent enabling is supported: weekly/monthly reports can be created and run separately without relying on "starting the daily report first".

  3. Three-phase pipeline (borrowed from daily-paper-skills)

    • Daily report:
      • Phase A (Fetch): search PubMed + initial screening and deduplication
      • Phase B (Review): generate structured TopN, 10 questions, four-dimensional scoring, evidence level
      • Phase C (Deliver): push according to channel rules and record the sending result
    • Weekly/monthly report:
      • Phase A (Collect): collect the "already produced daily report" results within the corresponding period (prefer reading the daily report archive)
      • Phase B (Synthesize): perform aggregate statistics, topic merging, and analysis of trends and evidence strength changes based on the daily reports
      • Phase C (Deliver): push according to channel rules and record the sending result

  4. Fix the "search + output structure"

    • Daily report search source: PubMed (default)
    • The daily report must automatically expand the user's colloquial topic "xx literature" into an executable PubMed query (Boolean logic + synonyms + abbreviations)
    • By default, weekly/monthly reports do not directly rerun the full search; they prioritize automatic summarization based on the daily report archive; supplementary search is triggered only when the daily report is missing
    • Time window: default last 24 hours (daily report)/last 7 days (weekly report)/last 30 days (monthly report); fill-in window default last 7 days (daily report) or last 30 days (weekly/monthly report)
    • TopN: daily report default Top3 (actual if fewer); weekly report default Top10; monthly report default Top20 (all can be modified according to user requirements)
    • It is recommended to keep a historical deduplication file (such as .history.json or topic_history.json) to avoid pushing the same article repeatedly on consecutive days

  5. Fix "push reliability"

    • In the payload prompt, require the use of message tool to actively send
    • WeCom long texts must be distributed in 2-3 segments (each segment <=1200 characters)
    • Feishu/QQ/Telegram can send a single message by default; if the body is too long, also switch to segmented sending.
    • Segment marker:第1/3段、第2/3段、第3/3段
    • If the payload already explicitly contains message.send, then cron delivery.mode is set to none

  6. Verification

    • cron.run Manually trigger once
    • cron.runs Check status and deliveryStatus
    • The user confirms whether the full text is visible on the target end.

  7. Weekly/monthly report sample coverage validation (must be executed)

    • Weekly report: count the number of covered days of daily reports within the statistical window, with a default threshold of >=4 days; if insufficient, mark at the top of the report: "Insufficient sample, conclusions are for reference only."
    • Monthly report: count the number of covered days of daily reports within the statistical window, with a default threshold of >=18 days; if insufficient, likewise mark insufficient sample.

PubMed configuration (local execution)

  • API Key：<PUBMED_API_KEY>
  • Usage recommendation: include in PubMed requests api_key to improve quota and stability.
  • Security constraint: this key is only for local operation, not displayed externally, and not written to public repositories.

PubMed search query expansion rules (must be executed)

When the user says "push xx literature", do not search "xx" directly as-is; first perform search query expansion:

  1. Topic normalization: convert Chinese topics into English medical subject terms (add MeSH when necessary).
  2. Synonym expansion: add common aliases/abbreviations/full names (connected with OR).
  3. Disease + scenario constraints: when necessary, add research scenario terms (such as resistance, therapy, prognosis).
  4. Time constraints: daily reports default to the last 24 hours; weekly reports default to aggregating the last 7 days of daily reports; monthly reports default to aggregating the last 30 days of daily reports.
  5. Result quality first: prioritize clinically relevant literature and literature with a higher level of evidence.

Example search query structure:

  • (主主题同义词1 OR 同义词2 OR 缩写) AND (研究场景词1 OR 场景词2)

When outputting, include a line at the beginning of the first paragraph: "Search query used this time: ...".

Enhancement rules (migrated from the dailypaper pipeline)

  1. Minimum quantity fill-in

    • When the number of high-quality new additions for the day is less than TopN (default 3), automatically fill in from the recent 7-day window until TopN is reached or candidates are exhausted.
    • Fill-in literature must not duplicate what has already been selected for the day.

  2. Quality-first sorting

    • Candidate sorting priority: level of evidence > clinical relevance > methodological innovation > recency.
    • When tied, prioritize the one with a higher journal tier (comprehensive judgment based on SCI/Q and CAS partition).

  3. Historical backfill and preventing interruptions

    • If the current period (day/week/month) has very few search results, backfilling from the historical candidate pool is allowed to ensure daily/weekly/monthly reports are not interrupted.
    • Backfilled literature must be explicitly marked as "backfill/fill-in" to avoid confusion with "new additions for the day".

  4. Standardized archive structure (recommended mandatory)

    • After each daily report output, write a structured record to disk (JSON):topic/date/pmid/title/journal/sci/cas/cpu/evidence/score/summary/url。
    • Weekly/monthly reports preferentially read this structured archive and do not directly parse natural language text.

Recommended output template (common to MDRGNB/HCC)

  • Number of new additions in this period (daily report = today, weekly report = this week, monthly report = this month)
  • TopN (daily report default 3 / weekly report default 10 / monthly report default 20; if insufficient, use actual number)
  • Each entry includes:
    • Title
    • Journal name (Journal)
    • PMID
    • Link
    • CAS partition (latest caliber + highest partition; if unavailable, write "to be verified")
    • SCI/JCR quartile (latest standard + highest quartile; if not found, write "to be verified")
    • China Pharmaceutical University classification (CPU)
    • 80-120 character Chinese abstract
    • One-sentence clinical/research value
    • 10-question key points (1-10)
    • Four-dimensional scoring (engineering application value/architectural innovation/theoretical contribution/result reliability, 1-10) + overall assessment
    • Evidence level (Meta/RCT/observational/in vitro/review/other)
  • Current issue conclusion
  • Next issue recommendations (1-2 items)

Channel mapping (default)

  • Feishu:channel=feishu，target=chat:<chatId> or user:<openId>
  • WeCom:channel=wecom，target=<userId|groupId>
  • QQ：channel=qqbot，target=qqbot:c2c:<openid> or qqbot:group:<groupid>
  • Telegram：channel=telegram，target=<chat_id>

Cron template (multi-channel general)

{
  "action": "add",
  "job": {
    "name": "<daily|weekly|monthly>-<topic>-<channel>-<HHMM>",
    "schedule": { "kind": "cron", "expr": "<m> <h> * * *", "tz": "Asia/Shanghai" },
    "sessionTarget": "isolated",
    "wakeMode": "now",
    "payload": {
      "kind": "agentTurn",
      "model": "openai-codex/gpt-5.3-codex",
      "timeoutSeconds": 1200,
      "message": "先检索文献并生成结构化快报，再使用 message 工具发送到指定渠道/目标（channel=<feishu|wecom|qqbot|telegram>, target=<ID>）。若正文过长则按2-3段发送（每段<=1200字），最后仅输出固定完成语。"
    },
    "delivery": { "mode": "none" }
  }
}

Common expressions (default push time is 08:00, can be modified):

  • Daily report:0 8 * * *
  • Weekly report (last day of this week):0 8 * * 0(Sunday 8 AM)
  • Monthly report (last day of this month):0 8 28-31 * * + verify within the task "whether the next day crosses into a new month, send only on the day before the month changes"

Default linked creation strategy:

  • When creating a daily report, also create a weekly report and monthly report on the same topic.
  • If the user does not specify a time: daily/weekly/monthly reports all default to 08:00; if the user specifies a time, override the default with the user's time.
  • Weekly reports default to "last day of this week at 08:00", and monthly reports default to "last day of this month at 08:00"; both can be modified separately and enabled/disabled independently.
  • If the corresponding weekly/monthly report already exists, skip creation and only update the configuration (to avoid duplicate tasks).
  • Monthly report "send at month end" must undergo secondary verification: actually send only when "tomorrow crosses into a new month", to avoid multiple triggers on the 28th-31st.

Troubleshooting

  • Symptom:delivered but the user cannot see the full text

    • Force change to payload message.send segmented sending
    • First send a short test message to verify target reachability
    • Then cron.run retest the full text

  • Symptom: sending failed or timed out

    • Degradation order: full-text segmentation → short summary (Top3 + links) → alert message (including failure reason and retry suggestions)
    • Write every failure to the run summary (for tracking)

  • Symptom: QQ and WeCom content inconsistent

    • Use the same "content generation template", only replace channel/target

Constraints

  • Must not output only a single placeholder word (such as mdrgnb）
  • When quartile information is uncertain, must mark 待核实, must not fabricate
  • 10-question key points, four-dimensional scoring, and evidence level are fixed output items and must not be omitted
  • Weekly/monthly reports must preferentially be automatically summarized and generated based on already published daily reports (aggregation/summarization/trends), and must not default to re-retrieval as a substitute
  • When the user requests "keep consistent", the body structure of QQ and WeCom must be consistent
  • For each article selected in the weekly report Top10 and monthly report Top20, a 1-line "reason for selection" should be given (such as high evidence level/high quartile/high clinical value)