mcpField
C
ccf-submission-checker

ccf-submission-checker

github.com/mikubaka88ドキュメント3.3k1.9k 回インストール1 週間前に更新
リポジトリ

ccf-submission-checker について

ccf-submission-checkerは、学術論文の投稿準備を確認するスキルです。会場規則、ビルド、提出物を点検し、確認済みと未検証を区別します。最終判断では最新の公式規則を確認し、論文本文の書き換えは行いません。

主な機能

  1. 01会場形式とページ制限の確認
  2. 02LaTeX、PDF、ビルド出力の点検
  3. 03匿名性、フォント、メタデータの確認
  4. 04コード、データ、再現性のチェックリスト
  5. 05モードに応じた成果物の確認

活用シーン

  1. 01特定の年やトラックの投稿規則を確認
  2. 02PDFのページ数、フォント、匿名性の問題を調査
  3. 03コードとデータの公開資料を準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mikubaka88/ccfa-skills --skill ccf-submission-checker

インストール後、Claude Code で/ccf-submission-checkerを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

CCF 提出チェック

ファイル運用の契約

ファイル作業の前に、正規パスとタスク/成果物ごとの作業ディレクトリを再利用してください。既定の場所は、プロジェクトルートの ccfa-workfiles/<purpose>/<artifact-id>/ です。その場で更新し、入力ファイルを保持し、UTF-8 を使用して中国語テキストが含まれていないか確認してください。命名、所有権、タスクで作成したファイルのクリーンアップには、artifact-contracts.md を適用してください。引き継ぎ先でもこれらのパスを引き継ぎます。

連携の契約

専門担当者が作業を開始する前に、まず ccf-humanization を読み、適用してから、ccf-common を読んで適用してください。引き継ぎのたびに、適用可能な有効ルールを再利用するか、不足または変更があれば更新してください。文章がない場合でも、両方の事前確認が必要です。詳細な編集、実験、保守の各モードは、関連する場合にのみ実行してください。

必要な専門担当者の作業を、責任者を一人に定めて統合してください。有効な前提条件を再利用し、影響を受けた結果を検証してください。重複したレポートを作成せず、連携ルートに従ってください。

基本ルール

提出物は、ビルド、投稿先のポリシー、ページ数の上限、成果物の準備状況を判定するゲートとして扱ってください。想定されるルールの確認には投稿先のローカルガイドを使用し、最終判断には公式ポリシーが最新であることを確認してください。論文の内容は書き換えないでください。

モード

  • venue-format:テンプレート、ページ上限、匿名性、著者情報欄、補足資料、カメラレディのルール。
  • package-check:LaTeX/PDF のビルド、メタデータ、フォント、ページ数、ファイル構成、提出チェックリスト。
  • artifact:コード/データ/モデルの公開計画、環境、シード、ハードウェア、ライセンス、成果物の README、再現性に関する付録。
  • full:投稿先+パッケージ+成果物。

ワークフロー

  1. 投稿先/年/トラック、提出モード、プロジェクトディレクトリ、TeX/PDF ファイル、補足資料/成果物ファイル、締切までの切迫度を特定します。
  2. 利用可能な場合は ccfa.yaml を読みます。ない場合は、提供されたファイルを使って作業を進め、プロジェクト状態の追跡が利用できないことを明記します。
  3. 投稿先に関する質問では、公式情報の最新性を確認する前に、../ccf-paper-writer/references/venue-guides/index.md と該当する投稿先ガイドを読みます。
  4. パッケージを確認する際は、実際の TeX/PDF/ビルド出力、該当する投稿先/年/トラックにおけるページ数の計算、匿名性、フォント、メタデータ、参考文献、該当する必須フォームを確認します。ICLR 2027 では、該当ガイドにある年ごとのテンプレート、段階ごとのページ数上限、AI の使用に関する記述/フォームの確認を適用します。確認できていない使用状況の事実は、未検証のまま扱います。ログと影響を受けるページを読み、ファイルが存在することだけを根拠にビルド成功と判断しないでください。
  5. 成果物を確認する際は、コード、データ、モデル、環境、シード、ハードウェア、ライセンス、アクセス制限、README を含む再現性チェックリストを作成します。
  6. テキストやページ数の書き換えが必要な場合は、ccf-paper-writer に引き継ぎます。上限を超えている場合は圧縮し、説明が実際に不足している場合は内容を補足し、上限内であれば通常の推敲を行います。再現性実験が不足している場合は ccf-experiment-designer に、図表のフロート順、キャプションの配置、フォント、クリッピング、配色、視認性の修正には ccf-visual-composer に、査読後の回答資料一式の作成には ccf-rebuttal-writer に引き継ぎます。

出力の契約

Mode:
Venue and rule freshness:
Files checked:
Pass/fail checklist:
Build/package issues:
Anonymity/page/font/metadata issues:
Length budget status:
Artifact/reproducibility issues:
Required fixes:
Next CCFA owner:

確認範囲

../ccf-common/references/handoff-modes.md と ../ccf-common/references/task-modes.md に従ってください。依頼されたモードと実際の成果物に関連する確認を行います。合格、不合格、該当なし、未検証を区別してください。ツールがない場合、合格にも不合格にもなりません。公式ルールの URL と確認日を記録してください。プロジェクトのビルド設定を再利用し、生成したログ/プレビューは、確立済みのタスク用または共有のビルドディレクトリに配置します。正規の準備状況レポートをその場で更新し、以前の PDF と今回正常にビルドされた PDF を区別してください。修正後は、影響を受けたビルド箇所のみ再確認します。ページ数の上限を下回っていることだけでは、投稿先の規則違反になりません。準備状況の確認を依頼されたというだけで、ファイルをアップロードまたは提出しないでください。

コメント