---
source: CrewKit documentation
url: https://crewkit.io/docs/inheritance.md
title: "Inheritance"
description: "How resources merge across platform, organization, and project tiers."
---


crewkit uses a three-tier inheritance model for all resources (agents, skills, rules, commands). This lets you start with platform defaults and layer on team and project customizations.

---

## The three tiers

```
Platform (crewkit-managed)
  |
  v  inherit / fork / standalone
Organization (your team)
  |
  v  inherit / fork / standalone
Project (project-specific)
```

| Tier | Scope | Managed by |
|------|-------|------------|
| **Platform** | All crewkit users | crewkit team |
| **Organization** | Your team | Team admins |
| **Project** | One project | Project members |

---

## Ownership modes

Each resource at each tier has an ownership mode:

### Standalone

Full content, no parent. The resource exists only at this tier.

```
Organization: acme-deploy-checker (standalone)
  -> No platform equivalent. Fully owned by your org.
```

### Inherit

Merges content from parent tiers. Organization adds its guidelines, project adds its specifics.

```
Platform: rails-expert (base content)
  -> Organization: rails-expert (inherit) adds "## Organization Guidelines"
    -> Project: rails-expert (inherit) adds "## Project Guidelines"
```

The effective content is the merge of all three.

### Forked

A snapshot copy that's independent after creation. Use this when you want to diverge from the platform version.

```
Platform: rails-expert v3
  -> Organization: rails-expert (forked from v2)
    -> Independent. Platform updates to v3 don't affect your fork.
```

---

## Effective content

When the CLI syncs resources, it requests the **effective content** — the final merged result across all applicable tiers. The API computes this server-side.

For inherited resources, the merge works by concatenation:

```markdown
<!-- Platform content -->
You are an expert Rails developer...

## Organization Guidelines
Follow our team's coding standards...

## Project Guidelines
This project uses MySQL 8 and Sidekiq...
```

---

## Versioning

Every save creates an immutable resource version:

- **version_number** — Auto-incrementing integer
- **version_hash** — SHA-256 of the content
- **content** — Full snapshot of the content at that version

You can roll back to any previous version through the dashboard or API.

The **effective_version_hash** is the hash of the final merged output across all tiers. This is what gets tracked on sessions for resource performance measurement.

---

## Not all tiers required

Resources don't need to exist at every tier:

- An org can create `deploy-checker` (standalone, org-only) with no platform equivalent
- A project can create `db-migration-helper` (standalone, project-only)
- A platform resource can exist without any org or project overrides

---

## When to fork vs inherit

**Inherit** when you want to stay in sync with upstream changes. Your org/project additions stack on top of the platform base. When the platform updates, you get those updates automatically.

**Fork** when you want to diverge. Your copy is independent. Platform updates don't affect you. Use this when you disagree with the platform direction or need fundamentally different content.

---

## Viewing the inheritance chain

Use the CLI to inspect how a resource resolves:

```bash
crewkit resources inspect rails-expert
```

This shows each tier's contribution to the final effective content.

---

## Next steps

- [Agents](/docs/agents)
- [Experiments (A/B testing versions)](/docs/experiments)
- [Playbooks](/docs/playbooks)