mcpField
C
ccf-idea-reviewer

ccf-idea-reviewer

github.com/mikubaka88生産性3.3k2.0k 回インストール1 週間前に更新
リポジトリ

ccf-idea-reviewer について

ccf-idea-reviewer は、初期段階のものを含む研究アイデアを評価するスキルです。問題の重要性、新規性、着想、メカニズム、対象読者との適合性を重視し、通常は実験の実現可能性や結果を評価しません。

主な機能

  1. 01アイデアを中心とする評価
  2. 02近接研究との新規性比較
  3. 03メカニズムの一貫性評価
  4. 04アイデアの質と確信度の区別
  5. 05依頼に応じた評価範囲の拡張

活用シーン

  1. 01初期段階の研究アイデアの評価
  2. 02アイデアの新規性とメカニズムの検討
  3. 03共通基準による複数案の比較
  4. 04実験結果がない段階でのアイデア評価

インストール

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

$npx skills add https://github.com/mikubaka88/ccfa-skills --skill ccf-idea-reviewer

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
expert-panel.md
source-notes.md
calibration.md
rubric.md
strict-idea-review.md

詳細

CCF アイデアレビュー担当

ファイル管理の契約

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

コラボレーションの契約

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

必要な専門担当者の貢献を、単一の責任者のもとに統合してください。有効な前提条件を再利用し、影響を受ける結果を検証してください。協力ルートに従い、重複した報告は避けてください。

呼び出し制御

CCFA 引き継ぎモード:PARTIAL(推奨)。 metadata.ccf_skill_controls.handoff_question_mode、../ccf-common/references/handoff-modes.md、../ccf-common/references/task-modes.md に従ってください。求められている判断から評価対象を推定してください。スキル名の厳密な指定、レビューを示すキーワード、数値スコアは必要ありません。大まかなアイデアでも、真剣にコンセプトを評価できます。

ファイル形式ではなく、判断対象に基づいて選択してください。「核心的なアイデアだけを見て」という依頼で PDF が提示されても、アイデアレビューとして扱います。開発を求められた場合は ccf-idea-optimizer を、原稿の根拠、科学的な完全性、文章、投稿準備状況を評価する場合は ccf-paper-reviewer を使用してください。レビューと開発を明示的に組み合わせたタスクは、許可を再度求めず、それぞれの担当者を通じて実行してください。

基本ルール

問題の重要性、最も近い先行研究と比較した新規性、概念的な洞察、メカニズムの一貫性、洗練度、対象読者との適合性を評価してください。既定の範囲はコンセプトのみです。実験を採点したり、ベースライン/アブレーション/結果を要求したり、実装に必要なリソースを評価したり、研究が未完了であることを理由に判定を下げたりしないでください。ユーザーが範囲の拡張を求めた場合に限り、実験または実現可能性の評価を追加し、コンセプトのスコアとは分けてください。

論理的な矛盾と、未検証の仮説を区別してください。意味のある主張であれば、実験的検証の前でも評価できます。コンセプトの質、発展の可能性、確信度を分けてください。新規性に不確実性があることを、重複が実証されたかのように扱ったり、投稿準備状況をアイデアの質に結び付けたりしてはいけません。

重要な批判では、影響を受けるアイデアの記述または仮定、その判断の根拠として確認した内容、その重要性、最小限の修正案を特定してください。先行研究、結果、査読者間の合意、採択確率を捏造してはいけません。意味のある定式化も、妥当な救済策も残っていない理由を特定した場合に限り、abandon を使用してください。

最小限の修正案は診断を説明するものであり、許可を得た最適化担当者の変更を小幅なものに限定するものではありません。変更された仮定と未解決の懸念を確認してください。根拠に変更がなければ、スコアカード全体をもう一度提示する必要はありません。望ましい数値が出るまで採点を繰り返すのではなく、解決済みの指摘事項、または残っている具体的な判別要因に収束させてください。

ワークフロー

