Inheritance

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)

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:

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

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

## Project Guidelines
This project uses PostgreSQL 15 and Solid Queue...

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:

crewkit resources inspect rails-expert

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

Next steps

• Agents
• Experiments (A/B testing versions)
• Playbooks