Let your coding agent edit Optimizely content. You review the drafts.

No more hand-written queries against tblContent. Items come back with every property decoded, including ContentAreas, local blocks, links and rich text. Reads go straight to the database, so the site doesn't need to be running.

See the C# class for a content type, the source line of each property and the Razor views, plus which ContentAreas accept it according to [AllowedTypes].

Find every page and block that references an item, through nested blocks all the way up to pages. You can also resolve a URL to content, or list the unpublished drafts.

See an item's change log: moves, deletes, restores and publishes, with who did each and when.

The same commands work on both, including CMS 13 databases upgraded from CMS 12. serve picks the right site agent for your CMS version.

Writes go through IContentRepository inside your running site, so validation, versioning, events and caches all work. Changes are saved as drafts unless you publish, and every write command takes --dry-run.

get shows an experience as its sections, rows, columns and elements, with display templates and settings. composition adds, moves, changes and removes them, or writes back the JSON get printed. Content variations and blueprints work too.

Read and set shortcuts and external links, simple addresses, categories, sort order and publish dates.

delete only moves content to the recycle bin, and refuses while other pages or blocks still reference it, listing where. trash shows what's in the bin, and restore puts it back where it was.

unpublish takes a page offline, the same way expiring it in the edit UI does, and shows which version was live so you can publish it again. discard removes a draft that was never published.

Content with an approval sequence can't skip its reviewers: --request-approval sends it for review instead. --publish-at schedules the publish with the CMS's own scheduled job.

Each file becomes a media item of the type your site registers for its extension, in the page's own folder or any folder you choose. The output shows where it was stored.

See who can read and edit an item, and where those rights are inherited from. Changes apply to that item only, and can never leave the site without an administering role.

With "guidNamespace", every item a plan creates gets the same GUID in every database. --update-existing then updates what's already there, restores it from the recycle bin if needed, and skips finished steps. export turns existing content from any database into a plan like this.

A plan value of "@body.html" reads that file, so long rich text lives in HTML files you can review instead of inside the JSON. Links written as href="$id" point to content the plan creates and are saved as permanent links.

Steps on content the plan hasn't created yet run against stand-ins, so validators, required properties and [AllowedTypes] are checked before anything is written.

After restoring a production database, one command makes your local host each site's primary host and moves SiteUrl with it, so links and canonical URLs point to localhost. The production hosts are kept. Save the mapping once and rerun it after every restore. users add creates a local admin login and stores its password in a file only you can read.

sync pull brings what editors did in production into your local database: new, changed and moved content, matched by GUID and written through your local site. It only reads production, keeps your own local changes, lists conflicts instead of overwriting them, and remembers what it synced, so the next pull is quick.

A coding agent can prepare changes for production but can't write them. sync push seals what changed locally. You run the command it prints in your own terminal: it shows what it will do, then asks for the database's name and a write login, which is never saved. It refuses to run if the plan, the build or production changed since the seal. On Azure it can join production's event bus, so no restart is needed, and upload media to its blob storage.

See every job's schedule, last run and log, and where its code lives. Run one and wait for its result, stop it, or change when it runs. After a database restore, serve stops overdue jobs from all running at startup, and jobs that delete data permanently need an explicit flag.

types --orphaned finds content types whose code is gone, and type shows leftover properties with their stored values. types prune removes what can go through the CMS, never content, records every removal first, and needs a flag before it deletes stored values.

serve starts your existing build with a small agent injected at startup, through a .NET startup hook and a hosting startup. Your site's code and config stay as they are. ide on only adds a block to your own .csproj.user, which git ignores.

With ide on, the site you start from Rider or Visual Studio loads the agent from its own build, so opticli writes through that process and a reload shows the change, without a restart. No per-run setup, HTTPS with the development certificate works, and the debugger, hot reload and breakpoints stay as they are.

Piped output is compact JSON. Every item has a ref you can pass to the next command, and errors come with a code and a hint. A Claude Code skill tells the agent when to use opticli and how to use it safely.