Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
95 changes: 75 additions & 20 deletions docs/src/docs/kitfile/kf-overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,46 +6,48 @@ keywords: kitfile format, kitops kitfile example, modelkit yaml, ai model manife

# Kitfile Format for ModelKits

The **Kitfile** is the blueprint for every AI/ML project packaged with KitOps.
The **Kitfile** is the blueprint for every AI project packaged with KitOps.

It’s a simple, YAML-based manifest that defines what goes into a ModelKit: models, datasets, notebooks, documentation, and metadata.
It’s a simple, YAML-based manifest that defines what goes into a ModelKit: models, datasets, code, prompts, agent skill files, MCP server configurations, and documentation.

ModelKits use Kitfiles to package and version your project so it can be shared, stored, or deployed from any OCI-compatible registry.

## Why Use a Kitfile?
## Why Use a Kitfile?

A Kitfile helps you:
- Package your AI/ML project with full traceability
- Package your AI project with full traceability - whether it’s a model, an agent configuration, or both
- Make your work reproducible across environments
- Collaborate with DevOps, ML engineers, and app developers using a shared format
- Integrate seamlessly into CI/CD pipelines and registries
- Collaborate with DevOps, ML engineers, AI engineers, and app developers using a shared format
- Integrate into CI/CD pipelines and registries

## 📚 Kitfile Sections
## Kitfile Sections

Each Kitfile includes one or more of the following sections:

| Section | Description |
|---------------|-------------|
| `package` | Project metadata (name, version, license, authors) |
| `code` | Paths to notebooks or scripts |
| `model` | The serialized model and framework info |
| `datasets` | Training, validation, or other datasets |
| `docs` | Additional documentation to include |
| `prompts` | Prompt files for use with LLMs |
| Section | Description | Example contents |
|---------------|-------------|------------------|
| `package` | Project metadata (name, version, license, authors) | - |
| `model` | The serialized model and framework info | Model weights, GGUF files |
| `datasets` | Training, validation, or other datasets | CSV files, Parquet datasets |
| `code` | Code, scripts, and server configurations | Jupyter notebooks, MCP server code and config files |
| `prompts` | Prompt files and agent skill files | System prompts, SKILL.md, .cursorrules |
| `docs` | Additional documentation | README, usage guides |

The `prompts` section is the natural home for agent skill files and prompt templates. The `code` section is where MCP server code and configuration files go. You can organize these however fits your project - the key is that everything gets versioned together.

You can extract the Kitfile from any existing ModelKit:

```sh
kit unpack [registry/repo:tag] --config -d .
```

## Minimal Kitfile Example
## Minimal Kitfile Examples

The only required fields are:
- `manifestVersion`
- At least one of `code`, `model`, `datasets`, `docs`, or `prompts` section

Example:
A ModelKit for a dataset:
```yaml
manifestVersion: v1.0.0

Expand All @@ -56,12 +58,30 @@ datasets:
path: ./data/test.csv
```

A ModelKit for agent skills and prompts (no model required):
```yaml
manifestVersion: v1.0.0

package:
name: customer-support-agent
description: Skill files and prompts for the customer support agent
version: 2.1.0

prompts:
- path: ./prompts/system.prompt.md
description: System prompt for the support agent
- path: ./skills/escalation.skill.md
description: Skill for escalating tickets to human agents
- path: ./skills/refund-processing.skill.md
description: Skill for processing refund requests
```

### Notes on Kitfile Behavior
- Kitfiles must use relative paths (not absolute)
- ModelKits can include only one model, but multiple datasets or code bases
- You can currently only build ModelKits from local files but support for remote sources (e.g. DVC, S3) is coming soon
- ModelKits can include only one model, but multiple datasets, code entries, or prompts
- You can currently only build ModelKits from local files, but support for remote sources (e.g. DVC, S3) is coming soon

## 🧱 Example: Full Kitfile
## Example: Full Kitfile with Model

```yaml
manifestVersion: v1.0.0
Expand Down Expand Up @@ -98,6 +118,41 @@ prompts:
description: System prompt for model inference
```

## Example: Agentic AI Kitfile

This Kitfile packages agent skill files, prompts, and an MCP server configuration together. No model is needed when the agent uses a hosted API (e.g., Claude, GPT).

```yaml
manifestVersion: v1.0.0

package:
name: sales-research-agent
description: Agent configuration for automated sales research pipeline
authors:
- Platform Team
version: 3.0.1

prompts:
- path: ./prompts/system-prompt.md
description: Core system prompt defining agent persona and constraints
- path: ./prompts/research-prompt.md
description: Prompt template for company research tasks
- path: ./skills/linkedin-enrichment.skill.md
description: Skill for enriching leads with LinkedIn data
- path: ./skills/competitive-analysis.skill.md
description: Skill for generating competitive analysis summaries

code:
- path: ./mcp-servers/crm-connector
description: MCP server for CRM data access
- path: ./mcp-servers/web-scraper
description: MCP server for web scraping with rate limiting

docs:
- path: ./README.md
description: Agent setup and deployment guide
```

## Learn More

➡️ Explore the [Kitfile structure](../format.md) in detail
Expand Down
34 changes: 18 additions & 16 deletions docs/src/docs/modelkit/intro.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,42 +8,44 @@ keywords: modelkit, modelkit overview, oci ai packaging, ml model registry, shar

![ModelKit](./ModelKit_chart.svg)

