Back to Details

paper-know-journal

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

paper-know-journal

paper-know-journal

输入与输出

Input and Output

输入：期刊/杂志名；可附加输出目录、工作区、关注方向、目标文体/文章类型（如 Article、Original Research、Review、Brief Communication、Case Report、Letter）或目标 manuscript 类型。
输出：
KnowJournal-{杂志名}.md
，默认在用户当前工作目录根目录；用户指定输出位置时按指定保存。文件名中的 
/\:*?"<>|
等路径危险字符替换为 
-
。
中间文件：默认全部放入 
.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/paper-know-journal/{yyyy-mm-dd-hh-mm}/
。除最终 Markdown 和用户明确指定输出外，不得在隐藏工作区外写检索日志、网页摘录、截图、草稿、JSON、临时下载或运行缓存。
测试区：轻量验证用 
./tests/paper-know-journal/
；测试证据不得混入最终报告。
Input: Journal name; optional additional inputs include output directory, workspace, focus areas, target article types (e.g., Article, Original Research, Review, Brief Communication, Case Report, Letter) or target manuscript types.
Output: 
KnowJournal-{journal name}.md
, saved by default in the root directory of the user's current working directory; saved to the specified location if the user designates an output path. Path-dangerous characters such as 
/\:*?"<>|
in the file name are replaced with 
-
.
Intermediate Files: By default, all intermediate files are stored in 
.bensz-api/task-{yyyymmdd-hhmm}-{brief description}/paper-know-journal/{yyyy-mm-dd-hh-mm}/
. Except for the final Markdown file and outputs explicitly specified by the user, retrieval logs, web excerpts, screenshots, drafts, JSON files, temporary downloads or runtime caches must not be written outside the hidden workspace.
Test Area: Use 
./tests/paper-know-journal/
for lightweight verification; test evidence must not be mixed into the final report.

流程

Workflow

输入

Input

按用户请求和配置文件提供必要输入；缺失信息应明确列出并停止依赖该输入的步骤。
Provide necessary inputs according to user requests and configuration files; if information is missing, clearly list it and stop steps that depend on the missing input.

执行步骤

Execution Steps

  • 因本 skill 设计缺陷导致的 bug，先用 
    bensz-collect-bugs
    规范记录到 
    ~/.bensz-skills/bugs/
    ，不要直接修改用户本地已安装的 skill 源码；若有 workaround，先记 bug，再继续完成任务。
  • 只有用户明确要求“report bensz skills bugs”等公开上报时，才用本地 
    gh
    上传新增 bug 到 
    huangwb8/bensz-bugs
    ；不要 pull / clone 整个仓库。
  • For bugs caused by design flaws of this skill, first use 
    bensz-collect-bugs
    to record them in 
    ~/.bensz-skills/bugs/
    in a standardized manner, do not directly modify the skill source code installed locally by the user; if there is a workaround, record the bug first, then continue to complete the task.
  • Only when the user explicitly requests actions like "report bensz skills bugs" for public submission, use the local 
    gh
    tool to upload new bugs to 
    huangwb8/bensz-bugs
    ; do not pull / clone the entire repository.

初始化

Initialization

先运行脚本创建隔离工作区、测试区和安全输出路径：
bash
python3 /path/to/paper-know-journal/scripts/init_workspace.py \
  --journal "Cancer Cell" \
  --cwd "$PWD"
脚本会打印 
workspace_dir
、
output_path
、
test_dir
、
manifest_path
、
sources_path
。所有中间产物写入 
workspace_dir
。如提示 
output_path already exists
，覆盖前先向用户确认或改用新路径。
如用户指定输出目录或工作区：
bash
python3 /path/to/paper-know-journal/scripts/init_workspace.py \
  --journal "Journal for ImmunoTherapy of Cancer" \
  --cwd "$PWD" \
  --output-dir "/path/to/output" \
  --workspace-dir "/path/to/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/paper-know-journal"
First run the script to create an isolated workspace, test area and secure output path:
bash
python3 /path/to/paper-know-journal/scripts/init_workspace.py \
  --journal "Cancer Cell" \
  --cwd "$PWD"
The script will print 
workspace_dir
, 
output_path
, 
test_dir
, 
manifest_path
, 
sources_path
. All intermediate products are written to 
workspace_dir
. If prompted 
output_path already exists
, confirm with the user before overwriting or use a new path.
If the user specifies an output directory or workspace:
bash
python3 /path/to/paper-know-journal/scripts/init_workspace.py \
  --journal "Journal for ImmunoTherapy of Cancer" \
  --cwd "$PWD" \
  --output-dir "/path/to/output" \
  --workspace-dir "/path/to/.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/paper-know-journal"

