Extending Cial

Most products give you a feature list and a feedback form. Cial gives you the source — and the tooling to change it. Cial is the platform: it runs your coding agent (a harness like Claude Code or Kimi) and hands it write access to Cial's own code, plus a safe edit → verify → deploy → commit pipeline. So when something's missing, you have the agent build it into the platform. This page is the heart of Cial: how you make it yours.

How a change happens

You don't configure Cial so much as converse it into shape. Describe what you want; the agent does the engineering loop and ships it to your live instance.

The stack is disposable; self-edit is permanent

It helps to separate two things. The implementation — which model runs, which tools exist, how the sidebar looks — is just where Cial happens to be today. The capability — that any of it can be changed from inside — is the part that doesn't move.

So when these docs describe a feature, read it as "here's the default — and you can replace it."

Add a harness

A harness is the engine a session runs on. Cial ships with Claude Code and Kimi — but they're just two entries in a registry, not a hard limit. Want a different model, a local CLI, or a new provider? Ask the agent to add it as a harness, and it appears in the composer's engine picker like the built-ins.

Add a tool or integration

There are two levels, depending on how deep you need to go:

For anything off-the-shelf, the Vault (env-var / MCP / markdown tools) is the fast path. For something bespoke — your private API, a workflow no MCP server exists for — ask the agent to build the integration into Cial itself. Because it controls the whole codebase, it can wire the integration anywhere it needs to live.

Add a feature or surface

New capabilities slot in as self-contained pieces rather than rewrites:

The ultimate integrator

Put it together and the claim is simple: because Cial can rewrite itself, it can integrate with almost anything. A new model provider, your internal tools, a niche workflow, an API with no existing client — none of them need to have been anticipated. If you can describe the integration, the agent can build it into your Cial and ship it.

Your changes survive updates

Cial keeps improving upstream, and your instance can pull those updates. Changes written the right way — additive (new pieces) rather than rewriting core files — fold in cleanly when you update, so customizing today doesn't mean falling behind tomorrow. The agent knows these conventions and follows them, and records any deeper change so an update can re-apply it.

Experiment without fear

Self-editing sounds risky until you see the safety net. Every change is type-checked before it ships, committed so it's never lost, and — if a change ever breaks the screen — Cial self-heals: it detects the broken build, falls back to a built-in recovery page (which never depends on the broken code), and lets you roll back to the last working version in one click. Nothing you try is irreversible.

How to ask

It's just chat. Be specific about the outcome and let the agent handle the engineering:

• "Add a Linear integration — let me create issues from a session."
• "Swap the model picker so it defaults to Kimi for me."
• "Add a /standup command that summarizes today's sessions."
• "Build a small dashboard app showing our team's open tasks."
• "Connect our internal deploy API as a tool."

The agent will edit, verify, deploy, and commit — and tell you what it changed. If you don't like it, ask it to revert, or roll back.