paper-know-journal

paper-know-journal

入力と出力

入力：ジャーナル／雑誌名。出力ディレクトリ、ワークスペース、関心分野、目標とする文体／記事種別（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/ を使用します。テストの証跡を最終レポートに混在させてはなりません。

ワークフロー

入力

ユーザーの依頼と設定ファイルに基づいて必要な入力を用意します。不足している情報は明示して列挙し、その入力に依存する手順を停止します。

実行手順

• この Skill の設計上の欠陥が原因のバグは、まず bensz-collect-bugs を使って所定の形式で ~/.bensz-skills/bugs/ に記録します。ユーザーのローカルにインストール済みの Skill のソースコードを直接変更してはなりません。回避策がある場合は、まずバグを記録してからタスクを続行します。
• ユーザーが「report bensz skills bugs」などの公開報告を明示的に要求した場合に限り、ローカルの gh を使って新たなバグを huangwb8/bensz-bugs にアップロードします。リポジトリ全体を pull／clone してはなりません。

初期化

まずスクリプトを実行し、隔離ワークスペース、テスト領域、安全な出力パスを作成します。

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 と表示された場合、上書きする前にユーザーに確認するか、新しいパスを使用します。

ユーザーが出力ディレクトリまたはワークスペースを指定した場合：

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"

調査

必ずオンラインで検証し、少なくとも以下を調査します。

• 公式情報源：ジャーナル公式サイト、著者向けガイド、投稿システムの説明、manuscript preparation / formatting guidelines、出版社のポリシーページ、料金ページ、編集方針ページ。
• コミュニティ／第三者情報源：SciRev、LetPub、ResearchGate、Reddit、X/Twitter、フォーラム、機関図書館の案内、著者の体験談など。第三者情報は体験に関する手がかりとしてのみ扱い、公式ポリシーの代わりにしてはなりません。

以下の情報を優先して確認します。

• ジャーナルの正式名称、出版社／学会、ISSN、公式サイト、投稿先。
• 対象範囲、記事種別、語数／抄録／図表／参考文献の制限。
• 目標とする文体／記事種別の具体的な要件：ユーザーが文体を指定した場合は、その文体を必ず対象にします。指定がない場合は、まず公式の記事種別を列挙し、最も一般的または関連性の高いものを 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 を参照してください。

レポート作成

中国語の Markdown で出力し、JITC / Cancer Cell の調査サンプルに近いスタイルにします。まず重要な結論とジャーナルの概要を示し、続けて投稿要件、投稿形式の要件、実際の論文の書式、コミュニティの評価、投稿に関する提案を記載します。

レポートには以下を必ず含めます。

• 調査日。
• ジャーナル名と検証可能な公式サイトへのリンク。
• 「公式情報」と「コミュニティ評価／第三者情報」の情報源の区別。
• 独立した「投稿形式の要件と書式チェックリスト」の章。近年の論文サンプルだけで、公式の投稿書式要件を代用してはなりません。
• 「投稿形式の要件と書式チェックリスト」に、独立した「目標とする文体／記事種別の具体的な要件」の小節を含めます。目標とする文体ごとに、公式の見出し／順序、語数またはページ数、抄録、キーワード、図表、参考文献、特別なファイルの要件を明確に記載します。公式が format-free / free format での初回投稿を採用している場合も、なお満たす必要がある項目と、修正後または受理後にのみ適用される項目を明確にします。
• 投稿準備に使える実行可能なチェックリスト。少なくともタイトルページ、抄録／キーワード、本文構成、図表、補足資料、参考文献、声明／倫理／データ／コード／AI、投稿ファイルまたは cover letter を対象とします。公式ページで開示されていない項目は、個別に「公式ページで確認できず」と記載します。
• 欠落、矛盾、または古くなっている可能性のある情報の明示。
• リンクとアクセス日を含む情報源一覧。

検証されていない断定を出力してはなりません。インパクトファクター、区分、料金、査読期間など、変動しやすい情報には情報源の年またはアクセス日を記載します。