调研

Research

必须联网核验，至少覆盖：
  • 官方来源：期刊官网、作者指南、投稿系统说明、manuscript preparation / formatting guidelines、出版商政策页、费用页、编辑政策页。
  • 社区/第三方来源：SciRev、LetPub、ResearchGate、Reddit、X/Twitter、论坛、机构图书馆说明、作者经验贴等。第三方只作体验线索，不替代官方政策。
优先查证这些信息：
  • 期刊全称、出版社/学会、ISSN、官网、投稿入口。
  • scope、文章类型、字数/摘要/图表/参考文献限制。
  • 目标文体/文章类型的具体要求：用户指定文体时必须覆盖该文体；未指定时先列出官方文章类型，再选择 2-3 个最常见或最相关类型（通常包括原创研究与综述）展开。逐项核验该类型的名称、正文/摘要字数或页数、摘要类型、关键词数量、章节标题与顺序、图表/补充材料/参考文献限制、报告规范清单和特殊提交材料。
  • 投稿形式要求：标题页、作者信息、摘要类型与字数、关键词、正文结构、章节标题、文件组成、模板、行距/页码/编号、图表文件格式与分辨率、补充材料、参考文献格式、cover letter、报告规范清单。
  • OA/订阅模式、APC、许可证、是否有会员折扣或豁免。
  • 审稿方式、首轮决定时间、接收到上线时间、接收率；没有官方数据时标明来源类型和不确定性。
  • 格式要求：标题页、摘要、关键词、正文结构、图像分辨率、补充材料、参考文献格式、声明章节、数据/代码/AI 使用政策。
  • 近期文章格式：抽样 2-3 篇近年同类文章，归纳摘要、正文结构、图表数量、声明与参考文献风格。
  • 社区评价：速度、沟通、拒稿/大修体验、费用争议、透明度、常见槽点；与官方信息分开写。
调研时维护 
sources.json
：
  • official
    ：官方网页、作者指南、费用页、投稿系统、出版伦理页。
  • community
    ：SciRev、LetPub、论坛、作者经验贴、机构说明等。
  • article_samples
    ：近期代表性已发表文章。
每条来源至少记录 
title
、
url
、
source_type
、
accessed_at
、
key_facts
。网页摘录、检索日志和草稿只能放在 
workspace_dir
内。
资料处理规则见 
references/source-policy.md
。报告结构见 
references/report-template.md
。
Online verification is mandatory, covering at least:
  • Official Sources: Journal official website, author guidelines, submission system instructions, manuscript preparation / formatting guidelines, publisher policy pages, fee pages, editorial policy pages.
  • Community/Third-party Sources: SciRev, LetPub, ResearchGate, Reddit, X/Twitter, forums, institutional library instructions, author experience posts, etc. Third-party sources are only used as experience clues and cannot replace official policies.
Prioritize verifying the following information:
  • Full journal name, publisher/society, ISSN, official website, submission portal.
  • Scope, article types, word count/abstract/figure/reference limits.
  • Specific requirements for target article types: When the user specifies an article type, it must be fully covered; if not specified, first list official article types, then select 2-3 most common or relevant types (usually including original research and reviews) to expand. For each type, verify its name, word count or page limit for main text/abstract, abstract type, number of keywords, section titles and order, limits on figures/supplementary materials/references, checklist of reporting standards and special submission materials.
  • Submission format requirements: Title page, author information, abstract type and word count, keywords, main text structure, section titles, file composition, templates, line spacing/page numbering, figure file format and resolution, supplementary materials, reference format, cover letter, checklist of reporting standards.
  • OA/subscription model, APC, license, whether there are member discounts or waivers.
  • Review method, first decision time, time from acceptance to online publication, acceptance rate; if no official data is available, indicate the source type and uncertainty.
  • Format requirements: Title page, abstract, keywords, main text structure, image resolution, supplementary materials, reference format, declaration sections, policies on data/code/AI usage.
  • Recent article formats: Sample 2-3 similar articles published in recent years, summarize abstract, main text structure, number of figures, declaration and reference styles.
  • Community reviews: Speed, communication, experience of rejection/major revision, fee disputes, transparency, common complaints; separate from official information.
Maintain 
sources.json
during research:
  • official
    : Official web pages, author guidelines, fee pages, submission systems, publication ethics pages.
  • community
    : SciRev, LetPub, forums, author experience posts, institutional instructions, etc.
  • article_samples
    : Representative recently published articles.
