Boot and operate JP's self-referential CMS. Connection-agnostic — works with notionctl, Notion MCP, raw API, or curl. The CMS describes its own schema, intents, workflows, and governance.
Scanned 9/20/2026
Install to Claude Code
npx -y skills add lev-os/agents --skill lev-cms --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Lev Cms?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/lev-os-lev-cms)More formats (shields.io, HTML) on the badges page.
---
name: lev-cms
description: Boot and operate JP's self-referential CMS. Connection-agnostic — works with notionctl, Notion MCP, raw API, or curl. The CMS describes its own schema, intents, workflows, and governance.
triggers: ["cms", "notion cms", "boot cms", "lev cms", "triage", "inbox", "content queue", "heartbeat", "bootup"]
---
# Lev CMS — Self-Referential Agent Operating System
The CMS describes its own schema, intents, workflows, and governance. This skill teaches you how to connect. Everything else is IN the CMS.
## 1-Liner Boot
```
RuntimeState DB: fdbf6902-5597-438d-8e6d-1452b51a5d57
Bootup page: 31f9b3e2-80ff-819a-b427-fd874996c93a
```
Read the `Value` property of the bootup page. It contains your operating instructions: identity, governance, boot sequence, database aliases, routing, and write pipeline.
## How to Connect
Use whatever Notion tool you have. The CMS doesn't care.
| Tool | Verify | Read DB | Read Page |
|------|--------|---------|-----------|
| notionctl | `notionctl doctor --json` | `notionctl db query <alias> --json` | `notionctl page get <id> --json` |
| MCP | `notion-fetch` any page | `notion-fetch {id: "collection://<uuid>"}` | `notion-fetch {id: "<id>"}` |
| API | `GET /v1/users/me` | `POST /v1/databases/<uuid>/query` | `GET /v1/pages/<id>` |
## After Boot
The bootup prompt tells you what to do. Key operations:
- **Triage inbox**: query `inbox` DB, filter `Processed=NO`
- **Route intents**: check IntentRegistry before executing
- **Write pipeline**: validate → confirm → write → log event to `event_log`
- **Entity lifecycle**: query `entities` DB for states and transitions
- **Content strategy**: query `content_queue` for hooks and themes
## Architecture (for developers, not operators)
The CMS has 3 layers — do not confuse them:
1. **Storage Adapter** (`CanonicalStorageAdapter`) — owns CRUD, emits LevEvents. Today: Notion via notionctl.
2. **CMS Control Plane** (`CmsControlPort`) — orchestrates workflows, approvals, scheduling OVER storage. Future: `plugins/cms-control-plane/`
3. **Publish Targets** (`PublishTargetPort`) — projection-only consumers. Today: `plugins/publisher/` (filesystem materializer).
Contracts in `core/domain/src/event-source.ts`. Specs in `docs/specs/spec-cms-control-plane.md` and `docs/specs/spec-storage-adapters.md`.
notionctl is a thin API envelope. It has zero CMS domain logic. CMS semantics live above the adapter.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!