検証

レポート作成後、以下を実行します。

python3 /path/to/paper-know-journal/scripts/validate_report.py \
  --report "KnowJournal-Cancer Cell.md" \
  --journal "Cancer Cell"

検証に合格した後、最終ファイルのパス、主な情報源の数、確認できなかった情報、残存リスクをユーザーに伝えます。

出力

Skill description で約束されている成果物を出力し、形式、パス、失敗時の返却形式を明示します。

出力の管理

この Skill の新しいタスクの中間ファイルは、すべて ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/ に書き込みます。同じタスクではタスクルートディレクトリを再利用します。複数の Skill が連携する場合に限り、shared/ を作成します。正式な成果物をこのディレクトリに保存してはなりません。過去の隠しディレクトリは、明示的に互換読み込み、移行、またはクリーンアップを行う場合に限って使用できます。

チェック

完了後、この Skill に既存の静的チェック、スクリプト検証、または手動レビューを実行し、合格基準を記録します。

失敗と復旧

• 公式サイトが見つからない場合：まず出版社、ISSN、NLM Catalog、DOAJ、Crossref、ジャーナルの投稿システムを使って照合します。それでも確認できない場合はレポート作成を停止し、対象ジャーナルについてユーザーの確認が必要であることを説明します。
• 同名のジャーナルが複数ある場合：候補となるジャーナル、出版社、ISSN を列挙し、先にユーザーに確認します。
• コミュニティ評価が少ない場合：「十分なコミュニティ評価が見つかりませんでした」と明記し、体験を捏造してはなりません。
• 公式情報とコミュニティ情報が矛盾する場合：公式ポリシーを優先し、コミュニティ情報は体験に関する手がかりとして扱い、矛盾点を明記します。
• ウェブサイトにアクセスできない場合：アクセス失敗を記録し、代替の公式ページまたはキャッシュされた概要を試します。重要なポリシーを検証できない場合は、レポート内で要確認事項として記載します。

制約

以下の共通制約を遵守し、この Skill 固有の境界も守ります。

共通の必須制約

• タスクでファイルへの書き込みが必要な場合は、一意の ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/ ルートディレクトリを使用します。共有資料は shared/ に、この Skill 固有の資料は Skill の input/、output/、log/ に保存します。
• 正式な成果物、ソースコード、正式な計画はプロジェクトの規約に従って保存し、タスクワークスペースには書き込みません。許可なく上書き、削除、移行、リモートへの書き込みを行ってはなりません。
• プロジェクトの保守変更では BAC の利用可否を確認し、要件、AI の生成物、ツールの結果、ファイル変更、検証の概要を記録します。BAC はプロセス監査のみを行い、著者表示、責任、コンプライアンスの判断に代わるものではありません。
• API Key、アクセストークン、パスワード、Cookie、環境／認証情報ファイル、非公開 Prompt、個人情報、ローカルユーザー名、ホスト名、不要な大容量の生データを記録してはなりません。
• ファイルパスは正規化し、許可されたプロジェクトの範囲内に制限します。外部 URL、子プロセス、ネットワークアクセスには最小権限の原則を適用し、パストラバーサル、SSRF、コマンドインジェクションを防止します。
• Skill のバージョンは、Skill 自身の config.yaml:skill_info.version にのみ記録します。公開 API、プロトコル、ディレクトリ、設定の変更は、ドキュメントと CHANGELOG.md に反映します。
• bensz-collect-bugs に報告するのは、Skill または Bensz インフラストラクチャ自体の設計上の欠陥に限ります。まず機密情報を削除して ~/.bensz-skills/bugs/ に記録し、現在のタスクは中断しません。公開報告はユーザーが明示的に要求した場合に限り行い、ユーザーがインストール済みの Skill のソースコードを直接変更することを禁止します。

Skill 固有の制約

この Skill description と上記のワークフローで定められた範囲を超えてはなりません。未検証の情報を確定した結論であるかのように示してはなりません。