Update to Jinkō

{
  "name": "jinko-context",
  "description": "Explain core Jinkō context, navigation, version management, and domain language for agents and users. Use this skill whenever the user needs a mental model of Jinkō projects, folders, project items, snapshots, sources, extracts, protocols, trials, calibration, virtual populations, references, or modeling context; when translating between generic terms and Jinkō terminology; or when an agent needs orientation before navigating or modifying Jinkō artifacts. This skill is conceptual and terminology-focused; use dedicated jinko-* workflow skills for creating or editing specific artifacts.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 273
    }
  ],
  "skill_md_contents": "---\nname: jinko-context\ndescription: >-\n  Explain core Jinkō context, navigation, version management, and domain language for agents and users. Use this skill whenever the user needs a mental model of Jinkō projects, folders, project items, snapshots, sources, extracts, protocols, trials, calibration, virtual populations, references, or modeling context; when translating between generic terms and Jinkō terminology; or when an agent needs orientation before navigating or modifying Jinkō artifacts. This skill is conceptual and terminology-focused; use dedicated jinko-* workflow skills for creating or editing specific artifacts.\nmetadata:\n  author: Nova In Silico\nlicense: MIT\n---\n\n# Jinkō Context\n\nUse this skill to explain Jinkō's shared mental model and vocabulary. Keep answers practical: the goal is to help a user or agent navigate Jinkō artifacts without confusing project organization, scientific content, and immutable versions.\n\n## Navigation and Version Management\n\nJinkō project navigation behaves much like working in a Git repository, but for scientific modeling artifacts instead of source-code files.\n\n- A **Project** is like the repository: it is the boundary for a concrete scientific modeling effort, including sources, data, models, protocols, trials, reports, and collaboration history.\n- **Folders** are like repository directories: they organize related project items by workflow, experiment, disease area, evidence package, or analysis thread. The folder API is an organizational surface; a folder is not a Project Item.\n- **Project Items** are like tracked files or domain objects in the repository: each item has an SID and represents a Jinkō artifact such as a model, protocol, trial, data table, source, output set, or document.\n- **Snapshots** are immutable states exposed by versioned Jinkō core-item APIs. The latest state is head. Do not assume every Project Item type exposes snapshots; use the resource's SDK/API surface to determine whether snapshot identity exists.\n\nThis Git-like structure makes Jinkō easier for agents to navigate because agents can separate three questions:\n\n- Where is the work organized? Look at the project and folders.\n- Which artifact is being discussed? Identify the project item.\n- Which exact state of a versioned artifact matters? Use its explicit version or snapshot surface, or use head when the user wants the latest state.\n\nUse `Project`, `Project Item`, and `Snapshot` rather than generic words like workspace, file, upload, save, version, revision, or commit unless you are explicitly making the Git analogy.\n\n## Domain Language\n\n**Project**:\nA concrete scientific modeling effort with its own sources, data, modeling artifacts, and reports.\nAvoid: workspace, case, study folder.\n\n**Folder**:\nAn organizational container inside a project used to group related project items. Folders support navigation and workflow hygiene; they do not replace item identity or snapshot identity.\nAvoid: Project Item or directory when speaking to end users unless making the Git analogy.\n\n**Project Item**:\nA named Jinkō object inside a project, such as a source, model, protocol, trial, data table, output set, or document. Its SID is the preferred user-facing identity. Versioned types can retain that identity across versions.\nAvoid: file, asset, object when precision matters.\n\n**Snapshot**:\nAn immutable state of a Jinkō model, protocol, trial, or other resource whose core-item API exposes snapshots. It enables exact version access; it is not a universal property of folders or every Project Item type.\nAvoid: revision, save, version, commit except when explaining the analogy.\n\n**Source**:\nAn immutable scientific input, usually a paper PDF, used as evidence for extraction and modeling.\nAvoid: document, file, upload.\n\n**Extract**:\nA structured piece of information derived from a source, such as a parameter value, clinical endpoint, experimental condition, mechanism statement, data series, or assumption. Extracts should stay linked to the source evidence that justifies them.\nAvoid: note, snippet, untracked fact.\n\n**Model**:\nA Jinkō-compatible executable representation of the biological or pharmacological mechanism being modeled.\nAvoid: model file, script.\n\n**Protocol**:\nThe Jinkō artifact that defines trial arms, interventions, dosing or treatment conditions, and simulation timing.\nAvoid: study design, scenario file.\n\n**Trial**:\nThe Jinkō artifact that combines a protocol, model, output sets, and data tables for simulation or comparison.\nAvoid: run, simulation setup.\n\n**Calibration**:\nThe stage that adjusts model parameters so simulations fit selected experimental evidence.\nAvoid: fitting, tuning.\n\n**Calibration Candidate**:\nA model-intrinsic parameter proposed for calibration. It may be marked with a `toCalibrate` model tag.\nAvoid: free parameter, tuned knob.\n\n**Virtual Population**:\nA generated population of parameterized virtual subjects used for in-silico trial execution.\nAvoid: cohort, sample.\n\n**Reference**:\nThe trace from a model, dataset, or report assertion back to the source evidence or assumptions that justify it.\nAvoid: citation, provenance.\n\n**Modeling Context**:\nThe full scientific, protocol, trial, source, and artifact background needed to build or refine a Jinkō Model.\nAvoid: extraction catalog, model input bundle.\n\n## Relationships\n\n- A **Project** contains one or more **Project Items**.\n- A **Folder** organizes Project Items within a Project.\n- Some versioned **Project Items** expose **Snapshots** through their core-item APIs.\n- A **Snapshot** captures one immutable core-item state; consult the resource API rather than assuming one exists.\n- A **Source** supports one or more **Extracts**.\n- An **Extract** should retain a **Reference** to its Source evidence.\n- A **Model** represents executable biological or pharmacological mechanisms.\n- A **Protocol** defines arms, interventions, and timing used by a Trial.\n- A **Trial** uses a **Protocol**, a **Model**, output sets or measures, and optional transformed data overlays.\n- A **Calibration** uses selected evidence and outputs to adjust Calibration Candidates.\n- A **Virtual Population** provides parameterized virtual subjects for Trial execution.\n- A **Reference** links Project Items, Model components, Trial outputs, data tables, and reports back to Sources or explicit assumptions.\n- A **Modeling Context** gathers the relevant Sources, Extracts, References, Models, Protocols, Trials, and reports needed to make a modeling decision.\n\n## Response Guidance\n\n- Translate user language into Jinkō language when it improves precision.\n- Preserve the Git analogy for orientation, but do not imply Jinkō is literally Git.\n- Distinguish stable SID identity from immutable snapshot identity where that resource exposes snapshots.\n- Use head/latest only when the user wants the current state; name snapshots when exact reproducibility matters.\n- Route implementation tasks to the relevant skill: `jinko-model`, `jinko-protocol`, `jinko-trial`, `jinko-vpop`, `jinko-data-table`, or `jinko-sdk-setup`.\n"
}