For each source, at least record 
title
, 
url
, 
source_type
, 
accessed_at
, 
key_facts
. Web excerpts, retrieval logs and drafts can only be stored in 
workspace_dir
.
Refer to 
references/source-policy.md
for data processing rules. See 
references/report-template.md
for report structure.

成稿

Final Report Compilation

用中文 Markdown 输出，风格接近 JITC / Cancer Cell 调研样例：先给关键结论和期刊概况，再写投稿要求、投稿形式要求、真实文章格式、社区评价和投稿建议。
报告必须包含：
  • 调研日期。
  • 期刊名称和可核验官网链接。
  • “官方信息”和“社区评价/第三方信息”的来源区分。
  • 独立的“投稿形式要求与格式清单”章节；不能只用近期文章样本替代官方投稿格式要求。
  • 在“投稿形式要求与格式清单”中包含独立的“目标文体/文章类型具体要求”小节；对每个目标文体写清楚官方章节标题/顺序、字数或页数、摘要、关键词、图表、参考文献和特殊文件要求。若官方采用 format-free / free format 初投稿，也要写清哪些项目仍需满足、哪些项目仅修回或接收后适用。
  • 面向投稿准备的可执行清单，至少覆盖标题页、摘要/关键词、正文结构、图表、补充材料、参考文献、声明/伦理/数据/代码/AI、投稿文件或 cover letter；官方未披露时逐项写“未在官方页面确认”。
  • 对缺失、冲突或疑似过期信息的显式标注。
  • 来源清单，含链接与访问日期。
不得输出未核验断言。影响因子、分区、费用、审稿时长等易变信息必须写来源年份或访问日期。
Output in Chinese Markdown, with a style similar to JITC / Cancer Cell research samples: Start with key conclusions and journal overview, then write submission requirements, submission format requirements, actual article formats, community reviews and submission suggestions.
The report must include:
  • Research date.
  • Journal name and verifiable official website link.
  • Clear distinction between "official information" and "community reviews/third-party information" sources.
  • An independent chapter "Submission Format Requirements and Checklist"; do not replace official submission format requirements with only recent article samples.
  • An independent subsection "Specific Requirements for Target Article Types" within "Submission Format Requirements and Checklist"; for each target article type, clearly write official section titles/order, word count or page limit, abstract, keywords, figures, references and special file requirements. If the official adopts format-free / free format for initial submission, also clarify which items still need to be met and which items only apply during revision or after acceptance.
  • An actionable checklist for submission preparation, covering at least title page, abstract/keywords, main text structure, figures, supplementary materials, references, declarations/ethics/data/code/AI, submission files or cover letter; write "Not confirmed on official pages" for each item not disclosed by the official.
  • Explicit labels for missing, conflicting or suspected outdated information.
  • Source list with links and access dates.
Do not output unverified assertions.易变信息 such as impact factor, partition, fees, review duration must include the source year or access date.

验证

Verification

成稿后运行：
bash
python3 /path/to/paper-know-journal/scripts/validate_report.py \
  --report "KnowJournal-Cancer Cell.md" \
  --journal "Cancer Cell"
验证通过后告知用户：最终文件路径、主要来源数量、无法确认的信息和残余风险。
After compiling the report, run:
bash
python3 /path/to/paper-know-journal/scripts/validate_report.py \
  --report "KnowJournal-Cancer Cell.md" \
  --journal "Cancer Cell"
After verification passes, inform the user of: final file path, number of main sources, unconfirmable information and residual risks.

输出

Output

输出 Skill description 所承诺的交付物，并明确格式、路径和失败返回形式。
Deliver the output promised in the Skill description, and clearly specify the format, path and failure return form.

输出管理

Output Management

本 Skill 的新任务中间文件统一写入 
./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/
。同一任务复用一个任务根目录；多 Skill 协作才创建 
shared/
。正式交付物不写入该目录，历史隐藏目录只允许显式兼容读取、迁移或清理。
Intermediate files for new tasks of this Skill are uniformly written to 
./.bensz-api/task-{yyyymmdd-hhmm}-{brief description}/{skill name}/input|output|log/
. Reuse a single task root directory for the same task; create 
shared/
only for multi-Skill collaboration. Official deliverables are not written to this directory; historical hidden directories only allow explicit compatible reading, migration or cleaning.

校验

Check

完成后执行 Skill 已有的静态检查、脚本验证或人工复核，并记录通过标准。
After completion, perform existing static checks, script verification or manual review of the Skill, and record the passing standards.

失败与恢复

