mcpField
J
jinko-context

jinko-context

github.com/novainsilico生産性4159 回インストール1 週間前に更新
リポジトリ

jinko-context について

Jinkō Contextは、Jinkōの科学モデリングプロジェクトを扱うユーザーやエージェント向けのスキルです。プロジェクト構成、成果物の識別、不変のSnapshot、専門用語を説明し、作業場所と対象項目・状態を区別します。

主な機能

  1. 01プロジェクトとフォルダー構成の説明
  2. 02Project Itemの識別方法
  3. 03不変のSnapshotの解説
  4. 04科学モデリング用語の定義
  5. 05関連スキルへのタスク振り分け

活用シーン

  1. 01Jinkōプロジェクト内での成果物の特定
  2. 02バージョン管理された成果物の状態確認
  3. 03モデリング成果物間の関係の把握
  4. 04実装タスクに適したスキルの選択

インストール

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

$npx skills add https://github.com/novainsilico/jinko-skills --skill jinko-context

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

同梱ファイル

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

agents/
openai.yaml
evals/
evals.json
references/
folder-management.md
scripts/
manage_folders.py

詳細

Jinkō Context

このスキルは、Jinkō の共通のメンタルモデルと用語を説明するために使用します。回答は実用的なものにしてください。目的は、プロジェクトの構成、科学的な内容、不変のバージョンを混同せずに、ユーザーやエージェントが Jinkō の成果物を扱えるようにすることです。

前提条件: フォルダー管理の例では、初期化済みの jinko-sdk 接続と、metadata.requires_sdk の範囲を満たす SDK が必要です。jinko-sdk-setup スキル(../jinko-sdk-setup/SKILL.md)を実行し、そのチェックに合格してから進めてください。セッションコードは一度しか交換できないため、このスキル独自の SDK プロセスを開始する前に、再度 get_session_code を呼び出してください。このスキルが見つからない場合は、novainsilico/jinko-skills からインストールしてください。

ナビゲーションとバージョン管理

Jinkō のプロジェクトナビゲーションは、ソースコードファイルではなく科学モデリングの成果物を扱う点を除けば、Git リポジトリでの作業によく似ています。

  • Project はリポジトリに相当します。参照、データ、モデル、プロトコル、試験、レポート、共同作業の履歴など、具体的な科学モデリングの取り組みをまとめる単位です。
  • Folders はリポジトリのディレクトリに相当します。ワークフロー、実験、疾患領域、エビデンスパッケージ、分析の流れごとに、関連するプロジェクト項目を整理します。フォルダー API は整理のためのインターフェースであり、フォルダーは Project Item ではありません。
  • Project Items は、リポジトリで追跡されるファイルやドメインオブジェクトに相当します。各項目には SID があり、モデル、プロトコル、試験、データテーブル、参照、出力セット、ドキュメントなどの Jinkō の成果物を表します。
  • Snapshots は、バージョン管理された Jinkō コア項目 API が公開する不変の状態です。最新の状態は head です。すべての Project Item タイプでスナップショットが公開されるとは限りません。スナップショット ID があるかどうかは、リソースの SDK/API インターフェースで確認してください。

この Git に似た構造により、エージェントは次の 3 つの問いを切り分けて Jinkō を使いやすくなります。

  • 作業はどこに整理されているか?プロジェクトとフォルダーを確認します。
  • どの成果物について話しているか?プロジェクト項目を特定します。
  • バージョン管理された成果物のどの状態が重要か?明示的なバージョンまたはスナップショットのインターフェースを使うか、ユーザーが最新の状態を求めている場合は head を使います。

Git との類比を明示的に示す場合を除き、workspace、file、upload、save、version、revision、commit のような一般的な言葉ではなく、Project、Project Item、Snapshot を使用してください。

ドメイン用語

プロジェクト: 独自の参考資料、データ、モデリング成果物、レポートを持つ、具体的な科学モデリングの取り組みです。 避ける語:ワークスペース、ケース、研究フォルダー。

フォルダー: 関連するプロジェクト項目をまとめるためにプロジェクト内で使用する整理用コンテナーです。フォルダーはナビゲーションやワークフローの整理に役立ちますが、項目の識別情報やスナップショットの識別情報に代わるものではありません。 ユーザー向けの説明では、Git の類推を示す場合を除き、「プロジェクト項目」や「ディレクトリ」は避けてください。

プロジェクト項目: プロジェクト内にある名前付きの Jinkō オブジェクトです。参考資料、モデル、プロトコル、試験、データテーブル、出力セット、文書などが該当します。ユーザー向けの識別情報としては SID が優先されます。バージョン管理される型では、バージョンをまたいで同じ識別情報を保持できます。 正確さが重要な場合は、「ファイル」、「アセット」、「オブジェクト」を避けてください。

スナップショット: Jinkō のモデル、プロトコル、試験、またはコア項目 API がスナップショットを公開するその他のリソースの、不変の状態です。正確なバージョンへのアクセスを可能にします。フォルダーやすべてのプロジェクト項目に共通する性質ではありません。 類推を説明する場合を除き、「リビジョン」、「保存」、「バージョン」、「コミット」は避けてください。

