Concepts

This page explains the core concepts behind Cendis. Read it once and the rest of the documentation will make sense.

The problem Cendis solves

Modern AI coding tools (Claude Code, Cursor, Codex) are configured per-project through skills, slash commands, templates, and rules files. Without governance, every project ends up with its own ad-hoc collection — copy-pasted from blog posts, drifted from team standards, and impossible to update at scale.

Cendis is a governed registry for those AI assets. You publish once, your projects pull, and you have a clear audit trail of which version is running where.

Org

The org is the top-level container. It’s typically your company.

• One billing account
• One member roster (admins + members)
• One asset registry that all workspaces inside the org can pull from

You sign up, create an org, and invite teammates. Everything else lives inside it.

Workspace

A workspace is a governance scope inside an org. It’s the boundary around a set of assets that share the same release cadence and approval policy.

Most orgs start with one workspace and split later. Common splits:

• One workspace per product line
• Separate workspaces for engineering vs. product (different asset types)
• Customer-facing workspace + internal workspace

Workspaces are how Cendis pricing scales — you pay per workspace, not per seat.

Asset types

Cendis governs four types of assets. The CLI uses the same pull / list / status commands for all four.

Skill

A skill instructs an AI agent how to handle a specific task — code review, debugging, test generation, documentation. Format: markdown with YAML frontmatter.

Lives at: .claude/skills/{slug}.md, .cursor/rules/{slug}.mdc, etc.

Command

A command is an executable shortcut for an AI tool — a slash command in Claude Code, a custom command in Cursor. The agent invokes it on demand or auto-suggests it.

Lives at: .claude/commands/{slug}.md, etc.

Template

A template is a file or project scaffold — a PR description template, an issue template, a starter package.json. Pulled into a known location and treated as governed source-of-truth.

Lives at: wherever the template targets (.github/PULL_REQUEST_TEMPLATE.md, etc.).

Rules file

A rules file is an IDE-specific configuration — CLAUDE.md for Claude Code, .cursorrules for Cursor, AGENTS.md for Codex. Sets project-wide behavior for the agent.

Lives at: project root, typically.

Version strategy

Each project’s cendis.yaml declares a version strategy that controls how cendis pull resolves which version to fetch.

latest

Always pulls the newest published version. Best for:

• Fast-moving teams that trust the registry
• Assets where breaking changes are rare
• Internal-only orgs where you control both publish and pull

pinned

Locks each asset to the exact version recorded in cendis.yaml. cendis pull will refuse to upgrade unless you change the pin. Best for:

• Production deployments that need reproducible builds
• Customer-facing assets where you must approve every change
• Compliance-sensitive teams (audit log of every version change)

You can mix strategies per-asset using the @version syntax even in a latest config:

cendis pull skill/code-review        # follows version_strategy
cendis pull skill/code-review@2.0.0  # pins this one regardless

Drift

Drift is the gap between what you have locally and what’s published in the registry.

cendis status

Outputs a per-asset diff — up-to-date, outdated, or missing. Drift is informational, not a blocker. Run cendis pull to resolve.

In CI, run cendis status --strict to fail the build on any drift. Use this in production deploy pipelines to enforce that what runs in prod matches what’s approved in the registry.

Approval queue

When an asset publisher submits a new version, it can require approval before becoming published. Approvers are configured per workspace.

The flow:

1. Publisher submits version 2.1.0
2. Asset enters pending_approval state — cendis list won’t surface it as the latest
3. Approver reviews in the dashboard, approves or rejects
4. On approval, the version becomes published — projects on latest pull it on next sync

Approvals are how Cendis converts “we have a registry” into “we have governance.”

Audit trail

Every state transition (publish, approve, reject, deprecate, pull) is logged with:

• Who did it
• When
• Which version
• For pulls: which project (matched on cendis.yaml)

Available in the dashboard and via the API. This is what makes Cendis useful for compliance-heavy teams.

Putting it together

The end-to-end loop:

1. Author publishes a new skill version → enters approval queue
2. Workspace admin approves → version becomes published
3. Engineer runs cendis pull in their project → SHA-verified files written to disk
4. CI pipeline runs cendis status --strict → fails if anyone hand-edited the file
5. Audit trail shows: publisher, approver, every project that pulled, every version they’re on

That’s it. Read CLI Quickstart for the hands-on version.