Failure and Recovery

  • 找不到官网：先用出版商、ISSN、NLM Catalog、DOAJ、Crossref、期刊投稿系统交叉定位；仍不能确认时停止成稿并说明需要用户确认目标期刊。
  • 同名期刊冲突：列出候选期刊、出版社和 ISSN，先让用户确认。
  • 社区评价稀少：明确写“未找到足够社区评价”，不要编造体验。
  • 官方信息与社区信息冲突：以官方政策为准，社区信息作为体验线索，并标注冲突点。
  • 网站无法访问：记录访问失败、尝试替代官方页面或缓存摘要；关键政策无法核验时在报告中列为待确认。
  • Official website not found: First cross-locate using publisher, ISSN, NLM Catalog, DOAJ, Crossref, journal submission system; if still unconfirmable, stop report compilation and explain that user confirmation of the target journal is required.
  • Conflict with journals of the same name: List candidate journals, publishers and ISSN, and ask the user to confirm first.
  • Insufficient community reviews: Clearly write "Insufficient community reviews found", do not fabricate experiences.
  • Conflict between official information and community information: Prioritize official policies, treat community information as experience clues, and mark conflict points.
  • Website inaccessible: Record access failure, try alternative official pages or cached summaries; if key policies cannot be verified, list them as to-be-confirmed in the report.

约束

Constraints

遵守以下公共约束，并执行本 Skill 的专属边界。
Comply with the following public constraints and implement the exclusive boundaries of this Skill.

公共硬约束

Public Hard Constraints

  • 任务需要落盘时，使用唯一的 
    ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/
    根目录；共享材料放入 
    shared/
    ，Skill 专属材料放入该 Skill 的 
    input/
    、
    output/
    、
    log/
    。
  • 正式交付物、源代码和正式计划按项目约定保存，不写入任务工作区；未经授权不覆盖、删除、迁移或远程写入。
  • 项目维护变更检查 BAC 可用性并记录需求、AI 产出、工具结果、文件改动和验证摘要；BAC 只做过程审计，不替代署名、责任或合规判断。
  • 不记录 API Key、访问令牌、密码、Cookie、环境/凭据文件、私有 Prompt、身份信息、本地用户名、主机名或不必要的大体积原始数据。
  • 文件路径必须规范化并限制在授权项目范围内；外部 URL、子进程和网络访问遵循最小权限，防止路径遍历、SSRF 和命令注入。
  • Skill 版本唯一记录在自身 
    config.yaml:skill_info.version
    ；公开 API、协议、目录或配置变更同步文档与 
    CHANGELOG.md
    。
  • 仅将 Skill 或 Bensz 基础设施本身的设计缺陷交给 
    bensz-collect-bugs
    ；先脱敏写入 
    ~/.bensz-skills/bugs/
    ，当前任务不中断，只有用户明确要求才公开上报，禁止直接修改用户已安装的 Skill 源码。
<!-- End of canonical common constraints. -->
  • When tasks require disk storage, use a unique 
    ./.bensz-api/task-{yyyymmdd-hhmm}-{brief description}/
    root directory; shared materials are stored in 
    shared/
    , and Skill-specific materials are stored in 
    input/
    , 
    output/
    , 
    log/
    of the Skill.
  • Official deliverables, source code and official plans are saved according to project agreements, not written to the task workspace; do not overwrite, delete, migrate or remotely write without authorization.
  • For project maintenance changes, check BAC availability and record requirements, AI outputs, tool results, file changes and verification summaries; BAC only performs process audits and does not replace signature, responsibility or compliance judgments.
  • Do not record API Keys, access tokens, passwords, Cookies, environment/credential files, private Prompts, identity information, local usernames, hostnames or unnecessary large-volume raw data.
  • File paths must be standardized and limited to authorized project scopes; external URLs, subprocesses and network access follow the principle of least privilege to prevent path traversal, SSRF and command injection.
  • Skill versions are uniquely recorded in its own 
    config.yaml:skill_info.version
    ; changes to public APIs, protocols, directories or configurations are synchronized with documents and 
    CHANGELOG.md
    .
  • Only design defects of the Skill or Bensz infrastructure itself are submitted to 
    bensz-collect-bugs
    ; first desensitize and write to 
    ~/.bensz-skills/bugs/
    , do not interrupt the current task, only submit publicly if the user explicitly requests, and prohibit direct modification of the Skill source code installed by the user.
<!-- End of canonical common constraints. -->

Skill 专属约束

Skill Exclusive Constraints

不得超出本 Skill description 和上方流程所声明的范围；不将未验证的信息伪装成确定结论。
Do not exceed the scope stated in this Skill description and the workflow above; do not disguise unverified information as definitive conclusions.