>**ModelKit is a standardized, OCI-compliant packaging format for AI/ML projects.**
>**ModelKit is a standardized, OCI-compliant packaging format for AI projects.**

It bundles everything your model needs — datasets, training code, config files, documentation, and the model itself — into a single shareable artifact.
It bundles the artifacts your AI project depends on - models, datasets, code, prompts, agent skill files, MCP server configurations, and documentation - into a single versioned, shareable artifact.

Use ModelKits to version, share, and deploy AI models across teams and environments using familiar DevOps tools like DockerHub, GitHub Packages, or private registries.
Despite the name, not every ModelKit contains a model. A ModelKit can package any combination of AI project artifacts. You might create a ModelKit that contains only prompts and skill files for an agentic AI system, or one that bundles an MCP server with its configuration, or a complete package with model weights, training data, prompts, and code.

Use ModelKits to version, share, and deploy AI projects across teams and environments using familiar DevOps tools like DockerHub, GitHub Packages, or private registries.

➡️ [Get started with ModelKits](../../get-started.md) in under 15 minutes
➡️ [See how security-focused teams use ModelKits](../../use-cases.md)
➡️ [See how teams use ModelKits](../../use-cases.md)

## 🔑 Key Features
## Key Features

* **OCI-compliant and tool-friendly**
Store, tag, and version ModelKits in any container registry — no custom infrastructure needed.
Store, tag, and version ModelKits in any container registry. No custom infrastructure needed.

* **Selective unpacking**
Unpack only the parts you need (e.g. just the dataset or model weights) to speed up pipelines and reduce compute overhead.
Unpack only the parts you need (e.g. just the prompts, just the model weights, just the MCP config) to speed up pipelines and reduce overhead.

* **No duplication for shared assets**
Reuse datasets or configs across multiple kits without bloating storage.
Reuse datasets, prompts, or configs across multiple kits without bloating storage.

* **Familiar versioning and tagging**
Use registry-native tags (e.g. `:latest`, `:prod`, `:rollback`) to track model state and history.
Use registry-native tags (e.g. `:latest`, `:prod`, `:rollback`) to track project state and history.

* **Built for ML workflows**
Supports AI-specific needs like serialized model handling, reproducible training snapshots, and data lineage.
* **Built for AI workflows**
Supports models, datasets, prompts, agent skill files, MCP server configurations, and code. Handles both large binary files (model weights) and small text files (prompts, configs) in the same artifact.

* **Streamlined collaboration**
Teams can pull, inspect, and repack models just like container images making it easier to collaborate across roles and environments.
Teams can pull, inspect, and repack ModelKits just like container images, making it easier to collaborate across roles and environments.

## Why It Matters
## Why It Matters

ModelKit simplifies the messy handoff between data scientists, engineers, and operations. It gives teams a common, versioned package that works across clouds, registries, and deployment setups without reinventing storage or delivery.
ModelKit simplifies the messy handoff between data scientists, AI engineers, agent developers, and operations. It gives teams a common, versioned package that works across clouds, registries, and deployment setups without reinventing storage or delivery.

It’s more than a format — it’s a building block for secure, reproducible AI.
For self-hosted model teams, it’s the packaging layer that ties model weights to their training data, configuration, and documentation. For agentic AI teams, it’s the versioning system that ties prompts, skills, and MCP configs to a known-good state. For teams doing both, it’s one format that covers everything.

## 🔄 ModelPack Format Support
## ModelPack Format Support

KitOps supports both **ModelKit** and **ModelPack** artifact formats:

Expand Down
9 changes: 5 additions & 4 deletions docs/src/docs/next-steps.md
Original file line number Diff line number Diff line change
Expand Up @@ -82,7 +82,7 @@ If you are building a ModelKit from a Hugging Face repository you can use the [k

### 2/ Generating a Kitfile From a Directory

If you have your AI/ML project artifacts in a directory structure already then the easiest way to get started is with [kit init](../cli/cli-reference/#kit-init). From the root of the directory with the AI/ML artifacts you wish to pack in the ModelKit run:
If you have your AI project artifacts in a directory structure already then the easiest way to get started is with [kit init](../cli/cli-reference/#kit-init). From the root of the directory with the artifacts you wish to pack in the ModelKit run:

```sh
kit init .
Expand All @@ -95,15 +95,16 @@ You can learn more about the syntax, options, and flags in our [CLI docs](../cli

### 3/ Writing Your Own Kitfile

There are five parts to a Kitfile:
There are six parts to a Kitfile:

1. The `package` section: Metadata about the ModelKit, including the author, description, and license
1. The `model` section: Information about the serialized model
1. The `datasets` section: Information on included datasets
1. The `code` section: Information about codebases related to the project, including Jupyter notebook folders
1. The `code` section: Information about codebases, scripts, and MCP server configurations
1. The `prompts` section: Prompt files, agent skill files, and other text-based AI configuration
1. The `docs` section: Information about documentation for the ModelKit

A Kitfile only needs the `package` section, plus one or more of the other sections.
A Kitfile needs a `manifestVersion` plus at least one of the other sections. The `package` section is recommended for metadata but not strictly required. Not every ModelKit needs a model - you can create ModelKits that contain only prompts and skill files, or only code and MCP server configurations.
Comment thread
bmicklea marked this conversation as resolved.

The `model` section can contain a single model, or you can create model dependencies with `model parts` which is covered in the [KitFile format documentation](../kitfile/format/#model).

Expand Down
Loading
Loading