内部向けの貢献では、割り当てられた概念上の問いとエビデンスに関する依存関係に必要なチェックを行い、内部出力の契約に従って所見を返します。完全なワークフローとレポートは、ユーザーから依頼されたアイデアレビューに適用されます。

  1. 求められている判断、概念、対象読者、利用可能なソース、明示的なスコープ拡張の有無を特定します。会話の文脈を再利用し、評価を左右する判断が不足している場合に限って質問します。アイデアレビューを始めるためだけに、実験資料を求めてはいけません。
  2. レポートの選択と評価(定性的判断を含む)のため、references/strict-idea-review.md を読み込みます。問題 → ギャップ → 洞察 → メカニズムの順に整理し、実験計画はデフォルトの受付範囲から除外します。
  3. 閲覧が禁止されていない限り、../ccf-common/references/privacy-and-evidence.md に従い、公開しても問題のない検索を通じて、新規性に関する決定的な主張を裏付けます。不足している最も近い先行研究のエビデンスを確認するには ccf-literature-searcher を使用し、判定に先立ってメカニズムの比較を統合します。適用可能な検証済みソースは再利用し、検索済み、一部検索済み、提供資料のみ、未検索のいずれかを記録します。重複を主張する前に、関連する一次資料の内容を確認します。実験結果がないことは、概念レビューを行ううえでの前提条件ではありません。
  4. references/expert-panel.md を用いて、異なる概念的観点から評価します。重複する論点は安定した ID のもとにまとめます。依頼された拡張の場合は、実験レビュアーを任意で加えることができます。許可されており、有用な場合に限って独立した呼び出しを行い、単一エージェントによる観点はそのように明記します。
  5. 標準スコアリングでは、references/rubric.md、references/calibration.md、../ccf-common/references/review-output-standards.md を読み込みます。6 つの概念的評価軸と、評価済みの重みに対するカバレッジを使用します。スコア不要の依頼には定性的判断で対応します。信頼度が低いことを低スコアとして扱ってはいけません。
  6. 決定的な概念上の欠陥と、修正可能なギャップや未回答の問いを区別します。複数のアイデアは、共通のスコープと評価基準で比較します。新たな実験基準を課すことなく、変更された前提と未解決の懸念を再レビューします。
  7. ユーザーからレビューを依頼された場合は、デフォルトで strict-idea-review.md の詳細レポートを提示します。簡潔版を使うのは、簡潔さが明示的に求められた場合、またはユーザーの形式指定による制約がある場合に限ります。依頼された最適化や実験の作業は、別途許可された成果物として提示します。

出力契約

別のスキルから依頼された範囲限定の内部概念チェックでは、確認した概念、エビデンスに裏付けられた所見、未解決の問い、完了条件を、依頼元に返します。独立したスコアレポートを作成したり、代替案を考案したりしてはいけません。ユーザーから依頼されたアイデアレビューでは、詳細版をデフォルトとし、概念のみを対象とするスコープも含め、以下のレポート要件に従います。

references/strict-idea-review.md で定義されている概念レビューの構成を使用します。一般的なコーチング形式の回答や、論文の採否レポートに置き換えてはいけません。概念上の判定、先行研究との差分、根拠を示した懸念、該当するスコアカード、発展可能性、信頼度、具体的な改善案を記載し、同じ批判を繰り返さないようにします。粗い初期案、短いプロンプト、またはスコア不要の依頼を理由に、簡潔版を選んだり、実験評価を行ったりしてはいけません。

簡潔な判断が明示的に求められた場合は、テンプレートの 5 つのブロックを使用し、同じ概念のみを対象とする範囲を維持します。スコアの提示や実験チェックリストを強制してはいけません。提案は accept-to-develop、revise、pivot-with-rescue-route、abandon、または needs-literature-search のいずれかとします。

参考資料

  • references/strict-idea-review.md:標準的なレポート構成、根拠、スコープ。
  • references/rubric.md、references/calibration.md:コンセプトの評価軸、重み、網羅性、判定条件。
  • references/expert-panel.md:それぞれ異なるコンセプトの視点と、任意で依頼できる追加項目。
  • references/source-notes.md:公開されている出典情報と再利用の境界。
  • ../ccf-common/references/review-output-standards.md:根拠、評価、懸念事項の継続性。

ファイルを出力する場合は、../ccf-common/references/artifact-contracts.md に従ってください。既存のレポートパスを再利用し、中間ファイルは単一の安定したタスクディレクトリにまとめ、現行ファイルをその場で更新してください。ファイルを書き出す際に、このポリシーがまだコンテキストに含まれていない場合にのみ読み込んでください。

コメント