参考資料: 通常は科学論文の PDF と、DOI などの書誌メタデータを保持するプロジェクト項目です。抽出とモデリングの根拠となります。この項目の Jinkō API の型名は Source です。 「ソース」、「文書」、「ファイル」、「アップロード」は避けてください。API の型名には Source のみを使用してください。

抽出: 1 つの参考資料から選択した、テキスト、矩形、数式、またはデータテーブルのオブジェクトを 1 つ保持するプロジェクト項目です。パラメーター値、臨床エンドポイント、メカニズムの記述など、根拠を示す定式化と、分類(Statement、Hypothesis、Data)を含めることができます。 「メモ」、「抜粋」、「追跡されていない事実」は避けてください。

ハイライト: 抽出内にある、位置が特定された根拠の一部です。参考資料の PDF 内の位置にリンクします。ハイライトはプロジェクト項目ではありません。 「注釈」、「引用」は避けてください。

モデル: モデル化する生物学的または薬理学的メカニズムを表す、Jinkō 互換の実行可能な表現です。 「モデルファイル」、「スクリプト」は避けてください。

プロトコル: 試験の群、介入、投与または治療条件、シミュレーションのタイミングを定義する Jinkō の成果物です。 「研究デザイン」、「シナリオファイル」は避けてください。

試験: シミュレーションまたは比較のために、プロトコル、モデル、出力セット、データテーブルを組み合わせる Jinkō の成果物です。 「実行」、「シミュレーション設定」は避けてください。

キャリブレーション: 選択した実験的根拠にシミュレーションが適合するように、モデルパラメーターを調整する段階です。 「フィッティング」、「チューニング」は避けてください。

キャリブレーション候補: キャリブレーションの候補として提案される、モデル固有のパラメーターです。toCalibrate モデルタグを付けることができます。 「自由パラメーター」、「調整ノブ」は避けてください。

仮想集団: インシリコ試験の実行に用いる、パラメーター化された仮想被験者の生成集団です。 「コホート」、「サンプル」は避けてください。

トレーサビリティリンク: モデル、データセット、またはレポート内の主張から、その主張を裏付ける抽出、参考資料、または明示的な仮定へのリンクです。 「参考資料」(プロジェクト項目を指す用語です)、「引用」、「来歴」は避けてください。

モデリングコンテキスト: Jinkō モデルの構築または改良に必要な、科学、プロトコル、試験、参考資料、成果物に関するすべての背景情報です。 「抽出カタログ」、「モデル入力バンドル」は避けてください。

関係性

  • Project には、1 つ以上の Project Items が含まれます。
  • Folder は、Project 内の Project Items を整理します。
  • バージョン管理される一部の Project Items は、コアアイテム API を通じて Snapshots を公開します。
  • Snapshot は、変更されないコアアイテムの状態を 1 つ記録します。存在すると決めつけず、リソース API を確認してください。
  • Reference は、1 つ以上の Extracts を支えます。
  • Extract は 1 つの Reference に由来し、証拠を 1 つ以上の Highlights として保持します。
  • Highlight は、Reference PDF 内の該当箇所にリンクします。
  • Model は、実行可能な生物学的または薬理学的メカニズムを表します。
  • Protocol は、Trial で使用する群、介入、タイミングを定義します。
  • Trial は、Protocol、Model、出力セットまたは測定値、および任意の変換済みデータオーバーレイを使用します。
  • Calibration は、選択したエビデンスと出力を使用して Calibration Candidates を調整します。
  • Virtual Population は、Trial の実行に使用するパラメーター化された仮想被験者を提供します。
  • Traceability Link は、Project Items、Model の構成要素、Trial の出力、データテーブル、レポートを Extracts、References、または明示的な前提に結び付けます。
  • Modeling Context は、モデリング上の判断に必要な関連する References、Extracts、Traceability Links、Models、Protocols、Trials、レポートをまとめます。

回答の指針

  • 精度が高まる場合は、ユーザーの言葉を Jinkō の用語に置き換えてください。
  • 理解の手がかりとして Git との類似性を維持しますが、Jinkō が文字どおり Git であるかのように示さないでください。
  • 安定した SID アイデンティティと、スナップショットを公開するリソースにおける不変のスナップショットアイデンティティを区別してください。
  • ユーザーが現在の状態を求めている場合に限り head/latest を使用してください。厳密な再現性が重要な場合は、スナップショットを指定してください。
  • フォルダーの確認、作成、変更が必要な場合は、references/folder-management.md を読み、API 呼び出しを独自に考案せず、同梱スクリプトまたは記載されている SDK 呼び出しを使用してください。
  • 実装タスクは、該当するスキル jinko-reference、jinko-model、jinko-protocol、jinko-trial、jinko-vpop、jinko-data-table、または jinko-sdk-setup に振り分けてください。

コメント